#ubuntu-devel 2005-02-14
<jdub> yeah, largely
<jdub> the way it attempts to run spamd, etc.
<jdub> mdz: there?
<maswan> Mithrandir: Well, hopefully it will sync ok tonight then
<Mithrandir> maswan: ook
<Mithrandir> maswan: it's a daily sync, only?
<lifeless> HrdwrBoB: completly evos fault. its got bugs open upstream.
<HrdwrBoB> ahr
<lifeless> evo *should* have one spamd and one spamc. thats 2 processes.
<maswan> Mithrandir: Yeah, we used to do more, but we got too many "too many rsync processes" mails
<Mithrandir> maswan: hmkay.
<maswan> Mithrandir: So I guess pending proper ftpmaster with password-protected mirror-sync-modules for registered primary mirrors...
<maswan> well, that or ignoring error messages, but that's not good in the long run either
<Mithrandir> maswan: yeah, that'd make sense.
<Mithrandir> maswan: rsync should have an option to ignore a certain set of error messages, like "refused due to too many connections", then
<Mithrandir> maswan: anyhow, you know if Kamion managed to track down the ia32-thingy-problem?
<maswan> Mithrandir: Yeah, but rsync is only smart in some regards, not all the regards one would want to to be smart in.
<maswan> Mithrandir: No, not really. I didn't keep track of that.
<Mithrandir> you've got the source. ;)
<maswan> Yes, but it is _rsync_ source. ;)
<srbaker> what is multiarch?
* maswan leaves that question to Mithrandir and heads to bed with a whisper about coinstallable libs
<netdur> you should rename "gnome bittorrent" to "bittorrent downloader" or something more HIG'er
<Mithrandir> maswan: dude, I'm getting the patch for ld into sarge now, I've bloody compiled gcc about fifty times during the last week and am going to work on multiarch until mid-june. :P
<srbaker> isn't there an ubuntu-sponsored arch client?
<Mithrandir> bazaar
<srbaker> link to info on that?
<jdub> bazaar.canonical.com
<lifeless> daniels: is '<unknown>' in xrestop a exited, leaking application ?
<srbaker> i find arch a bit of a pain int heass.  i've been using monotone :)
<lamont> really need to fix that router
<Mithrandir> lamont: why isn't linux32 built on amd64?
<lamont> %linux32: i386 ia64 mips mipsel powerpc s390 sparc                    # only useful for 64-bit architectures
<lamont> fixed
<lamont> Mithrandir: although you'll probably need to poke elmo to have that make a difference to hoary
<infinity> lamont : There's arm64 too, in some strange parts of the world.
<infinity> lamont : Then again, I don't know if Linux supports it..
<Mithrandir> infinity: I think he just fixed it.
<Mithrandir> lamont: it's universe for some fucked reason.
<Mithrandir> it should be supported, at least.
<infinity> Mithrandir : Nah, he just added amd64 to the line.
<Mithrandir> ah, sorry, I read arm64 as amd64
<Mithrandir> thought you were sarcastic :)
<infinity> Mithrandir : I'd argue that the line should just be "%linux32: !m68k !alpha", since alpha is always 64 bit, and m68k is the only arch that can't have a 64-bit kernel (in theory).
<mdz> jdub: here
<mdz> was on the phone
<infinity> lamont : Thoughts?
<YokoZar> I just finished my winetools package.  Would someone like to review it/sponsor an upload to Debian?
<dholbach> had had enough action tonight... i'm off to bed
<lamont> infinity: probably - I could almost certainly be talked into changing the line later.
* lamont is hip deep in postfix right now
<infinity> lamont : Well, I could change it right now. :)
<dholbach> sleep tight everyone
<infinity> lamont : It's just that when my pet port is one of the only ports that CAN'T use m68k, I'm hardly an authority on the subject.
<infinity> s/m68k/linux32/
<infinity> Wow.  I need a new brain.
<netdur> I changed reslation to 1024*768... when I log out, only part of gdm apear, I have to reboot X to get it right, but then after loggin, gnome says something about panel still running and stop loading, but desktop's right-click still works which allowed me to start terminale to "sudo reboot"
<netdur> I'm running up-to-date hoary
<eruin> netdur: ----> #ubuntu methinks
<netdur> I'm reporting about problem not looking for help
<eruin> oh, excuse me then ;)
<pvh> Kamion: Hey there. Did you see my messages?
<jdub> mdz: are we using liveseed yet?
<jdub> amu: ping
<mdz> jdub: nope
<jdub> how much room do we have left?
<lamont> mdz: liveseed will turn into ubuntu-live, yes?
<mdz> lamont: if that's what you require, I suppose so
<lamont> s/require/desire/
<lamont> it'd be (1) consistant, and (2) make my life easier.
<elmo> P-a-s updated
<mdz> jdub: 497M - <size of OpenCD stuff>
<jdub> oh, opencd stuff is already on there?
<mdz> no, but it will be for release
<mdz> and is therefore a factor in how much room we have for liveseed stuff
<jdub> we have 497MB free?
<mdz> er...no :-)
<mdz> make that 153M - <size of OpenCD stuff>
<jdub> ok
<jdub> lamont: how big was opencd for warty?
<wasabi> Package version question, example: 2.8.1-0ubuntu2
<wasabi> When the 2 becomes 10... does apt handle that? :0
<mdz> wasabi: dpkg --compare-versions
<jdub> lamont: did we have anything left that we could dump?
<lamont> jdub: after we pruned it, not so bad.
<mdz> yeah, we dropped some stuff for Warty
<lamont> we dumped celestica from the opencd stuff to make things fit
<jdub> left after warty purging
<lamont> jdub: technically, the whole thing is prunable - it's just a question of how much you want to trade off...
<wasabi> cool it's smart.
<jdub> what's on there now?
<jdub> - firefox
<jdub> - openoffice.org
<jdub> - thunderbird?
* lamont tries to remember
<mdz> jdub: ~100M
<mdz> 13M     bin
<mdz> 100M    programs
<mdz> 3.8M    disctree
<mdz> 52K     start.exe
<mdz> 512     start.ini
<mdz> 116M    total
<mdz> abiword  audacity  firefox  gimp  openoffice  pdfcreator  thunderbird
<jdub> ta
<jdub> hmm
* jdub would roughly put abiword and audacity in the binnable list
<mdz> there isn't any point in removing things until we run out of space
<lamont> and the dvd should have install+live+full openCD
<jdub> i'm not suggesting we do, i'm getting an idea of what we could remove
<mdz> lamont: any idea what the compression ratio is for the non-empty portion of the cloop?
<mdz> do you save the create_compressed_fs output?
<lamont> .../current/...out
* lamont goes to find a URL
<pvh> My fresh Hoary net-install did not create any xorg.conf at all, just an empty file.
<pvh> When I run dexconf, it overflows.
<pvh> By that I mean that it has an unexpected end of ofile.
<lamont> mdz: http://.../~buildd/livecd/livecd-current.out
<mdz> which one is i386?
<lamont> or ~buildd/livecd/YYYYMMDD/livecd-YYYYMMDD-ARCH.out
<lamont> terranova
<mdz> looks like 0.37
<mdz> not bad at all
<mdz> so we only pay for a bit over 1/3 of installed-size for things we want to add
<sladen> is /usr/share/doc binable>
<jdub> no, livecd should really carry everything available on the desktop
<jdub> we wouldn't be able to demo our elite debian doc / yelp integration if we killed all the docs
<darklight> fabbione dong
<mjg59> Is it possible to remove a package from universe?
<elmo> sure?
<mjg59> laptop-mode-tools probably shouldn't be there
<mjg59> We've got laptop-mode in main
<elmo> should that be resolved by pushing our laptop-mode to Debian?
<elmo> and/or some other merging?
<mjg59> The right way is probably to move laptop-mode-tools to main and drop laptop-mode
<mjg59> But I'd need to speak to thom about that
<elmo> bug Thom is always the best way forward ;)
<elmo> bugging thom even
* lamont runs to town for a few
<mjg59> What would generate the following in kernel logs:
<mjg59> jmfw: dropped: IN=ath0 OUT= MAC=00:05:4e:42:49:77:00:09:5b:3d:9b:78:08:00 SRC=198.93.112.61 DST=10.19.72.6 LEN=40 TOS=0x00 PREC=0x00 TTL=234 ID=574 PROTO=TCP SPT=80 DPT=36586 WINDOW=16060 RES=0x00 ACK URGP=0 
<mjg59> ?
<mjg59> Is that standard netfilter?
<YokoZar> jdub: I finished my winetools package.  Care for a peek?
<mjg59> Anyone here using madwifi drivers?
<jdub> YokoZar: bit busy atm - is it in your winehq repo?
<YokoZar> jdub: yeah.
<jdub> ok, will have a look later
<elmo> mjg59: 'ath0'?
<elmo> but yeah, that's standard netfiler
<YokoZar> I'd like a sponsor to up it to debian too
<mjg59> elmo: madwifi
<mdz> mjg59: I am
<mdz> yes, that's the standard (read: HORRIFIC) netfilter log format
<mdz> so any LOG rule would generate one of those
<mjg59> mdz: Have you seen any issues with madwifi and laptop-mode?
<mjg59> I'm leaning towards it being some strange interaction between netfilter, madwifi and laptop mode, rather than just being the latter two
<mdz> mjg59: the atheros card I have is not in a laptop
<mjg59> mdz: Ah, right
<mdz> I do have a pcmcia atheros card, but I don't use it anymore because the new laptop has ipw2200
<mdz> I could try to reproduce the bug
<daniels> lifeless: i don't know, sorry
<daniels> mjg59: i haven't seen that bug, no
<mjg59> daniels: You have a madwifi laptop?
<daniels> i mean, sometimes I don't get packets out when I don't remove ath_pci around suspend/resume, but that's it
<daniels> mjg59: yah
<mjg59> Isn't your X40 an Intel?
<daniels> mjg59: nope, ath
<mjg59> Oh, wow
<mjg59> Ok
<lifeless> daniels: ah well, thanks anyway. If you do figure out what unknown is, I have a couple ;)
<daniels> lifeless: heh
<jdub> dudes
<jdub> mjg59 is sleeping around
<jdub> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=146966
<AndyFitz> how promiscuous
<Mithrandir> *chuckle*
<jdub> everyone like february's calendar?
<wasabi> Wow
<wasabi> this CD upgrade stuff is awesome.
<wasabi> props to whomever is responsible for that
<AndyFitz> yeah feb calendar is great.   lots of colour integrity in the png too :)
<AndyFitz> jdub:  http://andy.fitzsimon.com.au/ubuntu-background-calendar-february.png
<daniels> jdub: sass.
<jba> hey guys, just popped in to say thanks for your help 2 days ago wrt DSDT
<jba> works a treat
<jba> finally got round to testing it
<jba> now how do I go about adding how I did it to the wiki?
<daniels> fabbione: oooh! oooh! oooh! still taking suggestions for patches while you're breaking ABI?
<tritium> mjg59, did you come up with anything you'd like me to test re: acpi-support?
<daniels> fabbione: http://lisas.de/~andi/acx100/acx100-0.2.0pre8_plus_fixes_45.tar.bz2
<mjg59> tritium: Not tonight, I'm afraid
<daniels> fabbione: acx111 is *apparently* usable with that (it actually recalibrates the radio; right now, it drops out randomly and I have to reboot to get it back, this is meant to fix that)
<tritium> no problem.  I've been trying a few different things on my own.
<daniels> fabbione: so if we could get that, that would be fantastic
<tritium> mjg59, surprisingly, I'm having better pwr. mgmt. results using NvAGP rather than agpgart with.
<mjg59> tritium: Really? That's kind of impressive
<tritium> (reverse the order of those last 2 words)
<tritium> yeah, I was surprised
<jdub> AndyFitz: yeah
<wasabi_> Should I be discussing hoary array 3 in the #ubuntu channel or here? (i have a problem)
<jba> jdub, thanks for the tip on dsdt, I was disbelieving that all i had to do was cat the file to initrd but it worked
<tseng> mako: that conference you mentioned...
<tseng> mako: if you look at the speakers list, im already signed up for 2 talks
<srbaker> shit
<mjg59> jba: Before Hoary, it ought to be possible to just copy your DSDT to a file and generate an initrd automatically
<srbaker> can someone echo their /etc/hosts here for me?  i removed mine, and i forget the default values
<jba> mjg59, i just didn't believe it could be that simple, but was happy when it worked
<mjg59> jba: We aim to make it simpler :)
<mjg59> Sadly, it's unlikely that we can make it automatic
<jba> yeah i read on the mailing list
<jba> sucks about the asl compiler
<jba> asl ? asml ?
<tseng> mako: ping me back then
<toresbe> hah, asl compiler
<toresbe> "I'm slowly unrolling the loops.... ooh, an integer! Increase, increase, HARDER"
<jba> toresbe, i don't get it
<daniels> crikey -- http://home.iprimus.com.au/remfrey/juliette/images/Melbourne_under_water.JPG
<toresbe> bash.org/?55178
<toresbe> hahahaha
<jdub> daniels: wtf?
<daniels> jdub: that's down by the yarra, near blue train
<jdub> Subject: [Bug 6117]   New: Xorg behaves unacceptably on mac mini
<jdub> ^ haha
<jdub> daniels: is that doctored?
<daniels> jdub: wettest february day on record; large chunks of melbourne (including most arterial roads) are underwater
<daniels> jdub: no, that was taken at lunchtime
<jdub> ouch
<jdub> wettest february and it's only the 3rd
<daniels> jdub: dude, the traffic announcements on the radio are taking like 20 minutes
<jdub> haha
* jdub has been in a rhythmbox bubble :-)
<tseng> jdub: dude.. muine4life
<jdub> haven't quite got the hang of the workflow yet
<jdub> i wish there was an "add everything and shuffle it" quick thingy for muine
<tseng> Play album, ctrl+a, enter, Ctrl+s
<tseng> but yeah
<tseng> playlist filling is on the Todo list, it will rock
<jdub> ahr
<tseng> think Party mode in itunes, but cooler
<daniels> heh 
<jdub> ctrl-s is not shuffle
<jdub> oh
<jdub> i need some new version
<jdub> right?
<tseng> ya, > 0.7.0
<tseng> i believe.
<jdub> i don't even have shuffle :)
<tseng> we need gtk-sharp2
<tseng> and then i can slap you some sweet muine love
<jdub> bong
<tseng> jdub: one sec
<jba> jdub, do you use totem to play movies?
<tseng> oh.. you cant install my bins
<jdub> yes
<tseng> i forgot.
<jba> and you got it it to use alsa, or esd ?
* lamont thinks he may be close to finishing his battle with backporting a postfix fix from 2.2
<daniels> jdub: (oh, and all access to tulla was blocked for a while, so flights were cancelled/diverted; the incoming road off the freeway was quite badly under water)
<tseng> http://getsweaaa.com/~tseng/muine/ has muine 0.8.0_pre1 debs
<tseng> if anyone is interested ill put together newer ones w/ sources
<jba> we got hail stones the size of tenis balls las night
<tseng> right now its just for personal use
<daniels> mdz: ping
<jdub> jba: both
* bluefoxicy is pondering whether to abandon gentoo or try splitting ubuntu 4G ubuntu 5G gentoo 1G swap. . .
<tseng> bluefoxicy: you will hurt with gentoo in 4G
<jba> then i must be doin something wrong :(, my totem just doesn't like alsa. i'll look into it later though.
<tseng> bluefoxicy: my /usr is usually 2G, and 1G in distfiles
<bluefoxicy> tseng:  5G
<bluefoxicy> Filesystem            Size  Used Avail Use% Mounted on
<bluefoxicy> /dev/hda1             7.5G  3.9G  3.7G  52% /
<tseng> that will be tight duder.
<daniels> jdub: unfortunately it wasn't as spectacular as the last one, which was localised to a point which floods *really* badly; the SES sent boats down the Eastern Fwy to rescue people stuck in their cars.  although this did happen: http://www.heraldsun.news.com.au/common/story_page/0,5478,12128331%5E2862,00.html
<bluefoxicy> tseng:  /var/tmp/ is a tmpfs
<bluefoxicy> I don't need any more than my static space
<bluefoxicy> tseng:  my biggest worry is 1) I lose ssp/pie for now, 2) I have to migrate thunderbird
<bluefoxicy> last time i tried ubuntu, thunderbird couldn't see my mailboxes
<bluefoxicy> (same /home)
<jba> i've been using the same .evolution folder since it was evolution on fc1
<bluefoxicy> maybe I just need to steal thunderbird 1.0 from hoary
<tseng> jdub: oh.. i think there is a curse on tomboy
<mdz> daniels: pong
<daniels> mdz: there are amd64 debs on concordia, could you please test them a bit?
<mdz> ok
<daniels> mdz: also powerpc just building now on davis; i386 works for me
<mdz> more specifically where?
* bluefoxicy gets hardened-dev-sources to use on ubuntu
<daniels> all the configuration stuff should work fine too, although I haven't tried qemu
<daniels> mdz: {concordia,davis}:~daniels/xorg
<mdz> has so much changed from the last release that it is necessary to test on all architectures before uploading?
<daniels> mdz: can't hurt.  in particular, phenomenal amounts of the debconfiscation have changed, so if I can exercise that some more and get any really stupid bugs out of it before I upload, sweet deal
<tseng> bluefoxicy: I need to work on getting that worked into an ubuntu kernel
<tseng> bluefoxicy: pitti started with just grsec, which would really be enough for me
<bluefoxicy> tseng:  he didn't make an amd64 one afaik
<tseng> build from source..?
<bluefoxicy> o.o
<daniels> mdz: (that being said, it worked in the configurations I could think of across my laptop and desktop)
<bluefoxicy> I'm going to use h-d-s for it, built from source
<tseng> ok, have fun applying the patches by hand :P
<bluefoxicy> what patches
* bluefoxicy has hds already
<bluefoxicy> it's on my /home partition
<mdz> daniels: at this point, if it fixes the dexconf bug, then it's better than what we have (for install and live CD testing)
* lamont gives up, heads to bed
<daniels> mdz: 'kay
<mdz> I'm downloading them and will give them a run, but I don't think you should wait for me to finish
<bluefoxicy> <Bluefox> i'm not very verbal
<daniels> mdz: right, my own hard deadline to upload is about 4:05 (32min)
<mdz> how long does the i386 build take?
<daniels> on my desktop, 1:43
<mdz> hmm
<mdz> lamont: will that make the cloop build?
<daniels> which is an athlonxp 2400+ (2ghz clock), with 512mb ram and a pretty shit disk
<daniels> dunno how fast it is on our buildds; i think around the 1:30 mark
<mdz> well, I can trigger those manually now
<mdz> so the bigger question is whether it'll be in the archive when I go to sleep tonight
<daniels> which is how long?
<mdz> probably not much more than 4 hours
<mako> tseng: ok.. sounds you got it covered then :)
<jdub> amu doesn't ship opencd stuff on gnoppix does he?
<mdz> gnoppix is currently nearly identical to the hoary live CD
<daniels> i'm going out the door (other house to clean up from flooding, power supply bits to hopefully get, pick up keys, hopefully an i845 as well) in 30min flat now
<jdub> mdz: har
<daniels> so it's going to be uploaded then, and 3:30 to get to the archite is pretty reasonable
<mdz> jdub: ?
<mdz> did you mean the morphix-based gnoppix?
<lamont> mdz/daniels: which package?
<tseng> mako: yeah, one question for you however
<mdz> lamont: xorg
<lamont> oh.
<lamont> livecd build happens at 0615
<lamont> which means the binaries for it need to be there by 0600
<mako> tseng: shoot
<tseng> mako: there are ~100 cds here now
<tseng> mako: 200 attendees
<jdub> mdz: that was a misspelt "ahr"
<lamont> xorg averages just over 1 hour, meaning that the source would need to be there by 0430
<daniels> lamont: it's 0437 now?
<tseng> mako: they said it took a few months to get the first batch, would it be possible to get some more by march 5th?
<mdz> yep
<lamont> daniels: yep
<daniels> lamont: how do you feel about kicking a new build when ubuntu13 lands?
<daniels> mdz: also, if you could test loading a configuration with 'Load "speedo"' still in it, I'd be indebted
<mako> tseng: yeah, no problem
<mdz> but since lamont has granted me the sword of pow^Wcloop-building, the daily cloop build deadline isn't so important
<lamont> daniels: I could slide it out 30 minutes, which should give you the time you need - will it be uploaded within the next 15 min?
<tseng> mako: sweet dude, could you look up the info for eric andreychek, or should we put in a new order?
<jdub> mdz: http://www.lacity.org/council/cd13/cd13press/cd13cd13press13227121_02022005.pdf
<jdub> GARCETTI, GREUEL, WEISS: FREE OPEN SOURCE SOFTWARE MEANS MORE POLICE ON THE
<jdub> STREETS COUNCIL BETS THAT OPEN SOURCE MOVEMENT CAN SAVE CITY MILLIONS
<jdub> 
<jdub> "FOSS means more caps to pop in your ass."
<mdz> that's serious propaganda
<daniels> jdub: represent
<mdz> OPEN SOURCE FEEDS BABIES
<daniels> lamont: no
<mdz> YOU DON'T WANT TO STARVE THE BABIES, DO YOU?
<daniels> lamont: it'll definitely be there within about 30min
<tseng> open source found me a new kidney
<mdz> I woke up in a tub of ice and open source had stolen my kidney
<mdz> a conspiracy!
<tseng> oh snap, i have a minor FOSS celebrity's right kidney
<lamont> mdz: I could just schedule the build for 0710, which _should_ finish in time for the daily CD build of Kamion's
<mdz> oh, that's in LA. rad.
<jdub> haha
<mako> tseng: i am happy to resend to anyone.. what i need is a message with (a) the email used to make the order (all the data up to date etc) (b) mention that it's a high priority (c) mention if that account has already recieved cds.. send it to mako@canonical.com and it'll be done in a heartbeat.. go out with the next shipment
<tseng> mako: wonderful, thanks a metric ton and 3 quid.. or something
<mako> mdz: you want more cops?!
<jdub> ok
<jdub> something is spiking cpu every 2s
<mdz> jdub: so I guess I should trudge down to city hall and bring a stack of Ubuntu CDs
<jdub> oh
<jdub> 3ddeskd
<jdub> bah
<jdub> mdz: elite!
<mako> mdz: bring extra, i hear the police's ranks are swelling
<jdub> mako: flanks, the police's flanks are swelling
<jdub> mmm, doughnut
<jba> hey jdub, does canonical have an aus office, or do you telecommute?
<jdub> jba: the entire company telecommutes :)
<tseng> jdub mdz .. there is a curse on tomboy, apperantly. the build dep is libpanel-applet2-dev.. mdz uploaded as libpanel-applet-dev, after I already effed it twice, and one miss-upload. im going to make it sit in the corner for being bad
<jdub> jba: also, my house is the .au head office
<jba> that's what I love about the os model, everything is designed around the concept of detached, distributed development
<bluefoxicy> tseng:  inside Project Eden (a European dome city project), they try to avoid all references to christianity.
<jba> jdub, cool
<tseng> if either of you can help me rectify once and for all, thatd be rad
<jba> you get many ausies in here?
<jdub> tseng: want me to do a quick fix?
<jba> s/ausies/aussies?
<tseng> jdub: yeppers
<daniels> jba: a couple, yeah
<daniels> jdub: it so is not
<jdub> jba: heaps. australia provides roughly 10% of the FOSS development community.
<daniels> jdub: melbourne 4 lyf
<tseng> bluefoxicy: thats.. interesting
<mako> MAKO BETS OPEN SOURCE MOVEMENT WILL SPELL BOON FOR DOUGHNUT INDUSTRY
<lamont> mdz: unless you say otherwise, I'll let the cronjob run as scheduled, and you can kick it again when you want.  or Kamion can
<tseng> jdub: give it a quick spanking also.
<tseng> jdub: bad tintin
<jdub> we should so get a new icon for it
<YokoZar> jdub: did you get a chance to look at winetools?
<tseng> tomboy is the redheaded stepchild of ubuntu
<jba> i'm from sydney myself. my first real oss influence was pptpclient and then mono, and monodevelop
<mdz> tseng: dude, aren't you supposed to be able to upload to universe now?
<tseng> jdub: jimmac made one
<tseng> mdz: i have to jump a hoop yet
<mdz> tseng: key?
<jdub> tseng: yeah?
<tseng> mdz: yes.
<jba> jdub, the .au office is in melbourne or sydney?
<bluefoxicy> tseng:  they renamed christmas to "the season of gifts" to avoid christianity references inside an ecodome project named after the setting of the book of Genesis
<tseng> jdub: yeah, ill go digging for it
<mdz> tseng: tried biglumber or debian?
<jba> tseng, orph (in #mono) who wrote tomboy (iirc) reckons it targets gtk-sharp not gtk-sharp2
<jdub> jba: sydney, of course. melbourne is just a runt city.
<jdub> jba: with delusions of grandeur.
<jba> hehe
<tseng> mdz: im planning to get the CoC and my key id notarized tommorow and mailed to mark
<jdub> jba: we were talking about muine and gtk-sharp2 before
<mako> bluefoxicy: well, genesis existed a long time before christianity
<jba> jdub, melbourne has some devent developers in them, all that rain breeds a computer addicted society
<jdub> tseng: notarised and mailed to mark?! :)
<tseng> jdub: yeah?
<bluefoxicy> mako:  Lies, sega started in 1987  :)
<mdz> tseng: -0ubuntu4 uploaded
<jdub> tseng: intense :)
* jba hasn't used muine yet
<tseng> mdz: thanks again
<jba> i can't even get totem to use alsa and the w32codecs, so I figured I'd leave muine for a while
<mako> jdub: dude, it's because then sabdfl will sign his key (and by doing so give elmo a heart attack)
<jdub> mdz: argh, i was just uploading it
<jba> the kill mono app I reckon will be beagle... and monodevelop
<tseng> jba: no.. muine is the one true god
<tseng> you will have no gods before muine
<jba> i should try it, but linux +  multimedia is always so hard for me to figure out
<jba> and being married doesn't help either, hardly any time to commit to oss
* daniels boggles.  non-geek friend:
<daniels> (15:48:33) ash - fuckin posers: btw abs is about to install some cheesy linux on my computer
<daniels> (15:48:55) ash - fuckin posers: abs: it's ubuntu live (warty), no installing it, just a preview for ash
<jba> so what happened between warty and hoary that made the intro music disappear when i log in?
<tseng> jba: muted alsa mayhaps?
<mdz> does sound work otherwise?
<jba> tseng, yeah I know that's the cause, but why did that change?
<jba> actually muted pcm in volume-settings applet
<jba> and muted master
<tseng> jdub: http://primates.ximian.com/~jimmac/blog/2004/Nov/01
<jba> was asking more on a political level, than a techincal question, cause quite clearly warty wasn't muting alsa
<tseng> jdub: mxpxpod had to do a bit of hacking to get the size right iirc
<jba> you guys know that beagle can now filter tomby notes as well
<jba> ?
<tseng> yes, we did.
<tseng> ( i speak for the entire room btw )
<daniels> (i didn't.)
<jba> i'm still waiting for zac to smoothen up his gtkmoxembed stuff for windows, so i can use beagle on my office desktoip
<mdz> jba: there was a bug at one point which caused sound to be muted, and saved as muted to disk
<mdz> jba: what does "debconf-show alsa-base" say?
<jba> 1 sec will boot it
<tseng> jdub: see the last post on that page.. crack
<smurfix> eh, cool -- start XMMS, xorg segfaults. That's a new one.
<smurfix> ... and of COURSE the problem goes away once I attach gdb to it. *sigh*
<tseng> jdub: http://primates.ximian.com/~jimmac/blog/Artwork/LowresTomboy applies also
<jba> mdz, it says "....on_shutdown: never autosave"
<jdub> tseng: aha, now that's more useful (for applet and nicon)
<tseng> yes.
<jdub> tseng: let's do it :)
<mdz> jba: sudo dpkg-reconfigure alsa-base, select "autosave always"
<jba> mdz cool thanks will try it
<mdz> otherwise it'll boot up muted forevermore
<jba> sweet, it was that easy
<jba> obviously it was an unattended synaptic install all upgradeable packages that caused it
<daniels> lamont: uploading u13 now
<mdz> the package was buggy for some indeterminate period of time
<mdz> and unfortunately the bad default setting was saved
<jba> fuck, I did something to my alsa when i tried to install the restricted file formats
* jba apologises for the expletive
<mdz> ah, hmm
<mdz> daniels: I won't be able to test amd64 at the moment
<mdz> it's hosed due to that grub segfault bug
<mdz> (half-installed)
<daniels> mdz: ok, nevermind
<daniels> lamont: u13 upload finished, have at it
<tseng> jdub: mxpxpod already hacked in these icons.. i dont have his source packages around. =/
<YokoZar> jdub: pong
<mdz> daniels: dpkg-reconfigure xserver-xorg gets me 640x480 on my powerpc-behind-KVM
<mdz> where previously it did 1600x1200 without complaint
<daniels> mdz: hmph.  what does sudo ddcprobe say?
<mdz> oem: ATI Radeon If
<mdz> memory: 0kb
<mdz> noedid
<jdub> YokoZar: yo
<YokoZar> jdub: Get a chance to install winetools yet?
<mdz>   xserver-xorg/config/monitor/horiz-sync: 30-75
<jdub> YokoZar: nup
<YokoZar> It should be a point and click setup, though I'm not quite sure if the menu entry is in the right place.
<daniels> mdz: if you reconfigure -plow you should be able to beat 16x12 into it; by the looks there's simply no way we can get ddc out of it
<daniels> mdz: if ddcprobe ever succeeded, that means the kernel's regressed
<jdub> YokoZar: ouch dude, gtk1.2
<daniels> mdz: (hm, 0kb.  are you on a laptop that you've suspended?)
<mdz> daniels: I believe that, but what used to happen was that it would ask me the mode question, I would select 1600x1200, and it would give me 1600x1200
<mdz> daniels: no, powerpc desktop
<daniels> mdz: righto.  will look into the not-prompting thing.
<YokoZar> jdub: ?  I didn't write it, just packaged it.  I'm not sure why it's based around Xdialog
<daniels> mdz: that being said, if you get to select your mode (i.e. configure with -plow), then it should write out a config file that will let you use it
<jdub> YokoZar: it could be ported to zenity :)
<jdub> though xdialog doesn't explain gtk1.2
<mdz> daniels: oddly enough, no
<mdz> I went through 'advanced' and entered the sync ranges manually
<mdz> and I still get 640x480
<mdz> you want config+log?
<mdz> it didn' t write out the sync ranges I specified at all
<mdz> mdz@max:/tmp$ grep -i sync /etc/X11/xorg.conf
<mdz> mdz@max:/tmp$
<mdz> Section "Monitor"
<mdz>         Identifier      "Generic Monitor"
<mdz>         Option          "DPMS"
<mdz> EndSection
<daniels> mdz: not really, if there's no sync ranges, then xserver-xorg/config/monitor/use_sync_ranges isn't set when it needs to me
<daniels> i'll test this weirdo corner case here (replace ddcprobe with a very small shell script)
<jdub> YokoZar: works with the debian menu
<YokoZar> jdub: maybe it's time I upgraded to hoary, heh
<jdub> daniels: have to scroll so far to see the xorg changelog
<tseng> i hit end and go back up
<jdub> daniels: i consider this a serious bug
<fabbione> ROCKING!
<fabbione> now we even get the inotify preview patches!
<syn-ack> I know that this is not an Ubuntu specific issue, but whats up with the ACPI bug that still not working right after kernel 2.6.6, iirc it was that worked fine.
<tseng> syn-ack: the what?
<tseng> you'll have to get alot more specific, or look upstream
<fabbione> syn-ack: we have a set of patches pending for it
<tseng> hah, at least someone knew what he meant.
<syn-ack> tseng: Theres a bug in the kernel acpi code thats not updating correctly, so it wont show the correct battery status, in my case, I have to do something like brighten or dim my LCD for it to update.
<jba> mdz, thanks mate, got my alsa sound working and rememberin it's last setting
<syn-ack> fabbione: aha.
<syn-ack> fabbione: man, I will SO beta that for you. :p
<jba> only problem now is that totem says 'alsa device "default" is already in use by another program'
<tseng> jba: esd running?
<jba> don't think so, how to check that?
<crimsun> pgrep esd; lsof /dev/dsp*
<tseng> or more point and click, desktop -> prefs -> sound
<jba> aah the sound server, yeah it's running, and plays sounds
<tseng> yeah um
<tseng> now desktop -> prefs -> multimedia systems selector
<tseng> swap default output sink to esd
<crimsun> [may I recommend polpyaudio instead? it doesn't hog the sound device by default, though you can configure esd to release it after a time period iirc] 
<tseng> and try totem again.
<crimsun> polypaudio^
<jba> tseng, that works, does using esd mean I
<jba> 'm still using alsa though?
<tseng> great
<daniels> mdz: i am fucking awesome.  fixed locally; thanks for the pointer.
<tseng> jba: esd is using alsa
<tseng> so indirectly, yes
<jba> i though esd was for oss ?
<jba> anyhow never mind, thanks dude
<tseng> well, it might do oss emulation
<tseng> but its all alsa in the end
<crimsun> (by default esd is configured to use ALSA's OSS emulation)
<jba> crimsun, polypaudio?
<tseng> jba: you can turn off esd in that dialog i showed you, and in system selector you can pick straight alsa
<crimsun> jba: esound's replacement down the road
<daniels> mdz: with xresprobe rigged to fail, at high priority, we now prompt for the mode and write out sync ranges
<jba> crimsun, is esd the reason why people cant get software mixing of sounds ?
<tseng> jba: no, esd is software mixing
<crimsun> jba: actually it is
<tseng> alsa doesnt do it on some hardware
<tseng> which is why esd exists
<jba> tseng, on the mailing list, and forums people have been claiming they can't
<tseng> but crimsun is a sound expert, so ill go shutup
<crimsun> hardly an expert :p
<HrdwrBoB> jba: they're probably confused
<tseng> jba: then the app isnt using esd, id guess
<HrdwrBoB> esd software mixes
<HrdwrBoB> however you can't just open /dev/dsp again
<jba> HrdwrBoB, i don't know dude, I'm just trying to "learn from the community"
<crimsun> jba: ALSA provides similar mixing capability in the form of an ALSA library-level plugin called "dmix", but it's far from complete, though "it works in most cases if you follow some constraints"
<jba> crimsun, yeah I read about that too, i'm trying not to stray too far from a default laptop installation
<jba> trying to convince guys at my office that linux is/ or will be in near future a viable platform option for us
<syn-ack> jba: Why wouldnt it be now?
<crimsun> jba: ubuntu has a fairly sane default config by using esd; if you plan to use recording capabilities, however, esd will present problems
<jba> syn-ack, crimsun: specifically because some of the hardware we use is not linux compatible
<jba> for example my dsdt issue earlier this week.
<syn-ack> jba: ouch
<jdub> jba: easy fix though
<jba> jdub, yeah easy fix for me, but I know linux
<jba> a windows only admin aint gonna belive me
<jdub> jba: we can make that better, too
<HrdwrBoB> esd->OSS emulation->alsa->hardware
<jba> I've been using linux for a while, and still didn't know about esd/alsa stuff either
<jdub> mjg59: tune in if you're around
<jdub> so what i'm thinking is
<jba> s/a windows only admin/our windows only admin
<jdub> if you put DSDT.aml in your /etc/mkinitrd,
<jdub> an additional mkinitrd script tacks it on the end
<jdub> thus working forever
<jdub> with every kernel upgrade
<jba> jdub, you'll need to have already compiled it though, that's the dirty part
<jdub> perhaps
<jdub> but we can ship or provide those
<jdub> in some other fashion
<jdub> it's just a binary firmware issue, really
<jba> on bugzilla they were saying that shipping them may have copyright issues
<jdub> as does shipping binary firmware
<jba> but hey, can I do this /etc/mkintrd perpetual kernel fix now ?
<jba> or is it not yet ready for that?
<jdub> not ready yet
<jba> the reason i like ubuntu is cause it has eye-candy and enterprise deployment/management potential
<jba> it's just a matter of convincing this windows admin of that fact
<tseng> those things are certainly co-dependent
<fabbione> jdub: we have a high probability to get inotify fixed
<jdub> tseng: chuckle
<jba> every time i have an issue with our network, hey says "cause your using that damn linux"
<jdub> fabbione: rml's giving you the love?
<jba> eediot
<fabbione> jdub: we are working together on fixing it.
<Treenaks> jba: scary
<jba> jdub, also from the list, YAST apparently lets you procide the path to the DSDT file, and it does the initrd tackinf for next reboot
<jdub> next reboot? ew.
<jba> ew ? it's a laptop
<jba> prolly the same thing as your /etc/mkinitrd, except it allows the DSDT file to sit anywhere
<jdub> and makes you cruelly aware of it, etc.
* jdub doesn't care where is firmware lives, and is better off for it
<jba> hehe, well i would rather be aware of it, than have aboslutely no clue that it aint gonna work :)
<daniels> mdz: ok, a few debconf cleanups done, but i hardly think they're important enough to warrant an ubuntu14 upload now
<jdub> jba: it should just work, that's the point
<jba> sometimes i think.. rather than change the people in my company's attitude that I would be better off changing my company
<jdub> daniels: i'm being bothered by hostinggeek about banning
<jba> but every company is the same (especially when you have a managed run time background).
<jba> they're either all java shops or all ms shops
<fabbione>    * Move *.1 manpages to *.1x, a change that got lost from xfree86->xorg.
* fabbione larts daniels with a cluebat
<daniels> fabbione: look a little closer
<fabbione> that was done upstream
<daniels> fabbione: in xfree86.cf, we remove AppManSuffix 1, which is why it gets forced to 1$(ProjectManSuffix) (i.e. 1x)
<daniels> but we didn't mirror the same change in xorg.cf, so AppManSuffix was getting forced to 1
<fabbione> AHHHH
<daniels> it was a side effect of not mirroring *all* the xfree86.cf changes to xorg.cf
<fabbione> GOTTA LOVE COHERENCE IN XORG
<fabbione> same shit as the fonts and the XF86CUSTOMVERSION
* fabbione sighs
<jba> jdub, to be fair though, the DSDT issue isn't really linux's fault
<fabbione> daniels: did you remember to update all the manifest files?
<jba> manufacturers with buggy DSDT implementations really should be accountable
<daniels> fabbione: yeah, plus *.install*
* fabbione pats daniels 
<daniels> fabbione: sailed through file on i386/powerpc/amd64 at least, and I made sure that ia64 and sparc didn't get damaged as well ;)
<daniels> fabbione: yeah, the XF86CUSTOMVERSION thing is annoying
<daniels> fabbione: xfree86.cf vs xorg.cf blows my mind.  why they still have two is amazing.
<daniels> oh well, yay imake!
<jdub> so mkinitrd has no ability to handle post-image-building customisation
<dholbach> morning!
<jba> who's decision was it to ship pptp 1.5 with hoary, by the way? that was a good decision
<jba> so much better
<daniels> fabbione: i've got the sparc iso now, but i've spent 26 of the last 31 hours doing xorg, xresprobe or l-r-m, so I'm not going to install it tonight ;)
<jdub> "First Graphical LiveCD For The PowerPC By Gentoo"
<jdub> on slashdot under games
<fabbione> daniels: i suggest you to wait anyway
<fabbione> daniels: Kamion is fixing the last bits in d-i
<tseng> jdub: gentoo had a graphical livecd for ppc long before that one (or ubuntu)
<daniels> fabbione: oh sweet
<fabbione> daniels: so the installation will be a breeze
<tseng> jdub: so it may be accurate, but only by mistake
<fabbione> daniels: it's missing a new choose-mirror and a new d-i upload
<fabbione> daniels: all the rest should be there
<fabbione> daniels: otherwise you need to hack a bit manually
<Treenaks> where can I find the list of natively-supported-by-Xorg ATIs?
<fabbione> isn't the madwifi driver in l-r-m?
<mdz> yes
<fabbione> hmmmm
<daniels> fabbione: yah, why?
<daniels> Treenaks: 'all of them'
<daniels> Treenaks: in terms of 3d, anything up to r2xx (which is up to and including radeon 9250)
<fabbione> daniels: 6108
<daniels> fabbione: whoohoo ;)
<bluefoxicy> tseng:  complete and total ass
<bluefoxicy> tseng:  I found the problem:  gentoo uses ~/.thunderbird, ubuntu ~/.mozilla-thunderbird
<bluefoxicy> woh the hell or how the hell did that, I don't know
<tseng> um, ok
<fabbione> humpf...
<fabbione> inotify -14 still doesn't fix the crash
<dilinger> fabbione: what's w/ the push to get inotify in shape?
<fabbione> dilinger: because we ship it? ;)
<fabbione> and it's the only critical bug for the kernel
<fabbione> + the amd64 ia32 emulation that is utterly broken in 2.6.10
<fabbione> (and the debian patch does not fix it)
<dilinger> right.  why do you ship inotify? :)
<fabbione> dilinger: ask jdub :-)
<fabbione> 1t'5 t0t477y r4d
<dilinger> heh
<fabbione> s0 r4d 7h47 br34k5
<tseng> it will be totally rad when it works right
<fabbione> tseng: it does.. it breaks when you remove a fs below it's monitoring
<fabbione> at least now i can a) reproduce b) debug
<dilinger> jdub: is this to get rid of famd or something?
<tseng> atm gamin doesnt work with inotify apperantly =/
<tseng> but that was part of it (beagle as well)
<fabbione> tseng: they have been disabled since inotify is broken
<jdub> dilinger: it replaces dnotify
* tseng nods.
<dilinger> jdub: right
<jdub> fabbione: current gamin uses inotify
<dilinger> jdub: that doesn't answer my question, though
<jdub> dilinger: gamin, which replaces fam, uses inotify or dnotify
<dilinger> ok
<jdub> dilinger: we ship inotify because it is a more scalable and less breakable interface than dnotify
<fabbione> given that it works :-)
<bluefoxicy> huh
<bluefoxicy> what the. . .
<bluefoxicy> gtk-gnutella-0.95-2 from hoary universe
<bluefoxicy> installs no binary?
<zenrox> noooo a reboot
<tseng> brace for impact.
<zenrox> hehehe
<gustavor> mdz, hi matt
<mdz> gustavor: hello
<gustavor> mdz, I believe there is a problem with uml-utilities package
<mdz> the problem with the uml-utilities package is that its maintainer is very busy ;-)
<gustavor> mdz, I see
<gustavor> mdz, I think it a very simple fix
<gustavor> mdz, should I file a bug in bugzilla? then you can have a look?
<mdz> gustavor: debbugs is fine for uml-utilities
<mdz> thanks
<dholbach> is there any reason why a check in configure.in like COASTER_PKG_PATH_PROG([XML_CAT_PROG] , [libxml-2.0] , [xmlcatalog] ) wouldnt work in pbuilder? (for testing reasons i put libxml2-utils in depends and build-depends)
<mdz> COASTER_PKG_PATH_PROG is a custom macro, so it could have any number of problems
<mdz> it looks like _maybe_ XML_CAT_PROG should not be quoted
<mdz> but it depends entirely on how COASTER_PKG_PATH_PROG is written
<bluefoxicy> I can't
<bluefoxicy> friggin
<bluefoxicy> get rhythmbox to do mp3s on this system wtf
<dholbach> it works nice with  debuild  or in a normal ./configure && make && make install  run
<bluefoxicy> gimme a hint, what do I apt-get
<tseng> bluefoxicy: install gstreamer0.8-mad or so
<dholbach> bluefoxicy: it's on the wiki too
<tseng> bluefoxicy: this is an faq bit
<tseng> yes.
<bluefoxicy> thanks
<bluefoxicy> I got like, gstreamer0.6-mad or something
<bluefoxicy> so I was like 'Wtf I installed gstreamer mad'
<tseng> 0.6 is old old
<dholbach> mdz: thanks... i found out, i could --disable-update-xml-catalog
<bluefoxicy> i've screwed this system up already, wanted newer shit
<bluefoxicy> I still want mozilla firefox but
<bluefoxicy>   mozilla-firefox: Depends: libgnomevfs2-0 (>= 2.9.90) but 2.8.2-0ubuntu1 is to be installed
<bluefoxicy> trying to steal hoary's for warty
<tseng> you cant do around installing half stuff from hoary
<bluefoxicy> tseng:  I have the hoary repository
<tseng> you have to backport it, or deal with the full upgrade
<tseng> bluefoxicy: hoary doesnt have 2.8.2, duder.
<bluefoxicy> exactly
<bluefoxicy> it's simply not there
<zenrox> ya tseng  is right
<bluefoxicy> so i'll have to wait a while :/
<tseng> so stop screwing arund with a half upgrade
<zenrox> just go full bore dist-upgrade
<bluefoxicy> hoary breaks
<fabbione> guys can we kindly move this topic to #ubuntu?
<jdub> bluefoxicy: hoary breaks less than a halfbreed
<jdub> bluefoxicy: this is really a #ubuntu issue
* tseng waves bluefoxicy goodbye.
<bluefoxicy> bai
<jdub> http://spooky-possum.org/cgi-bin/pyblosxom.cgi/rewinddir
<jdub> mdz: ^
<sivang> Morning all
<mdz> jdub: minii_fo is so fucked
<mdz> I'd like to point out that this problem can't exist on the hoary live CD, but it's broken :-/
<mdz> jdub: gentoo has had a powerpc livecd for ages, as far as I'm aware
<mdz> jdub: first "graphical" live CD?
<jdub> mdz: very confused news item, so it seems
<jdub> minii_fo?
<mdz> 24 comments, 2 ubuntu mentions ;-)
<mdz> mini_fo is the broken filesystem overlay module that the Warty live CD used
<jdub> aha
<mdz> which is surely responsible for weird readdir bugs
<jdub> "but it's broken" was in reference to?
<mdz> the hoary live CD
<mdz> no X at the moment
<jdub> oh
<jdub> oh right, broken for other reasons :)
<mdz> broken in more obvious ways
<mdz> xorg/amd64 built
<mdz> lamont: did you set Kamion up with cloop build access?
<fabbione> bah
<fabbione> let's give acpi some love
<jdahlin> acpi is in desperate need of it
<jdahlin> (at least on my box)
<bob2> everyone should just buy x40's
<bob2> then they don't need to complain
<jdahlin> is it even flawless on x40's?
<bob2> jah
<sivang> bob2: wowo, I should get one myself....how much does it cost from where you are?
<bob2> too much
<bob2> ($au3400)
<sivang> errr
<sivang> grrr
<bob2> down to $us1000 or so
<lifeless> and its a uk one. for an aussie.
<dholbach> hi sivang
<bob2> you'll note I don't have any screen cracks, tho.
<lifeless> bob2: you'll note my conspicuous absence of a pound symbols
<jdub> bob2: LOGICALLY you would NOT
<bob2> hahahahahahaha
<pitti> Morning
<dholbach> hi pitti
<jdahlin> I gave away a few ubuntu CDs to some chinese people today, they seemed very surprised that you could get them for free
<jdahlin> one of them even asked if a license key was needed...
<sivang> jdahlin: hehe
<sivang> Morning pitti!
<sivang> morning dholbach 
<fabbione> 2.6.11 is gonna be out pretty soon....
* sivang sounds drums rumbeling
<dholbach> morning mvo_
<mvo_> hi dholbach 
<sivang> hey mvo_ 
<mvo_> hi sivang 
<amu> jdub: gnoppix ships the opencd stuff also, cause its soo cool 
<jdub> amu: :-)
<jdub> amu: what did you ship on previous versions of gnoppix that is not in the ubuntu desktop or live seeds?
<sivang> amu: yes, opencd is the coolest:)
<amu> jdub: another theme, the restricted drivers, and a lot of preconfigs   
<fabbione> mjg59: confirmed that the new ACPI fixes the battery status
<jdub> amu: no extra apps?
<mdz> gah
<mdz> X still broken with ubuntu13
<jdahlin> fabbione: just curious, what kind of issues?
<fabbione> jdahlin: 5807
* jdahlin has some problems related to battery status on a standard warty kernel
<fabbione> this is hoary
<Treenaks> jdahlin: ASUS laptop?
<jdahlin> Treenaks: fujitsu-siemens
<Treenaks> jdahlin: I know asus DSDTs are known to be buggy
<Treenaks> dunno about f-s
<jdahlin> fabbione: okay, that's different from mine
<Treenaks> gah! has ldconfig forgotten how to cache?
<jdahlin> guess I should file that one in bugzilla
<mvo_> mdz: did you had time yet to look my changes for #5668 (apt-cdrom & authentication)?
<Treenaks> "Setting up libx[something] " takes AGES.. for each of them..
<mvo_> s/to look/to look over/ :)
<fabbione> jdahlin: please test a hoary kernel before opening a bug
<fabbione> that would be the first thing we would ask you to do
<mdz> mvo_: only a bit
<amu> jdub: not defined now, i hope Luis helps    
<jdahlin> fabbione: ok. I'm about to upgrade to hoary.
<mdz> currently, my priority is to get the live CD un-broken
<mvo_> sure, I don't want to rush you
<jdub> amu: no, i mean, did you have extra apps on the previous gnoppix cds
<fabbione> mdz: the next kernel will break the ABI..
<mdz> mvo_: can you do an installation test using your patched apt?
<fabbione> mdz: how much time do you want to fix the livecd?
<mvo_> mdz: does that require building my own install cd?
<amu> jdub: nothing, which you can't get from archive or debian pool
<fabbione> daniels: are you still around?
<jdub> amu: hrm, perhaps i'm not being clear
<Treenaks> hm... it's really ldconfig taking ages.. and re-doing whatever it does with EVERY package
<fabbione> Treenaks: you can't avoid that
<fabbione> and it is required
<jdub> amu: did pre-ubuntu gnoppix releases have additional packages installed?
<mdz> fabbione: daniels has probably passed out
<Treenaks> fabbione: it used to be slow only the first time, and cached after that ("Hey! Libraries haven't changed, so I don't need to run!"-style)
<mdz> and I now need to do what I asked for in the first place
<mdz> which was to fix the trivial dexconf bug and leave the other things out
<fabbione> mdz: want me to take a look?
<mdz> fabbione: I know the bug and how to fix it.  it is just that daniels rewrote postinst at the same time, and introduced new bugs
<fabbione> ah ok
<mdz> so I am reverting -1ubuntu13 and applying only the fix
<fabbione> mdz: ok. do you have the baz repo handy?
<amu> jdub: "pre-ubuntu gnoppix" ? we're talking about older, stable or upcomming versions?  
<fabbione> hmm no.. daniels didn't commit to baz
* fabbione sighs
<fabbione> brb
<jdub> amu: older stable versions
<amu> jdub: sure, there are a lot of extra packages compared to our new or old liveCD
<jdub> amu: can you let me know what isn't covered by the packages listed in the live seed?
<jdub> anyone have sid handy?
<jdub> n/m
<Treenaks> jdub: well.. yes.. why?
<jdub> Treenaks: apt-cache search clear looks throw up anything?
<mdz> Kamion: awake?
<Treenaks> jdub: mozilla-diggler - A set of URL manipulation utilities for Mozilla's location bar
<jdub> Treenaks: thanks
<Kamion> mdz: yo
<Kamion> just woke up
<sivang> hey Kamion , morning
<mdz> Kamion: morning
<amu> jdub: sending you the packagelist for 0.6 and 0.7, gimme 1h      
<mdz> was just sending mail
<Kamion> ok
<jdub> mdz: ok
<jdub> er
<jdub> amu: ok, thanks
<fabbione> jdub: can you try to install ubuntu-desktop on sparc? it should be working today :-)
<jdub> fabbione: ok, will do later :)
<jdub> in off-peak :)
<mdz> Kamion: I just uploaded xorg 6.8.1-1ubuntu14
<fabbione> jdub: :-)
<mdz> Kamion: which needs to make its way onto a new set of live CDs at the earliest opportunity
<Kamion> mdz: lamont did give me access to kick the cloop builds
<mdz> Kamion: lamont set you up with the capability to trigger cloop image builds, right?
<mdz> great
<Kamion> so if you want to go to sleep I can certainly shepherd those
<Kamion> might decide to do array 4 today, maybe
<mdz> that's my plan (sleep)
<mdz> I'd like to do a combined install+live  release for array 4
<fabbione> mdz.sleep()
<Kamion> mdz: yes, likewise
<mdz> so if you can organize a round of live CD testing, or wait until I wake up so that I can do it, that'd be best
<fabbione> Kamion: do you think it is reasonable to plan some sparc CD's AFTER array4?
<mdz> I hope that -1ubuntu14 will at least get us back to array3.5 status
<fabbione> mdz: i can help Kamion to test...
<Kamion> fabbione: sure, can do
<fabbione> Kamion: that would be awesome
<fabbione> anything i can do to help you there? or is it all DC located?
<Kamion> it's all DC located
<fabbione> ok
<mdz> ok, night all
<mvo_> night mdz 
<mdz> and good luck
<fabbione> night mdz
<sivang> night mdz 
<jdahlin> Is xfree86 or xorg recommended for hoary?
<d3vic3> W: Couldn't stat source package list http://archive.ubuntu.com hoary/main Packages (/var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_hoary_main_binary-i386_Packages) - stat (2 No such file or directory)
<d3vic3> anyone have an idead about that ? 
<fabbione> jdahlin: hoary has xorg, but please these questions are for #ubuntu
<fabbione> d3vic3: apt-get update
<mvo_> d3vic3: have you called "apt-get update"
<d3vic3> yes
<d3vic3> still gives same error 
<fabbione> check the sources.list
<jdahlin> fabbione: sorry, I just wanted to know which one was fully supported since I was given a choice
<d3vic3> looks fine 
<fabbione> hoary has no choise.. it is xorg by default
<jdahlin> I got a dialog when upgrading.
<fabbione> xfree is in universe -> not supported
<jdahlin> ah
<d3vic3> Failed to fetch http://archive.ubuntu.com/ubuntu/dists/hoary/main/binary-i386/Packages.gz  MD5Sum mismatch
<d3vic3> fabbione, sources.list looks fine, but still give that error 
<fabbione> d3vic3: are you behind a proxy?
<fabbione> if so it's the cache that is broken
<d3vic3> I use a firewall not a proxy 
<Kamion> archive.ubuntu.com's been randomly broken of late due to enormous load, I think
<Kamion> s/broken/out of sync/
<Kamion> d3vic3: might want to try using a mirror instead
<d3vic3> where is the mirror list? 
<Hwolf> The one advantage Debian has over Ubuntu right now is the massive mirror infrastructure
<Hwolf> Ubuntu would do well to get some mirrors up, and add them to the Hoary installer.
<Kamion> d3vic3: either http://www.ubuntulinux.org/download/ or http://www.ubuntulinux.org/wiki/Archive
<Kamion> Hwolf: we *have* mirrors; I was vetoed from having the mirror question in the installer though
<Hwolf> Kamion. I've tried looking for the mirrors, but could only find 'download install cd' mirrors
<maswan> Kamion: The more user-friendly approach would be adding redirect support and let archive distribute the load among mirrors, IMO
<Hwolf> kamion: How where they planning to cope if Ubuntu really takes of, then?
<maswan> Hwolf: http://www.ubuntulinux.org/wiki/Archive
<Hwolf> maswan: And what if the nearest archive selected by the installer is a massivly slow server? For debian I pick the university's server rather then my old isp's
<Kamion> Hwolf: vetoed => go talk to Mark :-(
<Hwolf> Kamion: does he read the mailing list?
<Kamion> maswan: yeah, that might work ...
<Hwolf> -devel, that is?
<Kamion> Hwolf: yeah
<maswan> Hwolf: Then you have an incentive to google for ubuntu mirror
<Kamion> Hwolf: though don't phrase it as "oi, Mark, ..." :-)
<Hwolf> maswan: I could. But every one of those 1300 people a day that read about ubuntu on distrowatch might not...
<maswan> Kamion: In my opinion, that's a better and more flexible approach than round-robin dns at least.
<maswan> Kamion: You can even do smart selection, given a smart server.
<Treenaks> maswan: http://www.globule.org/
<d3vic3> Kamion, the mirrors give more errors 
<Hwolf> hint: Make sure the master server's integrity is intact before rsyncing the mirrors. 
<maswan>  Treenaks Yeah
<Hwolf> An issue I see is that hoary users will automaticly run a cronjob every day, so it can be assumed that load on the servers will increase.
<Hwolf> dramaticly
<jdub> amu: holy crap, the difference is huge
<Kamion> Hwolf: yeah, that was brought up in one of the meetings at Mataro
<Kamion> elmo: mind if I make up a Mirrors.masterlist.ubuntu out of whole cloth and the various wiki pages etc., for use in choose-mirror and base-config? I don't necessarily expect it to be totally current all the time, but it can be updated just before release and stuff
<fabbione> are we actually monitoring our mirrors to know if they are alive/in sync?
<amu> jdub: yes it is     
<Hwolf> fabbione: I'd hope so
<Kamion> fabbione: I think that's one of the things elmo does; dunno
<Kamion> IIRC Debian have various automatic mirror monitoring scripts
<Kamion> fabbione: ah, didn't realise there was a bug about the serial console thing, thanks
<fabbione> Kamion: ehhe no problem :-) i submitted it as reminder.. nothing mor
<fabbione> more
* enrico wakes up
<enrico> jdub: did you create the ubuntu-doc-commits list and tell the address to Elmo?
<jdub> enrico: not yet
<enrico> I'd like to announce today the migration scheduled for monday: do you think you can make it so that monday everything is ready?
<jdub> yep
<jdub> sorry, busy day
<jdub> will do it tonight
<enrico> jdub: thanks@
<Mithrandir> Kamion: did you get anywhere with the amd64 grub kernel stuff?
<Kamion> Mithrandir: no further than I reported yesterday
<Kamion> Mithrandir: I really have to concentrate on feature-freeze stuff now
<Mithrandir> ok
<Kamion> hm, there were a load of d-i uploads last night to fix translation problems; I should probably go through and merge those
<Kamion> hm, mdz broke X
<Mithrandir> pitti: Debian is including http://arch.err.no/index.cgi/tfheen@idi.ntnu.no--2005/pkg-glibc--multiarch--0--patch-2?cmd=cs_new&file=debian/patches/99_multiarch-ld.dpatch in sarge.  How do you feel about we doing the same for hoary?
<Kamion> has that actually been uploaded to Debian yet?
<pitti> hmm, rpath...
<pitti> Mithrandir: I guess rpath is unavoidable for supporting several libraries with the same name (but different arch)?
<Mithrandir> Kamion: will be when jbailey gets around to it.
<Kamion> Mithrandir: he'll need to get a move on :)
<Mithrandir> Kamion: vorlon was ok with accepting it last night on -glibc.
* Kamion nods
<pitti> Mithrandir: what does default-rpath actually change?
<Mithrandir> Kamion: I could just NMU glibc if you want. :P
<pitti> Mithrandir: the patch itself looks safe
<Kamion> Mithrandir: heh
<Mithrandir> pitti: default rpath is the hard coded search path in ld-linux.so
<pitti> Mithrandir: which is usually /lib, /usr/lib, etc?
<Mithrandir> Kamion: you know, I almost NMU-ed glibc once, for a wishlist bug. ;)
<pitti> Mithrandir: and you want to add /lib64 etc.?
<Mithrandir> pitti: yes, and this adds /lib/i486-linux /usr/lib/i486-linux and /usr/local/lib/i486-linux to that list.
<pitti> Mithrandir: hmm, from my POV this looks fine
<Mithrandir> actually, not /usr/local yet.  That should be fixed.
<fabbione> jdub: i think i have a temporary fix for inotify and usb interaction
<Mithrandir> Kamion: though, that wishlist was "make a libc udeb" so it'd been appropriate. :P
<Kamion> Mithrandir: oh yeah, *that*
<Kamion> fabbione: choose-mirror fix making its way through katie/buildds now
* fabbione hugs Kamion with a lot of love
<Kamion> save it until you verify that it works :-)
<fabbione> yeah right... i am sure it will :-)
<fabbione> Kamion: so after this we only have d-i missing....
<fabbione> at least to get trough phase1 without problems
<Kamion> fabbione: right, I've got a sparc change pending there anyway so I'll do it once choose-mirror's in the archive. is your buildd running at the moment?
<fabbione> Kamion: yes..
<fabbione> it will pick up choose-mirror quite soon
<fabbione> unfortunatly i need to wait jackass -> archive -> my local mirror syncs
<fabbione> that is approx 1 hour or more delay
<Kamion> np
<fabbione> but i will make sure choose-mirror is builded before allowing d-i
<Kamion> I have xorg to fix anyway
<fabbione> i still have to find the time to start daily d-i build
<fabbione> yeah good luck with that ;)
<fabbione> i am testing some kernel stuff here
<Kamion> fabbione: that may be an issue for CD builds, but not much of one
<fabbione> but i need to wait for you/mdz/dani with X first
<Kamion> ah, mdz reverted MANIFEST fixes which were needed for it to build; yay
<fabbione> AMEN
<fabbione> guys please don't fuck X too much.. it's a royal pain to allign MANIFESTS and stuff
<Kamion> yeah, I know
<fabbione> time to cook some food
<Kamion> oh wow, xorg has a file called debian/po/pothead
<Kamion> elmo: could I have accounts in davis/concordia's hoary chroots, please?
<Kamion> (want to test-build xorg)
<elmo> Kamion: done
<elmo> halley too?
<fabbione> Kamion: mind to put the diff somewhere? i can test sparc here and avoid another upload
<Kamion> elmo: I have halley already apparently
<Kamion> fabbione: it's not changed from -1ubuntu14 with respect to sparc; try that
<Kamion> elmo: thanks
<fabbione> Kamion: ok
<lifeless> elmo: I'd really like to do amd64 debs for bazaar 1.2. Is there something other than your time holding up a bazaar chroot on concordia ?
<elmo> lifeless: that and that you keep making the mistake of saying it's "not urgent" every time you bug me about it :p
<lifeless> elmo: it wasn't urgent .. but it gets more so as time goes bye ;p
<elmo> yeah, ok, I'll do once I've finished figlet-of-death to pitti via bugzilla
<pitti> elmo: ?
<Mithrandir> elmo: you do figlets in bugzille?
<Mithrandir> s/e.$/a?/
<Kamion> jesus, I can see why you lot call concordia BATTLESTAR
<elmo> Kamion: :>
<elmo> pitti: set_conf_perms() in the postgresql postinst is EVIL
<fabbione> Kamion: ehehhe
<fabbione> Kamion: you should try building the kernel with -j 400
<fabbione> too bad that it eats all the swap
<Kamion> no thanks, that sort of thing scares me :)
<fabbione> with 300 you are ok :-)
<fabbione> nahh i did it
<fabbione> it keeps up perfectly
<Kamion> I'm happy with build-xorg-while-you-wait
<elmo> as opposed to while-you-grow-old-and-die?
<Kamion> indeed so
<maswan> Kamion: out of curiosity, what hardware is it?
<Kamion> dual "AMD Opteron(tm) Processor 250" 2.4GHz or so according to /proc/cpuinfo#
<maswan> ah
<Mithrandir> the 250s are ok
<Mithrandir> nice, even.
* maswan only has x48's 
<maswan> 8 gigs of ram or so in it too?
<elmo> nah, it's just a porting box, no need for Gbs of RAM
<Kamion> well, it has Gbs, but only two
<elmo> boxes with less than 2Gb of RAM are a crime against humanity
<Hwolf> elmo: in which context?
* fabbione hits elmo with a 1Mb 30 pin memoery stick
* Mithrandir throws some 64kbyte chips at fabio
* Hwolf hugs his 512mb of pc2100 which make memtest crash before it properly starts.
<infinity> People take pride in the weirdest things...
<Mithrandir> memory sticks?  hah! new fad which will go away and we will return to the glorious times of chips which you bent the legs on when you inserted them and similar mind-numbingness.
<maswan> well, make -j 400 bzImage seems to only gobble up 4:ish gigs of ram for me
<Hwolf> infinity: I'm just too poor to afford new stuff. :-P
<maswan> real    1m56.753s
<maswan> I had to try. :)
<elmo> maswan: yeah, for some reason I only put 1Gb of swap on concordia
<elmo> so it only has 3 total
<infinity> Hwolf : I haven't purchased any RAM in the last 10 years that didn't come with a lifetime warranty..
<fabbione> elmo: you can still add some more :-)
<infinity> elmo : And this seemed sane at the time?
<maswan> It peaked at around 4.5 gigs used, I think
<Hwolf> infinity: true, but if i'd send it in, i'd be ram-less for a while. :-)
<elmo> infinity: *shrug* I didn't expect people to try make -j 400; and at the time I was installing it had I had no idea of it's true BATTLESTAR nature
<maswan> Well, these are the same as the compute cluster, so that's the reason for 8 gigs of ram
<fabbione> elmo: i had the idea that you know me by NOW
<infinity> elmo : Well, make -j 400 seems a bit ridiculous, but swap smaller than RAM makes the swap seem kinda pointless.
<elmo> infinity: eh, why?
<Hwolf> infinity: Why would a box swap while ram isn't full, anway?
<infinity> elmo : If you're eating two gigs of RAM, you'll eat the next one pretty fast.  Of course, you need a fabbione to trigger this phenomenon, I suppose.
<maswan> infinity: the swap is there for stuff that isn't used, you want your working set in ram anyway
<infinity> maswan : Obviously, but some of us can't afford enough RAM for fabbione's tastes.
<maswan> infinity: Ah, well, in that case, yeah, lots of swap would be good.
<maswan> Tasks: 980 total, 280 running, 700 sleeping,   0 stopped,   0 zombie
<maswan> Mem:   8137444k total,  5097492k used,  3039952k free,   155280k buffers
<maswan> and the machine is laggy but usable. neat. :)
<infinity> Then again, I guess the usage of the machine matters.  Multi-user machine, constantly swapping out, acceptable.  Single0user machine, only ever one or two active tasks, you probably just want to see things get OOMed.
<maswan> Oh, well
* maswan prepares for use of Ubuntu in academia, by using his laptop for slides for his first ever lecture :)
<Hwolf> maswan: best of luck. Presentations are fun
<maswan> http://gmetad.hpc2n.umu.se/ganglia/?c=Sarek&h=mupp-m.hpc2n.umu.se&m=&r=hour&s=descending&hc=4
<maswan> make -j 400 and the second peak is make -j 1600
<Mithrandir> maswan: good luck. :)
<maswan> Not much of a difference. :)
<maswan> Thanks
<infinity> maswan : i don't recommend ever listening to fabbione's suggestions again. :)
<infinity> maswan : Also, the luck thing.  Break legs and all that.
<fabbione> nobody should by defalt :-)
<infinity> fabbione : That quote will haunt you.  I guarantee it.
<fabbione> infinity: eheheh
<fabbione> maswan: Uptime: 91 days, 20:46
<fabbione> what about doing a few tons of security updates on that box?
<Hwolf> fabbione: good piont. :-)
* fabbione prepares a few IGMP packets for maswan
<Hwolf> fabbione: be good!
<fabbione> nah i would never do stupid stuff like hacking other people boxes
<fabbione> it's really STUPID
<Hwolf> fabbione: I think most of the people present realise that. :-)
<fabbione> Hwolf: never assume anything in here.. 
<fabbione> elmo assumed that nobody was going to do a -j400 on concordia :)
<Hwolf> fabbione: outside of my working hours, I treasure my assumptions
<pitti> sjoerd: I'm at rewriting pmount-hal in C
<pitti> sjoerd: now it uses 0.2 sec instead of 2.7 :-)
<jdub> pitti: zoooom!
<pitti> jdub: calling hal-get-property repeatedly was a massive slowdown
<jdub> that'll be a nice boost in response time
<Hwolf> pitti: am I hearing faster ubuntu here? 
<pitti> :-)
<Hwolf> just curious, do you have any target-system that you'd expect ubuntu to be smooth on?
<darklight> fabbione dong
<Kamion> please don't make me think about fabbione's dong; I was about to have lunch
<infinity> I hope it wasn't a bratwurst.
<pitti> hey, Bratwurst is goood stuff
<infinity> pitti : Not when you associate it with fabbione's dong, it ain't.
<sivang> Kamion: hehehe
<fabbione> darklight: ?
<thom_> mjg59: if laptop-mode-tools is up to date, sure we should use that
<sivang> anybody has any idea how to make irssi act as a proxy? net latency is killing me :)
<sivang> the instrcutions on the site are rather, brief 
<sivang> (an unworking)
<elmo> sivang: http://www.garion.org/irssi/irssi-proxy.php
<thom> is madwifi in the kernel or in l-r-m?
<elmo> sivang: basically, /load proxy and then set irssiproxy_ports and irssiproxy_password variables
<elmo> sivang: then check it's listening on the port(s) you chose with netstat
<sivang> elmo: did that, it's listening, still no go :-/
<elmo> how do you mean? how are you trying to connect?
<sivang> elmo: but thanks for that doc, much more clearer then irssi's ones :)
<sivang> elmo: listing the server which irssi-proxy runs on as the chatnet server, and changing the port
<sivang> elmo: then attempting autoconnect on startup from my local irssi client
<rubenv> erm
<rubenv> am i reading right
<rubenv> or does he connect to the same port 4 times?
<mjg59> thom: l-r-m
<mjg59> thom: #6111 as well
<rubenv> i thought you needed a seperate port per irc net
<sivang> elmo: should I be quitting irssi on the server after loading the module? 
<Kamion> fabbione: where's my choose-mirror_1.06ubuntu3_sparc.udeb, eh? :)
<rubenv> sivang: detach it from screen i think
<fabbione> Kamion: in the queue
<sivang> elmo: looks like your doc is very nice, I'll give it a try then come back and bother again if I don't successed :)
<elmo> sivang: it's not my doc dude, it's just something thom pointed me at
<sivang> elmo: ok, then thanks to you and upstream to thom and to the one who wrote it :)
<dholbach> bye guys... i'm off
<darklight> volleys to everybody
<darklight> I would like to propose some project I regard the Kernel team
<Mithrandir> lamont: is avifile in PaS?
<fabbione> darklight: speak up :-)
<elmo> %avifile: i386                                                        # i386 Win32 DLLs needed/executed
<elmo> Mithrandir: P-a-s is available on cvs.d.o btw
<Mithrandir> elmo: we use the same PaS?
<infinity> dak/srcdep
<infinity> Mithrandir : Yes, elmo syncs it from time to time.
<infinity> Hence the appearance of amd64 all over Debian's P-a-s. :)
<Mithrandir> ah, ok.
<Mithrandir> goodie
<Mithrandir> elmo: I'll stop harassing you and lamont about that, then. :)
<fabbione> thom: l-r-m -> daniels please
<thom> fabbione: fix bugzilla; i just reassigned to default owner
<fabbione> ah crap
<fabbione> Kamion: choose-mirror is building now
<Kamion> ta
<darklight> beyond trying it gets bug in sources i would want to create a guide where they come listed to all the new functionalities of the kernel
<darklight> to say the truth they are the two guides. one for the bug and an other for adding drivers or to new functionality
<fabbione> darklight: so you want to produce documentation, right?
<Kamion> perhaps that kind of guide would fit better in kernel upstream than in a distribution-specific context?
<rcaskey__> yeesh, this week is the week of the Ubuntu live cd
<rcaskey__> everyone wants to have their name on it
<Kamion> c'mon, halley, build X damnit
<fabbione> ahha
<fabbione> it will take ages there if you don't have ccache
<Kamion> davis and concordia finished ages ago, and halley started first by some distance
<fabbione> yeah
<fabbione> same with the kernel
<fabbione> ia64 is teh sux
<thom> concordia > * ;-)_
<fabbione> thom++
<thom> fabbione: see the "please update ipw2100 to 1.0.2" post?
<fabbione> thom: which mailing list?
<thom> u-d
<thom> i think
<darklight> clearly it is remained in the context of ubuntu even if it is remained in the sphere of linux. The scope is to make to choose if and when to dawn just kernel based on the functionalities of the new releases
<fabbione> thom: ipw2100            | 1.0.2                      | ok     | 13/12/2004   | http://ipw2100.sourceforge.net/
<fabbione> thom: people don't even know what they are running :-)
<fabbione> + they should really use bugzilla
<thom> heh
<fabbione> i have way too many ml
<fabbione> Kamion: choose-mirror_1.06ubuntu3_sparc.changes ACCEPTED
* fabbione takes a break
* Hwolf gives fabbione some energy
<fabbione> after this fight with kernel boot options i can easily set it up to disable your browser from accessing bugzilla.u.c and bitch me
<mjg59> fabbione: The mail actually asks for 1.0.4
<lamont> fabbione: did we get -14 yet?
<elmo> ARE WE THERE YET?
<Hwolf> elmo: I'm still here, sorry
* lamont takes kids to school.
<thom> mjg59: 2, 4. same odds :-)
<mjg59> Haha
<mjg59> Arse, late
<Mitario> mvo_, pingping ;)
<Mitario> lo everyone
<fabbione> mjg59: yeah but it claims we run 0.55 :-)
<fabbione> lamont: i can't upload until X is fixed and LiveCD built on top of it
<Hwolf> fabbione: is there anything we can expect from X on the short term? any droolishly good stuff?
<mvo_> hi Mitario 
<mvo_> welcome back :)
<Mitario> hi :)
<Mitario> ty!
<Mitario> bleh my xchat periode has ended on XP, now I have to use mIRC :/
<fabbione> Hwolf: you should ask daniels ;)
* Hwolf is a bit pissed. *can't acces his mailing lists anymore*
<pitti> fuck, why does my computer crash when I remove my USB stick?
<pitti> faaaaaaaaaaabio!
<rubenv> pitti: same problem here
<rubenv> my guess:
<rubenv> linux kernel freaks because of lost device with unflushed buffers
<rubenv> this should be done more gracefully
<rubenv> if only I were a kernel hacker
<pitti> that never happened before
<infinity> Mitario : Try Bersirc -- http://bersirc.free2code.net/
<pitti> rubenv: I inserted and removed my USB stick so many times, it always worked without crashing
<rubenv> pitti: i know
<rubenv> exactly the same here
<rubenv> but probably yu were always lucky not having unflushed buffers
<rubenv> in fact you should unmount first
<pitti> rubenv: I did
<pitti> rubenv: in fact this happened during "pumount"
<fabbione> pitti: it's inotify.. i am working on it
<smurfix> pitti: for me, just unplugging works 95%, the other 5% -- ouch
<pitti> fabbione: ah, ok
<elmo> is inotify utterly critical for us?
<rubenv> elmo: yes :)
<fabbione> if you start monitoring the mountpoint or anything in it.. BUUM
<pitti> fabbione: this sucks really hard, doesn't it
<fabbione> pitti: 5431
<rubenv> elmo: unless you want FAM back ;)
<fabbione> and i have a workaround for it that i can't even upload now
<pitti> noooooo, no fam
<fabbione> elmo: upstream is working hard to fix the problem.. 
<fabbione> we exchanged 20 mails/patches only yesterday
* pitti cheers fabbione 
<fabbione> now i am going to make it a boot option as workaround
<rubenv> it should be mentioned that inotify is very young and already very impressive technology
<fabbione> so you can disable inotify if the machine freezes
<Mitario> infinity, ah thank you very much :)
<infinity> Mitario : 1.4 is pretty full featured, but closed.  2.x is a rewrite as Free Software.  Take your pick.  Both work.
<fabbione> who run 686 kernels here and have the usb crash problem?
* rubenv !
<pitti> k7
<Mitario> is 2.x the same as 1.4? or does it still need some cleanups
<fabbione> rubenv: any binary driver like nvidia or ati?
<Mitario[1] > ok ;)
<rubenv> fabbione: yes, nvidia
<pitti> fabbione: I don't have a binary driver
<Mitario[1] > hmm, UI is a bit slow/weird though ;)
<fabbione> rubenv: if you can temporary use the nv driver in X i have a test kernel for you
<fabbione> pitti: i didn't build k7 :-)
<fabbione> pitti: gimme a few and i will do
<pitti> fabbione: ah, I thought it was a poll for diagnostics
<fabbione> pitti: no.. i have test kernels...
<fabbione> but i did build only 686 :-)
<rubenv> fabbione: I'm pretty constained to nvidia, unless I only wanna use a small part of my screen
<rubenv> also I don't have a USB stick here at the moment
<maswan> fabbione: Well, if debian had had proper security updates for the kernel...
<rubenv> but If you'd like, I'll test it tonight
<Kamion> damnit
<fabbione> maswan: they do...
<Hwolf> maswan: debian is about the safest thing out there, or should be
<maswan> fabbione: I haven't seen a kernel dsa in ages
<Mitario_> allright
<Mitario_> 1.4 works better :)
<infinity> mitario : 1.4 is much better, yes.
<Hwolf> maswan: official woody uses an ancient kernel, remember?
<fabbione> maswan: so what? did you ever check 2.6.10 changelog recently?
<infinity> Mitario : Though, if you feel the urge to contribute to a project that's not XChat/Win32, then Bersirc 2.x is it.
<Mitario> yeah
<Mitario> well, just needed an irc client other then mIRC :)
<Hwolf> xchat blows mirc out of the water, imho
<fabbione> pitti: so how do i reproduce that crash? insert an USB device and unplug it without umount?
<pitti> fabbione: for me it just happened during pumount
<rubenv> fabbione: that's how i do it
<pitti> fabbione: but it's a gamble, most of the time it just works
<pitti> fabbione: it happened only twice today for me
<maswan> fabbione: No, not really. I know that the kernels have serious holes, yes. But the half point of running a distribution is to get security upgrades, not having to track development for issues that might turn up and then do trial-and-error for compatibility.
<infinity> Hwolf : And it's also time-limited shareware on Win32.  Hence Mitario's search for something else.
<pitti> fabbione: while i mount/umounted about 50 times (new pmount version...)
<fabbione> pitti: ok....
<Hwolf> infinity; win32 makes me shiver, please don't do that to me.
<fabbione> rubenv: ok.. i can test that
<Kamion> daniels: ok, I'm uploading an xorg which should actually build on all architectures, unlike -1ubuntu14, but doesn't have the changes in -1ubuntu13 that mdz reckons broke the live CD. I'll leave you to resolve the differences :-(
<rubenv> fabbione: i'll bug you tonight if I find a USB stick
<zul> hey
<fabbione> rubenv: i might not be around.. you can test this kernel: people.ubuntu.com/~fabbione/linux-image.....
<fabbione> hey zul
<Kamion> daniels: The only diff from -1ubuntu14 to -1ubuntu15 that wasn't part of your previous upload is removing tdfx_dri.so from MANIFEST.ia64.in; you can throw away that change once you start building it on ia64 again, as I'm sure you know.
<rubenv> fabbione: ok, it's on my list of things to do when feeling bored & destructive
<fabbione> rubenv: there is no binary nvidia for that kernel.. so that you know
<rubenv> fabbione: i can live with that for testing purposes
<fabbione> ok
<elmo> d3vic3: 
<elmo> ?
<d3vic3> yes
<d3vic3> elmo, 
<maswan> fabbione: btw, this is one of the reasons for wanting to move to ubuntu, since I've so far gotten security upgrades for my laptop, unlike my desktop which runs woody, or having to handle unofficial sid snapshots in the amd64 case.
<elmo> d3vic3: these python2.4 simpy packages are empty?
<jbailey> Is our Lintian package toold for Ubuntus section names and such?
<d3vic3> empty ?
<Kamion> jbailey: yeah, I did that a little while back
<RainMoods> Hi all
<jbailey> Kamion: Nice, thanks.
<RainMoods> Upgrading to hoary broke my system... Can anybody help out?
<jdub> RainMoods: #ubuntu would be more appropriate
<RainMoods> This is the error I got: Failed to start message bus: failed to read directory: "/usr/lib/dbus-1.0/services" No such file or directory
<RainMoods> would #ubuntu be more appropriate? They just pointed me to this channel :o(
<Hwolf> jdub, it'd be good to have someone help him track down what went wrong and file a good bug, right?
<elmo> d3vic3: there's nothing in them, except for the /usr/share/doc/$pkg/ directory
<d3vic3> ok, I'll check 
<fabbione> pitti: building k7/686 now...
<Mitario> brb
<zul> fabbione: for the phpacpi patch do you want me to send it as a dpatch from now on?
<fabbione> zul: it's already part of another upstream patch i did include to get battery status working again
<fabbione> no need to update it anymore
<zul> k
<fabbione> ohohohohoh NEW D-I
<zul> but for any other patches would a dpatch do?
* fabbione dances around Kamion 
<fabbione> zul: dpatch is fine but you need to name it properly.
<zul> k
<zul> what would you prefer the naming scheme?
<fabbione> zul: stolen_from_head when they come from upstream and they need to apply after the last stolen-from-head_ and before the first external patches
<fabbione> zul: the one that it is in use now
<zul> k
<fabbione> so that each major release we can just trash stolen_*
<fabbione> and rediff the others
<zul> gotcha
<fabbione> also, if the patch depends on another one, i need to know that
<fabbione> specially if we need to drop something
<Treenaks> 3 xorgs in 1 day.. is this some kind of record?
<elmo> it's certainly not a good one
<elmo> I'm going to come up with some kind of bandwidth-o-meter that electrocutes developers if they upload something that'll cause more than 200Mb of traffic in a day 
<fabbione> i don't think i never uploaded X that much.. max twice iirc
<fabbione> ;.(
<fabbione> elmo: does that mean that you will upload the kernel from now on?
<fabbione> iirc that's around 500Mb?
<elmo> yes, I know, and it sucks
<rubenv> hurray for pkg diffs :)
<fabbione> ok USB remove without umount crash reproduced
* fabbione gets ready close/duplicate a few tons of bugs
<rubenv> :-)
<pitti> carlos: ping
<carlos> pitti: pong
<pitti> carlos: anything wrong with Rosetta?
<pitti> carlos: I tried to upload a new pmount pot two times now
<pitti> carlos: it just doesn't appear
<carlos> hmm
<carlos> just a second
<carlos> we changed the way we import them
<fabbione> GO AND DIE INOTIFY!!!!!
<jbailey> Nice rhyme. =)
<Treenaks> jbailey: we need cheerleaders to chant it!
* rubenv loves inotify
<rubenv> *gogo rml*
<jbailey> elmo, mdz: I split off the plugin into nagios-radius-plugin, since adding 40k of code grafted on was less painful than 20 lines of configury and Makefile.  I have both packages here.  Do I need to do anything special, or just upload them?  (I don't see any mention in the wiki of things like ITPing and such)
<fabbione> rubenv: you know that it is inotify crashing your machine when you unplug the USB stick?
<elmo> jbailey: just uploading is fine
<rubenv> fabbione: yes, but i rather carry around my laptop to transfer data then use fam :-)
<Treenaks> fabbione: don't do that then :P
<lamont> fabbione: -14: ok.  sigh....  I want a new kernel right after array 4 then... :-)
<fabbione> lamont: i can't upload.. really.. i have an ABI change
<fabbione> that i really cannot avoid
<zul> fabbione: oh yeah that libata bug (6109) do you want to take a crack at it
<lamont> fabbione: yeah, I understand.
<lamont> it's not like ia64/live was working before this either... :-(
<fabbione> zul: i already imported some libata updates a while ago.. just double check them.. it would be great :-)
<zul> k
<lamont> Kamion: an ia64 install disk is probably useful for array 4, live need not ship
<carlos> pitti: fixed
<carlos> pitti: and imported
<carlos> pitti: thanks for the report
<fabbione> pitti: 5431 is an update
<fabbione> s/is/has
<pitti> carlos: okay, then I can upload the new POs now?
<carlos> pitti: some of them where already uploaded and imported
<carlos>  /s/where/were/
<pitti> carlos: well, I tried, but they did not appear
<carlos> pitti: should be there now
<carlos> pitti: but you can import them again if you want
<pitti> carlos: yes, indeed. everything is there now. THanks!
<carlos> pitti: np
<pitti> fabbione: oh, thanks for the workaround
<fabbione> pitti: i am uploading a kernel for you to test
<daniels> Kamion: blah.  thanks.
<fabbione> nothing special.. you can just boot with 'noinotify' and it will work via dnotify
<pitti> fabbione: we shall test this?
<pitti> fabbione: so the next kernel will not have inotify?
<fabbione> pitti: yes. not everybody needs noinotify
<fabbione> yes it will as the old ones
<fabbione> but you can disable it at boot
<fabbione> as an option
<fabbione> upstream is still working on a real fix to the problem
<pitti> okay
<fabbione> -13 that was released yesterday was not even capable of booting the kernel
<fabbione> anf i got -14 this morning 2 hours before kernel.org
<fabbione> :-)
<fabbione> sorry inotify -13 and -14
<jdub> fabbione: cool, glad rml is playing
<jdub> (i, um, kinda pinged nat about it...)
<fabbione> apparently i was the only one reporting bugs/patches to him
<fabbione> and we are the only distro with inotify 
<fabbione> at least...
<rubenv> fabbione: don't forget gentoo, they throw in everything
<fabbione> >I am not 100% sure if Jeff Waugh got in touch with you, but we (as ubuntu)
<fabbione> >> are having a problem with inotify (even if damn proud to ship it).
<fabbione> And I am very, very happy that you guys ship it.  ;-) 
<fabbione> rubenv: well.. pointless if they don't report problems to upstream
<zul> heh gentoo
<Treenaks> fabbione: gentoo does not have bugs!
<Treenaks> fabbione: bugs don
<rubenv> fabbione: gentoo users are used to breakage, they just wait ;-)
<Treenaks> t exist if you build from source
<fabbione> Treenaks: right.. they build with -ONOBUGS
<jdub> fabbione: atm, we are
<Treenaks> fabbione: yeah..
<fabbione> rubenv: another reason for not using gentoo
* zul abstains from arguing
* fabbione hides from zul
<fabbione> ;)
<zul> fabbione: damn straight
* fabbione can be evil
<fabbione> no.. that's wrong...
* fabbione is evil but tries hard not to be
<fabbione> zul: does gentoo use inotify?
<zul> fabbione: not that i know of i dont think so
<fabbione> ok
<zul> its kind of a policy of gentoo not to have cvs type software in their tree
<zul> er..cvs quality
<zul> well there is
<zul> devs get pissed if they break their tree...anyways
<fabbione> eheh
<pitti> ahem, this time I did not even try to umount/remove the usb stick...
<fabbione> pitti: the kernel is on people
<fabbione> in my home
<pitti> nice, thanks
<fabbione> pitti: boot with noinotify option
<fabbione> have fun
<pitti> well, exactly now I finished the last pmount/gvm test :-)
<pitti> elmo: please sync pmount 0.7-1 from incoming
<mjg59> fabbione: Good news about the acpi stuff
<fabbione> mjg59: tested here.. it works and fix the battery problem
<mjg59> Yeah
<mjg59> It ought to solve some other issues, too
<fabbione> good
<fabbione> i managed to hunt down the USB storage problems today
<mjg59> Excellent
<mjg59> Things are looking in pretty good shape
<fabbione> next will be to sacrifice jdub as virgin to get it fixed
<mjg59> I've got some Sony hardware that I'm going to play with now
<mjg59> Need to find a working CD drive first, though
<fabbione> mjg59: still missing ALSA and some other USB stuff
<elmo> pitti: is it urgent?
<pitti> elmo: well, not really
<mjg59> fabbione: Pff. Nobody needs them.
<mjg59> (cough)
<fabbione> mjg59: ehehhehe
<pitti> elmo: but sabdfl wanted me to upload new versions to Ubuntu no later than to Debian
<pitti> elmo: I can as well upload a -0ubuntu1
<fabbione> i am seriously thinking to backport all of alsa and usb back to 2.6.10
<elmo> pitti: besides it's a new upstream version
<elmo> pitti: you'll need to do the usual UVF procedure
<pitti> elmo: already ack'ed
<pitti> elmo: mdz agreed to put new pmount fixes into new upstream versions since I'm upstream myself
<elmo> ok, well please leave it for now; I want to talk to mdz about how we should handle this
<pitti> okay
* fabbione has the feeling that xorg has failed on ia64 for MANIFEST checks and it will fail on sparc
<fabbione> cp: cannot stat `debian/tmp//usr/X11R6/lib/modules/dri/tdfx_dri.so': No such file or directory
<fabbione> argh.. not even a MANIFEST check....
<Kamion> fabbione: mm? I'm fairly sure I fixed that bit on ia64
<Kamion> in -1ubuntu15
<daniels> Kamion: u15 is still ftbfs
<fabbione> well it failed on the buildd
<Kamion> daniels: crap
<fabbione> ok please no ubuntu16 today ok?
<Kamion> sigh. I fixed that, damnit.
<Kamion> fabbione: at this point, array 4 can wait
<daniels> Kamion: don't worry about it.  i'm about to go to bed (well, back to bed; for some reason I had a compulsive urge to go and check the build logs etc), so if you give me a few hours to catch up on sleep, I'll do u16 later on.
<fabbione> Kamion: i am afraid so...
<daniels> and this time, we can give it the testing it needs.
<daniels> 'night all
<Kamion> daniels: yeah, it was worth a try; at least mdz will have his live CDs, since this one built on amd64/i386/powerpc
<tseng> bye daniels.
<fabbione> daniels: please try not to destroy sparc.. it's almost friday :-)
<zul> night daniels 
<Kamion> and, since that was basically the mandate I got this morning ...
<tseng> lamont: when you get up would you mind telling me what happened with tomboy-0.3.1-0ubuntu4, upload was accepted yesterday but no log
<fabbione> Kamion: since we are delaying array4, would it be reasonable to try (just once and for the sake of it) to build a sparc cd?
<Kamion> fabbione: there's a fair amount of infrastructure to set up (mirroring sparc.ubuntu.com onto little, for a start), but I'll see what I can do
<fabbione> Kamion: than no.. stop here
<fabbione> no need to spend time on it
<fabbione> i tought it was something simple
<Kamion> elmo: so ... can you remind me what the problem with --copy-links in little's anonftpsync was?
<Kamion> elmo: oh, was it dists/*/main/*installer-*/current
<Kamion> ?
<elmo> yeah
<elmo> and you need --copy-links for pool/ because of the games I play with components
<elmo> s/and/but/
<Kamion> right, that was why I added it
<Kamion> hm. the problem is, your version is "mirror everything but the indices, then mirror everything (including indices)"; I can't just add it to the second run since that would probably overwrite the current symlinks with copies
<Kamion> sorry, just to the first run, I mean
<Kamion> oh, and what's the "--exclude complete" for?
<elmo> that's a bug
<elmo> it's something from hoglet era
<Kamion> ok, I'll trash that
<elmo> I just used that anonftpsync two-pass thing 'cos it's what I had handy, you don't necessarily need it
<elmo> you could turn it into one pass of everything, and then a second pass of pool/ only with --copy-links or so
<elmo> the two pass of anonftpsync is designed so that the mirror's never inconsistent (in theory); I guess that's not an issue for you
<Kamion> and maybe no --delete on the second pass; that would avoid consistency problems, wouldn't it?
<Kamion> well, it is an issue I think, I'm not locking on Archive-Update-in-Progress or anything
<Kamion> (and can't really, since it's remote)
<elmo> I meant consistent locally; I don't think we can address the issue of you catching archive.u.c mid-mirror
<Kamion> ok, I'll try that two-pass rearrangement out and see what happens
<jbailey> fabbione: Am I on crack?  I swear I saw the DSDT initrd patches in our kernels...
<lamont> tseng: if you upload to clear a build-dep, and the package is dep-wait on that... then you need to tell me to release it..
<mvo_> elmo: what was the reason again for not having a "stable" symlink in the ubuntu archive?
<Kamion> elmo: although leaving out --delete on the second pass probably doesn't matter, since files are kept around for long enough before garbage-collection that little should never lose stuff that the current indices refer to
<elmo> mvo_: err.. I actually can't remember :(
<tseng> lamont: ah sorry I did read that. thats definately the case
<smurfix> mvo_: ubuntu's committed to supporting the last three releases, so what's the "stable" one?
<elmo> smurfix: stable, stabler, stablest
<elmo> ;)
<mvo_> hrm ... I would like to check for new distro releases with update-manager so a stable symlink would come handy (to get the latest stable release file)
<Kamion> stable, oldstable, crustystable
<tseng> or.. current
<lamont> mvo_: you really want to be able to specify whether you want to be 0, 6, 12, or 18 months out of date, no?
<tseng> which seems to make sense to me.
<jbailey> fabbione: I am on crack, found it.
<bluefoxicy> aww man
<bluefoxicy> I really need to update firefox
<bluefoxicy> it crashes as soon as I try to type something in google, or in the search bar
<bluefoxicy> first letter I type BAM
<smurfix> mvo_: updating to the next release isn't something that should be happening automagically. Keeping uptodate with the release you use is (potentially). So why a symlink? It's ultimately dangerous.
<mvo_> lamont: yes, basicly I need to know that last releases to check if a new release is available and if this release will be stop being supported
<Kamion> lamont: tried to kick off live CD builds, but:
<Kamion> + ssh buildd@terranova.buildd /home/buildd/bin/BuildLiveCD
<Kamion> Password:
<mvo_> smurfix: I agree that there shouldn't be a automatic upgrade. I'm just thinking about how to keep track of the current/past releases to inform the user in a nice way :)
<smurfix> mvo_: I'd propose a small package which lists that stuff and which is updated in every release when a new one comes out.
<tseng> mvo_: i think of it in less of a debian "stable" sense and more of a gnome ftp "LATEST-IS" sense
<smurfix> tseng: exactly
* mvo_ nods
<smurfix> mvo_: Then if a release is no longer supported, we could put up a last update which pops up a big fat warning.
<lamont> Kamion: hrmpf. checking
<lamont> Kamion: command="/home/buildd/bin/BuildLiveCD",no-pty,no-port-forwarding,no-X11-forwarding,no-agent-forwarding ssh-dss AAAAB3N...
<lamont> wonder if I have the key wrong?
<tseng> mvo_: smurfix hm yes, a lastest-is or current symlink in the parent dir of all dists, and then an empty file UNSUPPORTED or EOL in the dist dir
<fabbione> or simply a SUPPORTED file with an array that would indicate the age too
<fabbione> like stable[0] =
<fabbione> and so on..
<fabbione> where 0 is always the latest
<lamont> Kamion: for the moment, you want me to just kick them?
<tseng> lamont: build cleared x86, thanks much.
<Kamion> lamont: yeah, please
<lamont> kicked everywhere
<lamont> (didn't want ia64 to feel left out, you know...)
<fabbione> ehheeh
* lamont considers glaring at certain kernel people, decides to be nice.. :-)
<fabbione>  signfile debian-installer_20041227ubuntu8_sparc.changes C14C0CBD
<fabbione> cya tomorrow guys
<pitti> bye fabbione 
<Kamion> elmo: ok, fixed more permanently now, I think
<elmo> Kamion: cool
<Kamion> elmo: could you kill /srv/cdimage.no-name-yet.com/ftp.bak/pool/main/g/gs-esp? it's owned by mdz and not group-writable
<elmo> done
<Kamion> ta
<Kamion> no idea how that happened; anonftpsync has always forced umask 002
<dholbach> re
<tseng> hi there
<tseng> lo mxpxpod 
<tseng> we were talking about you last night :)
<mxpxpod> oh?
<tseng> ya, about swapping the tomboy icon. i mailed you aboot it.
<mxpxpod> heh
<tseng> i dont recall what bits you changed
<mxpxpod> haha
<mxpxpod> the stupid tintin icon sucks
<tseng> i was too tired to poke it much
<tseng> just did a grep tintin.png | grep -v Makefile
<tseng> and came up empty
<mxpxpod> heh
<tseng> iirc it was hardcoded somewhere
<tseng> when you did it.
<mxpxpod> i can email you a patch
<tseng> great.
<tseng> (note the new version has an applet as well)
<mxpxpod> great
<tseng> the old patch is a start, thanks
<mxpxpod> k
* lamont decides that backporting a patch that is based on a complete reimplementation of another huge patch isn't properly called "backporting"
<thom> lamont: working with mozilla.org ?
<lamont> thom: postfix
<lamont> ipv6
<thom> ahr
<tseng> are the logs of this channel publicly available?
<mxpxpod> tseng: you need to put your tomboy source pkgs in your repo
<tseng> mxpxpod: they are in hoary
<mxpxpod> ah, ok
<tseng> or are you warty?
<mxpxpod> even the 1.3's?
<tseng> 1.3.1
<spiral> hi
<mxpxpod> cool
<tseng> the binary hasnt made it in yet, just built a little bit ago
<tseng> source should be there
<mxpxpod> k
<mxpxpod> i'll check it out
<thom> tseng: http://people.ubuntu.com/~fabbione/irclogs iirc
<mxpxpod> k
<mxpxpod> thanks
<tseng> thanks thom 
<mxpxpod> gotta go
<lamont> I AM INVINCIBLE!
<Kamion> This processor "Transmeta(tm) Crusoe(tm) Processor TM5800" is known _not_ to support power-saving.
<Kamion> hm, oh well
<mxpxpod> tseng: ah, I remember what I did
<mxpxpod> it should be easy to fix up your tomboy packages with a better icon :)
<sivang> rehi all
<tseng> mxpxpod: wonderful, thanks.
<mxpxpod> tseng: just have to find the icons again :)
<tseng> i have them
<tseng> http://primates.ximian.com/~jimmac/blog/Artwork/Tomboy
<mxpxpod> rawk!
<tseng> one more
<tseng> http://primates.ximian.com/~jimmac/blog/Artwork/LowresTomboy
<mxpxpod> that's the one
<mxpxpod> ok, i gotta go... I'll take a look at the package later
<lamont> anyone have a stock warty /etc/postfix/master.cf lying around?
<otavio> Hello folks ... I'm interested to know if anyone are interest to send xresprobe to Debian for include. It's interesting for others derived distributions like debian-edu and debian-br-cdd, like in my case.
<amu> lamont: if a warty debbootrap is fine for y also ...
<dholbach> lamont: http://moz.gotdns.org/master.cf
<lamont> amu: I have that - will probably just go that route
<lamont> or snag dholbach's.
<lamont> dholbach: that's not a stock warty install
<lamont> you've told it something other than 'Local only'
* lamont installs in a chroot
<dholbach> lamont: oh sorry, yes, it was hoary already
<Kamion> otavio: best talk to daniels
<otavio> daniels: there?
<otavio> Kamion: thanks a lot
<lamont> Kamion: postinst configure gets passed the old version, yes?
<spiral> hmmm.... http://www.uni-koblenz.de/~dbildh/Linux_On_TM4001/#smartbattery... Do you plan to put this in ubuntu ?
<spiral> It's about smart batteries
<Kamion> lamont: thus saith policy 6.6 ...
<lamont> thjans
<thom> spiral: mjg59 was looking at smart battery support
<mdz> Kamion: what's the good word?
<pitti> Hi mdz
<Kamion> mdz: took most of the day to fix up xorg
<tseng> lamont: does that package have to be pushed to the mirrors now that it built? im not seeing it hop over
<Kamion> mdz: and now alsa's apparently fucked, so the live filesystems won't build
<Kamion> dpkg: dependency problems prevent configuration of alsa-base:
<Kamion>  alsa-base depends on alsa-utils (>= 1.0.8-1); however:
<Kamion>   Version of alsa-utils on system is 1.0.7-2ubuntu2.
<lamont> tseng: should be automagical
<Kamion> dpkg: dependency problems prevent configuration of alsa-utils:
<Kamion>  alsa-utils depends on alsa-base (>> 1.0.7-1); however:
<Kamion>   Package alsa-base is not configured yet.
<sladen> thom: seen the latest cpufreq post---I think after the freature freeze I'll look at the whole thing again as despite the number of fixes, it's breaking others
<thom> yeah
<Mithrandir> alsa-base is uninstallable, yes
<thom> just asked them to file a bug
<Kamion> Mithrandir: that's critical; do you know if anyone's working on fixing it?
<Mithrandir> no idea, I noticed just before I left for dinner.
<Kamion> ah, alsa-utils failed to build on all architectures
<Kamion> http://people.ubuntu.com/~lamont/buildLogs/a/alsa-utils/1.0.8-1ubuntu1/
<lamont> Kamion: mdz uploaded it last... :-)
<Kamion> however, that was mdz's upload, so ... :)
<mdz> Kamion: I uploaded alsa-utils 1.0.8-1 yesterday to fix that
<mdz> gah
<mdz> After installing, the following source dependencies are still unsatisfied:
<Kamion> looks like alsa-lib needs to be uploaded too
<mdz> needs alsa-li bas well
<mdz> yep
<mdz> lamont: can you explain http://people.ubuntu.com/~scott/ongoing-merge/alsa-lib/alsa-lib_ubuntu.patch ?
<pitti> mdz: in a quiet minute, could you please take a look at #1956? I have a new g-v-m ready that would support the autorun feature (default off, of course)
<mdz> seems to merge OK, but i have no idea what it means
<mdz> pitti: is it necessary to have a --exec switch?  when would it be used, and when not used?
<pitti> mdz: if autorun is disabled, it is not used, just like now
<pitti> mdz: if autorun gets enabled, gvm uses --exec
<pitti> mdz: the thing is, we should either remove the feature completely or make it work
<pitti> mdz: but not leave it broken, as now
<Kamion> mdz: that patch looks to me as if we should actually just sync
<pitti> mdz: but since some people insist on it, and it's easy to make working, I thought I prepare a quick patch (only 3 lines)
<pitti> mdz: upload pending your decision
<mdz> is elmo around?
<mdz> pitti: ok, sounds fine
<mdz> pitti: I think it would also be fine to mount exec by default
<mdz> it only prevents the user from doing things that they ought to be able to do if they want
<pitti> mdz: so, leave noexec as pmount default, but always supply --exec in gvm?
<mdz> disabling autorun doesn't mean "prevent me from running things explicitly"
<pitti> hmm, okay
<lamont> mdz: short answer is "no" - it's on my pending list to figure out WTH autocrap is doing there, if anything.
<mdz> why leave noexec as default?
<lamont> it may be insignificant, dunno
<mdz> lamont: when you did 1.0.5-1ubuntu1, that was a configure.in change + autoconf, right?
<Kamion> lamont: changes in configure without corresponding changes in configure.{in,ac} are usually best discarded, I'd've thought ...
<mdz> if so, I agree with Kamion that it looks obsolete
<pitti> mdz: may I upload pmount 0.7? it brings --exec, and also a C rewrite of pmount-hal (0.2 s vs. 2.7 s with the shell version)
<elmo> mdz: I dunno, I can ask him if you want
<lamont> mdz: I believe so...
<mdz> elmo: please sync alsa-lib 1.0.8-1
<lamont> probably is obsoletel
<mdz> pitti: yes
<pitti> okay, thanks
<pitti> elmo: so can you please sync pmount? TIA
<elmo> mdz: done
<mdz> elmo: thanks
<pvh> How can I follow Hoary updates?
<pvh> By that I mean, how can I see what has changed in package updates?
<zul> subscribe to the hoary-changes mailing list 
<dholbach> or install apt-listchanges
* sivang is finally using irssiproxy, so cool, no latency ;)
<Kamion> any thoughts on adding longrun to main?
<Kamion> thom: ... or could Transmeta support be added to powernowd?
<pvh> dholbach: that sounds like the best solution
<Kamion> IME hoary-changes is much easier to follow than apt-listchanges
<zul> dholbach, top me will you...
<dholbach> zul: sorry for that - i should shut up and go back learning - you're right ;-)
<zul> heh
<Kamion> although apt-listchanges can sometimes be more complete with regard to changes made in Debian that we merged
<Kamion> I just find it hard to follow because I have multiple machines that I update irregularly
<pvh> Kamion: is that a roundabout way of saying that ubuntu specific patches are not always documented?
<Kamion> pvh: no, where did you get that idea?
<Kamion> that's false
<pvh> oh good. i must have misunderstood you
<pvh> these 8:30 classes are going to kill me
<pvh> killall -9 pvh
<pvh> i can only hope that i end up in uninterruptable sleep before then.
<Kamion> pvh: changelog entries made by the Debian maintainer don't always make it through to hoary-changes when we merge changes from Debian, depending on exactly how the Ubuntu developer built the source package
<Kamion> (i.e. -v flag to dpkg-buildpackage)
<pvh> Kamion: oh, i understand
<pvh> Kamion: apt-listchanges are more complete than hoary-changes list
<pvh> Kamion: rather than debian changelogs are more complete than ubuntu
<Kamion> indeed
<pvh> wakaru
<amu> Kamion: remasterlivecdhowto explains how to remaster i386, i'm looking for a ppc and tried mkisofs -r -T --netatalk -hfs -probe -map boot/powerpc/hfs.map -part -no-desktop -hfs-bless cdrom/install -hfs-volid MyPPC -o my_hoary_ppc.iso cdrom     
<Kamion> you will need to get hfs.map from somewhere
<Kamion> I'll try to get it into the CD image itself at some point, which will help
<stackpopper> Hey people.  I just downloaded the latest live CD for ppc to see if support had improved for imac G5 ppc.  However, the same problem has occured: the kernel freezes after spewing information about some apple firmware driver.
<amu> Kamion: hmm, from somewhere?  
<Kamion> amu: should be in debian-cd CVS
<zul> stackpopper: can you open a bug in bugzilla about it if it is not already open about it
<stackpopper> zul, sure i'll get get a pen and paper ready and upload report later on.
<amu> Kamion: all right, thanks
<zul> stackpopper: thanks
<Kamion> amu: that's obviously not suitable for a howto, though, which is why I said I'll put it on the CD
<pvh> Kamion: Did I remember to tell you how I got the installer running from an empty partition?
<Kamion> pvh: yeah, but you did so by IRC which is really transient - if you want me to remember something it might be better to e-mail it to me
<Kamion> pvh: cjwatson@ubuntu.com
<amu> Kamion: i guess so :) i'll wait for a while. 
<Kamion> pvh: (and thanks)
<pvh> Kamion: I'll write something suitable for the install documentation.
<pvh> Kamion: But it was a fairly ugly and involved process.
<Kamion> pvh: is there not something in there already, incidentally? I'm surprised ...
<pvh> Kamion: not that i could find, but I found a place it would fit.
<Kamion> archive.ubuntu.com/ubuntu/dists/hoary/main/installer-i386/current/doc/manual/ or wherever exactly it is
<pvh> Kamion: Yes, that was what I was looking at.
<Kamion> ok
<Kamion> I can get it checked in upstream, which would make translations happen etc.
<bluefoxicy> why does dselect say all kinds of crap needs to be installed for ubuntu-base
<bluefoxicy> but apt-get says ubuntu-base is fine
<Kamion> dselect installs standard packages by default if this is the first time you've run it; perhaps that?
<Kamion> "standard" => Priority: required, important, standard
<bluefoxicy> hmm
<bluefoxicy> I wonder how much would break if i did a dist-upgrade to hoary
<lamont> fire call
<trukulo> hi
<mdz> elmo: will the auto-depwaiter handle the alsa-utils/alsa-lib thing?
<mdz> or will it need a kick?
<bluefoxicy> oh what the hell it only takes an hour to install ubuntu
<lamont> or not.
<elmo> mdz: yeah
* bluefoxicy tries
<mdz> ah, lamont has not left
<lamont> canceled before I made it out the front door..
<sivang> lamont: that fast? 
<lamont> yeah - non-call
<bluefoxicy> apt should make a difference between what you want and what you need
<elmo> mdz: it just takes a cron.daily cycle after they've been built for the buildds to see them
<lamont> mdz: if the Depend is versioned, then all is well... That is, it doesn't handle anything that says 'but it is not [going to be installed] '
<mdz> so I should check back at :36 or so?
<bluefoxicy> I should be able to browse some list and see abiword selected and remove it, and it should remove everything that installing AbiWord caused that I didn't explicitly want and that I no longer need
<bluefoxicy> it'd be a short list though :P
<mdz> bluefoxicy: use aptitude
<bluefoxicy> mdz:  hmm :)
<mdz> it's done that for years
<bluefoxicy> i'll check it out after the hoary dist-upgrade happens
<bluefoxicy> mdz:  after i upgrade to hoary should I chase it with apt-get upgrade or apt
<bluefoxicy> or apt-get dist-upgrade?
<mdz> chase?
<trukulo> bluefoxicy, always aptitude
<bluefoxicy> yeah I like to update/upgrade every 5 hours or so
<bluefoxicy> or like, every few days
<mdz> apt-get upgrade only upgrades installed packages
<trukulo> bluefoxicy, or use deborphan
<bluefoxicy> hmm
<mdz> apt-get dist-upgrade will install new packages and remove installed packages in order to try to "do the right thing"
<mdz> but at any rate, it sounds like you want aptitude {upgrade,dist-upgrade} anyway
<bluefoxicy> i'll check those out
<bluefoxicy> also, {,dist-}upgrade is a shorter shell glob :)
<bluefoxicy> w00t I'm downloading at a constant 495kB/s
<bluefoxicy> Automatically selecting en_US.UTF-8 locale in addition to en_US.
<bluefoxicy> dpkg: warning, architecture `amd64' not in remapping table
<bluefoxicy> remapping table?
<Kamion> bluefoxicy: what does 'gcc -dumpmachine' print?
<smurfix> ftp://netz.smurf.noris.de/{initrd.gz,vmlinuz} has my new keyboard selection code. Please test / try to break.
<mdz> dpkg/amd64 has whined about that for ages
<mdz> haven't bothered to find out what it means
<Kamion> not seeing it here
<Kamion> the only place where that string occurs is in the implementation of dpkg --print-architecture and dpkg --print-gnu-build-architecture
<Mithrandir> bluefoxicy: what does grep amd64 /usr/share/dpkg/archtable
<Mithrandir> return?
<mdz> I have no local amd64 access at the moment due to that grub segfault bug, so I can't conrfirm
<Mithrandir> mdz: just boot with a warty cd and chroot into the system, then grub-install from there
<mdz> Mithrandir: yeah, I've just had other things to do since then
<bluefoxicy> bluefox@icebox:~ $ grep amd64 /usr/share/dpkg/archtable
<bluefoxicy> x86_64-linux-gnu                amd64           x86_64
<bluefoxicy> bash: gcc: command not found
<rubenv> apt-get install build-essential
<Kamion> bluefoxicy: the dpkg error will go away if gcc is installed. However, looking at the code, it's supposed to print just the built-in architecture in the case when gcc isn't installed, so please file a bug.
<Kamion>     /* if we have a problem excuting the C compiler, we don't
<Kamion>      * want to fail. If there is a problem with the compiler,
<Kamion>      * like not being installed, or CC being set incorrectly,
<Kamion>      * then important problems will show up elsewhere, not in
<Kamion>      * dpkg. If a C compiler is not important to the reason we
<Kamion>      * are being called, then we should just give them the built
<Kamion>      * in arch.
<Kamion>      */
<Kamion> (excuse the flood)
* mdz forgets to umount /target, waits for 160GB of fsck
<jhaltom> so i had an odd problem reinstalling hoary last night. I have 3 sata disks, and they got all reordered. What used to be sda was sdc on Hoary.
<jhaltom> As you can imagine that didn't work out right.
<bluefoxicy> Kamion: I'm not familiar enough with the software yet to give a competant bug report, plus I don't have an account and am generally lazy.  Also there's no failure, everything runs, it just prints a message I was curious about.
<bluefoxicy> AHHHHH why'd it install libqthreads  o.o
<mdz> lamont,Kamion: alsa mess is fixed, starting cloop builds
<Kamion> bluefoxicy: well, I'll file the report when I have time, but waiting for me to have copious free time is an unreliable strategy :-)
<bluefoxicy> :)
* bluefoxicy has chem2 tonight in a few hours
<mdz> jhaltom: as compared to a previous Hoary install, or a Warty install?
<jhaltom> As compared to a Warty install upgraded to Hoary.
* bluefoxicy is disturbed by this odd trend of openoffice becoming popular.
<wasabi_> I couldn't really figure out the problem exactly. It installed as sdc, grub set itself as root(0,
<wasabi_> grub refused to load
<mdz> wasabi: as long as the order didn't change on upgrade, that sounds fairly harmless
<Kamion> I really must stop making mistakes that require reboots to correct; highly time-consuming
<wasabi_> When I forced grub to load, it locked up on pivot_root.
<wasabi_> Well, the new install didn't work
<Kamion> wasabi_: I would just like to say I. HATE. GRUB.
<wasabi_> =)
<Kamion> its behaviour with respect to drive ordering is entirely opaque to me
<wasabi_> Seems to be bios order related.
<wasabi_> Or something.
<tseng> jdub: ping
<wasabi_> Anyways, a new install on my sytem did not work.
<wasabi_> I ended up removing the drives, moving them to a different controller, then it did work.
<Kamion> we've had at least one bug about SATA drive ordering
<wasabi_> I'm not sure what's responsible for linux drive ordering either
<mdz> we also have that disconcerting bug about SATA disks + ATA CD-ROMs
<Kamion> they're excruciatingly hard to debug without access to the machine though
<wasabi_> I was thinking udev was supposed to keep them in the same place always
<wasabi_> based on some device id or something
<wasabi_> am I thinking right?
<mdz> grub happens way before udev comes into existence
<wasabi_> I mean that's the only way I can think that Warty upgraded to Hoary continued to work.
<Kamion> wasabi_: you probably didn't run grub-install on upgrade
<Kamion> so device.map wouldn't have been recomputed etc.
<wasabi_> Hmm. Since upgrading to Hoary I have reinstalled the kernel numerous times... but that doesn't reinstall grub does it?
<Kamion> on upgrade, we just run update-grub, which only updates menu.lst, it doesn't reinstall the bootloader itself
<wasabi_> just updates menu.lst
<wasabi_> k
<mdz> lamont: do I read this correctly, that it sets up the 'latest' symlink/dir before actually creating the image?  isn't that racy with respect to the CD image builds?
<wasabi_> It would be interesting if udev's memory was put into the initrd heh
<Kamion> CD image uses current.cloop
<wasabi_> that way the root=/dev/blah would never have to change
<Kamion> wget -nv "$BUILDD/~buildd/livecd/livecd-current.cloop" -O "$BDIR/CD1/casper/filesystem.cloop"
<lamont> mdz: he grabs current
<lamont> not latest
<mdz> current...latest...
<lamont> latest is the most recent (including concurrent) attempt.  current is the most recent successs
<mdz> ok
<lamont> I suppose I could s/latest/attempt/ or some such
<lamont> (there is always a latest/...out, there isn't always a latest/...cloop
<trukulo> hi carlos 
<carlos> trukulo: hey!
<mxpxpod> tseng: I'm working on that patch right now
<tseng> mxpxpod: yay
<mxpxpod> tseng: now, how do I get a diff from this?
<tseng> diff from the entire source tree?
<mxpxpod> tseng: yeah, so I can send it to you
<dholbach> -ruN ?
<tseng> ok
<mxpxpod> wait, let me make sure this is going to work :)
<tseng> cp it to tomboy-new
<tseng> and diff -ruN tomboy-1.3.1 tomboy-new > icons.diff
<tseng> where tomboy-1.3.1 is a clean unpack
<mxpxpod> tseng: you mean 0.3.1
<tseng> yes.
<mxpxpod> tseng: there's going to be some auto* stuff regenerated
<tseng> oh um
<tseng> make distclean in the trees?
<tseng> to clean that out first
<mxpxpod> hold on
<tseng> you arent patching the generated bits, right?
<mxpxpod> tseng: I don't think so
* Kamion finds a shell in which $(< foo) doesn't work, and wishes Keybuk were here so he could figlet him
<lamont> Kamion: which shell?
<lamont> and can we kill it ?
<magnon> jdub: oh, I just noticed your X-Message-Flag :)
<Kamion> lamont: busybox sh
<Kamion> lamont: I kind of need it
<Kamion> $(cat foo) works just fine ...
<lamont> yeah
<mxpxpod> tseng: you just want the diff and you can deal with it?
<mxpxpod> because dpkg-buildpackage is giving me a strange error
<tseng> mxpxpod: sure.
<mdz> Kamion: where was that syntax being used?
<mxpxpod> tseng: sent
<mxpxpod> tseng: tell me if that's what you need
<tseng> ok i can merge this by hand
<mxpxpod> cool
<mxpxpod> let me know when you have an updated pkg
<tseng> not sure about having the images in a diff
<tseng> as far as packaging it like that
<mxpxpod> it should work
<mxpxpod> hmm, ok
<tseng> it should, just gross
<tseng> trying to think of a better way
<Kamion> mdz: kickseed
<Kamion> mdz: I was using it 'cos Keybuk always complains when people use $(cat foo) :-)
* lamont discovers a postfix bug he introduced somewhere around 2.1.5-1ubuntu1.  sigh.
<zul> aigh
<lamont> actually 2.1.5-3ubuntu1
<zul> aigh!
<lamont> (dropped some branding.. :-(
<Kamion> hmm, I bet the debconf->cdebconf passthrough strategy doesn't work properly with preseeding
<Kamion> since base-config is the thing that propagates preseed entries to debconf, and it won't have been run yet
<lamont> Kamion: you could alwasy teach busybox-sh to understand $(< ...
* lamont ducks
<Kamion> lamont: in my aforementioned copious free time :-)
<Kamion> tseng: images as in binaries in a .diff.gz?
<Kamion> tseng: you have to uuencode those (or similar), build-dep on sharutils, and uudecode them in debian/rules before you use them (remembering to clean up the uudecoded version in the clean target)
<wasabi_> wasan't somebody working on xdelta support for .diff.gzs?
<elmo> people have been "working on" that for years - there's still nothing usable
<mdz> cloop builds have been running for 45 minutes, and only 1 architecture is complete
<dholbach> have a nice evening... i'm off running
<wasabi_> why aren't they "getting it done?"
<wasabi_> I mean, it sounds pretty easy to me.
<lamont> fire call
<Kamion> wasabi_: people working on the dpkg-source format tend to get distracted into doing complete revamps, in my experience
<wasabi_> I had the uuencode stuff. =(
<wasabi_> s/had/hate/
<Kamion> not that I would suggest that anyone who works on dpkg is easily distra... LOOK, A FIRE ENGINE!
<bluefoxicy> lrwxrwxrwx   1 bluefox bluefox       4 2005-02-03 15:31 food -> fack
<bluefoxicy> bluefox@icebox:~ $ cat food
<bluefoxicy> cat: food: No such file or directory
<bluefoxicy> :) I'll shut up now
<thully_> so, are those udev/X bugs still causing problems?  X doesn't work on yesterday's daily builds for me.
<sivang> Kamion: hehe
<Kamion> thully_: X was fixed today
<mdz> smurfix: layout selector left me with an unusable keyboard
<Kamion> thully_: I would advise following the hoary-changes mailing list; it's useful to keep track of what's going on
<tseng> Kamion: hm, do you know of a package that does this? as a quick reference
<thully_> when will a new daily build be out w/fixes included?  I want to burn an ISO for installing
<smurfix> mdz: do the cursor keys still work?
<mdz> smurfix: no
<mdz> nor alt+f2, etc.
<Kamion> tseng: yes, give me a moment
<wasabi_> Hmm. What's this evms stuff. Should I be using it instead of LVM?
<mdz> I can't seem to get a response with any key
<wasabi_> must research!
<mdz> sysrq+b worked :-)
<sivang> Kamion: do you maintain a more current list of the desktop seed then http://people.ubuntulinux.org/~cjwatson/seeds/hoary/desktop ? 
<mdz> wasabi: evms
<Kamion> tseng: try browser-history in Debian
<Kamion> sivang: there is no more current list
<tseng> Kamion: will do, thanks.
<sivang> Kamion: ok, baz fetching the complete list has the same apps in it? (I'm interested only in desktop apps, that are visually apparent)
<Kamion> sivang: .../~cjwatson/seeds/hoary/ is simply a baz checkout
<smurfix> mdz: Hmm. Can you trace it? The initrd has strace and nc on it for a reason  :-/
<elmo>  It works with: Netscape Navigator, Arena, and Amaya. 
<elmo> Kamion: wow, cutting edge, dude ;-)
<Kamion> elmo: yeah yeah :P
<Kamion> mozilla people suck, I have a bug open asking them to un-remove the support that makes browser-history work since like forever
<sivang> Kamion: ok, thanks a lot.
<mdz> smurfix: I'm starting to think it's a kernel issue, actually
<Kamion> thully_: I suppose I can kick one off now; I hadn't planned to bother since we haven't got X fixed on ia64 yet
<smurfix> mdz: setup networking, open a shell, strace -f -s 300 -p pid-of-mainmenu 2>&1 | nc box port & exit    then do the keyboard select thing
<smurfix> mdz: I've had that problem when kbdselect dies, because it tells bterm to not listen to keystrokes temporarily
<thully_> ia64 isn't used by many people though...
<Kamion> thully_: it will be part of array 4 though
<Kamion> the daily builds aren't intended to be used by many people either :-)
<thully_> I'm actually surprised that Ubuntu's making a version for ia64 - considering that this platform is losing popularity and never caught on well
<Kamion> hm, this morning's daily build didn't happen because it clashed with a live CD build; yay locking
<smurfix> mdz: Anyway, at which point did it stop responding?
<Kamion> thully_: we had sufficient interest to make it worth a go; we may or may not revisit that decision
<mdz> smurfix: the first time through, I answered two questions, and it went on to the hostname prompt
<mdz> smurfix: at which point I could not type anything
<mdz> smurfix: a second time, I left it at the first screen of the layout selector and did not press anything
<mdz> smurfix: and eventually it froze there as well
<mdz> it just froze at the language chooser screen now
<mdz> it seems to just hang after a period of time
<smurfix> mdz: If you let the timeout time out you should end up in the normal "Select a keyboard layout" screen
<spiral> please... No one can tell me if they think that according to the link I posted, smart battery could be supported in hoary ?
<mdz> oh
<mdz> I pressed alt+f2
<mdz> and that seems to break bterm
<mdz> that happens on the live CD, too, after a point
<Kamion> spiral: 18:02 < thom> spiral: mjg59 was looking at smart battery support
<smurfix> mdz: I'll try to trace that
<mdz> probably something having a file descriptor open on the console or such
<smurfix> mdz: no, my mistake
<mdz> ok, so it is in fact getting the layout correct
<mdz> I am able to type into the hostname prompt
<smurfix> mdz: I stole SIGUSR2. I'll fix that
<mdz> the problem is with switching consoles
<smurfix> Yeah, I just noticed. :-/
<mdz> so I get one keypress (q) and one yes/no question
<mdz> (a)
<mdz> very nice
<mdz> lamont: ia64 cloop build has been running 40 minutes; is that normal?
<thully_> I fixed up the gettingubuntu wiki page yesterday - it no longer links to sounders, it links to arrays instead
<smurfix> mdz: what keyboard do you have? standard US?
<mdz> smurfix: dvorak
<smurfix> mdz: Ah, that explains the low number of questions ;-)
<elmo> mdz: something you triggered?
<mdz> elmo: yes
<mdz> I should fix my script to do them in parallel rather than in series
<elmo> I don't see anything in hooker's logs 
<elmo> for hours and hours 
<mdz> weddell
<elmo> oh, hooker's d-i, right, meh
<mdz> smurfix: what is the rationale for "do you have an 'a' key" rather than "press the 'a' key if you have one"?
<smurfix> mdz: some keyboards are subsets of one another
<mdz> hmm
<Kamion> thully: thanks
<mdz> I guess it would be fine if it defaulted to 'yes' rather than 'no'
<smurfix> mdz: I ask that question if I can't find any other key to press instead that would help decide
<mdz> most keyboards seem to have an 'a' ;-)
<elmo> mdz: seems to have finished now, FWIW
<smurfix> mdz: I'll have to look at the table to find out what the alternate branch is. What's the keycode of your 'q'?
<elmo> drwxr-xr-x  2 buildd buildd 4096 Feb  3 20:55 20050203.2
<mdz> weddell...Thu Feb 3 12:09:57 PST 2005
<mdz> adare...Thu Feb 3 12:55:19 PST 2005
<mdz> I thought it was much faster the last time, maybe I'm insane
<mdz> smurfix: what is the simplest way to find out?
<smurfix> switch to a text console, run showkey
<mdz> 0x2d
<elmo> it built two packages whilst it was building the livecd image, maybe that was a factor
<mdz> I don't want to know how long powerpc is going to take
<smurfix> mdz: Hmm, the result for no-a seems to be mac-usb-dvorak, which doesn't make much sense EXCEPT that I just looked at it, and it doesn't in fact have a mapping for 'a'
<zul> later
<mdz> smurfix: that sounds suspiciously like a bug in the map :-)
<smurfix> exactly
<elmo> well it hasn't been building anything at least
<smurfix> mdz: What's the keycode of your a?
<mdz> 0x1e
<smurfix> Ah, that's actually the standard location, no wonder nobody noticed
<smurfix> I suspect people don't usually switch from french to dvorak
<mdz> Kamion: E: Could not open lock file /srv/cdimage.no-name-yet.com/scratch/apt/hoary-i386/apt-state/lists/lock - open (13 Permission denied)
<mdz> Kamion: eek, were you attempting a live build at the same time that I was?
<mdz> smurfix: I wish I knew some more keyboard layouts to try :-)
<smurfix> Bah, I just found a selection step that doesn't in fact display any characters. Ouch. That, and fixing bterm, will be a project for tomorrow.
<enrico> elmo: did jdub get back to you with the list address?
<Kamion> mdz: is that from just now?
<Kamion> mdz: I was running an install CD build
<mdz> Kamion: yeah, shortly before I sent that message
<smurfix> mdz: Well, the layout generator seems to require another bugfix. Tomorrow -- I need to find my bed.
<mdz> Kamion: by the time I had reviewed the log, there was nothing interesting running under your uid, though I saw you were logged in
<Kamion> I need to institute locking at a higher level
<Kamion> mdz: go ahead and build now; tell me when you're done and I'll start my build
<mdz> Kamion: mine is finished
<mdz> well
<mdz> it's triggering mirrors
<Kamion> did they actually work?
<mdz> so I assume it's safe for you to go ahead
<mdz> seems to have worked, yes
<Kamion> my scripts were not designed for use by two people at high frequency
<Kamion> ok, building
<elmo> enrico: not that I saw sorry
<enrico> elmo: ok. even if jdub didn't, I'd like to go on with the announcement scheduling the migration for monday.  Any major issues against that?
<Kamion> mdz: you realise it only worked on i386, I trust
<mdz> Kamion: I only asked for i386; the other cloop builds aren't finished yet
<elmo> enrico: no, it's fine - the mail is just a small thing, I can deactivate the mails until the list is turned on
<mdz> and I desperately want to find out if we need another xorg upload
<Kamion> mdz: oh, ok
<Kamion> well, we *do* need another xorg upload, for ia64 if nothing else, and the stuff from -1ubuntu13 ought to be restored - I just band-aided it
<Kamion> mdz: what is your deadline here?
<mdz> I'm not particularly concerned with ia64 at the moment
<mdz> Kamion: when, or why?
<enrico> elmo: what do you need to create an account in the new repo?  username and e-mail address or other things?
<Kamion> well, it sounded like you had a deadline you were working to and were wondering whether you needed another xorg upload before then
<mdz> I just need the live CD back to a working state ASAP
<mdz> because it's stalling development
<Kamion> ok
<elmo> enrico: username, and either a) email + GPG key ID for them, or b) a password encrypted with my GPG key
<enrico> elmo: ok.  I'll tell in the annoucement that active people should mail me those data, and then I'll forward them to you
<spiral> mjg59: hi... Sorry, just read my log... Have you got news about smart batteries support for ubuntu ?
<Kamion> mdz: until I fix the locking issue, could you try not to initiate live CD builds on little from 8:20 UTC to about 9:20 UTC? it stalls development of the install CD when its build breaks, y'see ...
<mdz> ok
<Kamion> either that, or kick off an install CD build right afterwards :-)
<mdz> I wonder how fragmented the cloop fs is getting
<mdz> we should probably flush it sometime near release to reduce fragmentation
<mdz> say, for the RC?
<mdz> lamont: is that easy to arrange?
<Tux-Rox> Hello all, I think I may have found a bug, so I thought I'd bring it up here in the Devel channel, to see if it truely is. I have a dual proc EM64T Xeon workstation with 2GB RAM running Ubuntu 4.10 32-bit. The default kernel is not smp and the only smp kernel I could find through apt is 2.6.7. With the default, I can see my second SATA drive, but with the smp kernel I can not... well sort of.
<Tux-Rox> I can see it in fdisk and the OS says it is mounted or busy, but I can not see the contents. I tried it formatted as reiser and ext3. This seems like a kernel issue. Ideas?
<mdz> Tux-Rox: the only supported kernel in Ubuntu 4.10 is 2.6.8.1
<mdz> Tux-Rox: to get the SMP version, install linux-686-smp
<mdz> your problem arose because you downgraded from 2.6.8.1 to 2.6.7
<Tux-Rox> mdz, Oh, right. I'll give that a go. I kept searching in apt for 'kernel'. Thanks.
<mdz> yay, working live CD on i386
<mdz> Kamion: once the cloops finish, I'll want to do a full set; let me know when it's safe
<Kamion> mdz: I have to go soonish I'm afraid, but it's getting there; could you watch log/daily-20050203.2.log?
<mdz> Kamion: ok
<thom> Kamion: um, probably
<thom> send me you /proc/cpuinfo please?
<Kamion> thom: http://svn.debian.org/wsvn/d-i/trunk/packages/base-installer/kernel/tests/i386/oqo1.cpuinfo?op=file&rev=0&sc=0
<sivang> I think I will call it a day, night all
<thom> Kamion: thanks
<thully> Hi - I just tried the latest daily live CD build and X wouldn't start - has X on the latest live CD build been fixed yet?
<thully> (otherwise I'll report this as a bug)
<thully> aha - a new live/install cd are being uploaded - I'll try those and then report
<crimsun> thully: many of those changes from -1ubuntu13 were reverted because they "broke the live CD in different, but equally non-productive, ways"
<crimsun> thully: (from the changelog for -1ubuntu14. Note that Hoary currently has -1ubuntu15.)
<thully_> I've been in touch with the developer of the TrackPoint patch, and he doesn't understand why Ubuntu removed it.  Do you think somebody could work with him and get the issues solved, so us TrackPoint users can enjoy advanced features (like push-to-click and middle button scroll)
<crimsun> thully: according to 2.6.10-10, it's buggy and, in some cases, breaks ps/2 mice
<dholbach> re
#ubuntu-devel 2005-02-15
<thully> Just tried new live CD - my X problems are fixed (in fact I'm typing from it now)
<thully> downloading install cd now
<amu> thully: .7 ? 
<thully> .6, actually
<mdz> sladen: ping?
<thully> there is already a new one!
<mdz> .6 was an i386-only build to test whether the X fix worked
<mdz> it did, so I built .7 for i386/amd64/powerpc/ia64
<thully> is there any difference?
<mdz> no functional difference on i386, no
<thully> Also, is there a chance that .7 will be array 4?
<mdz> there is a chance, yes
<mdz> if all tests succeed
<thully> I'm downloading install cd build now
<AndyR> lo ppl
<dholbach> i'm off to bed guys... my thighs, my lower legs... everything hurts :-) *wave*
<bluefoxicy> you know
<bluefoxicy> that could really piss someone off.
<bluefoxicy> I upgraded to 2.6.10-2-amd64-generic or something
<bluefoxicy> and upon loading 8139too
<bluefoxicy> the kernel breaks
<bluefoxicy> junk is spewed to the terminal
<bluefoxicy> and the root filesystem (xfs) gets corrupted.
<bluefoxicy> miiiiiiiiight want to not do that.
<bluefoxicy> but I've reinstalled now, manually, breaking the install process and now I don't know how to set my default console keymap to dvorak
<bluefoxicy> also I don't know how to generate the prettified/automated /boot/grub/menu.lst since grub-install (in the installer) never works.
<bluefoxicy> anyone know how to fix my keymap and timezone up?
<mdz> grub is broken on amd64 at the moment, but there is a known workaround
<mdz> this is all in bugzilla
<bluefoxicy> I know how to make grub work manually (grub, root (hd0,0), setup (hd0)
<bluefoxicy> mdz:  how about keymap?  that in bugzilla?  (I broke that, not you, so I'd imagine not)
<mdz> that's fallout from the installer breaking
<bluefoxicy> yeah
<mdz> so if you go back and use the workaround, that'll take care of itself
<bluefoxicy> Can I get a hint on what ot search bugzilla for?
* bluefoxicy checks to see if he's got any hintcoins left
<Kamion> mdz: there isn't a known workaround that works when booting from CD, unfortunately
<Kamion> bluefoxicy: grub doesn't work manually like that right now, AFAIK; it's being hit by a kernel bug, it's not an installer bug
<elmo> oh dear god, what's mdz done to the seeds
<mdz> elmo: oo.o2
<mdz> and thereby kdelibs
<Riddell> oh goody
<mdz> how bad is it?
<bluefoxicy> Kamion:  I just installed grub like that
<bluefoxicy> Kamion: problem is ubuntu still stops and doesn't installa  proper menu.lst
<Kamion> bluefoxicy: that's surprising, since it doesn't work for me
<bluefoxicy> I forgot how to trick it into thinking it worked (I killed a certain process and it did it)
* bluefoxicy is very mean to the install CD
<Kamion> it is grub's 'install' command (called by 'setup') that triggers the segfault
<bluefoxicy> hum.
<mdz> perhaps you used a different grub
<elmo> mdz: only 7 new source packages; it's just the biggest change in a while, shocked me
<mdz> though, that wouldn't help, would it
<Kamion> although grub-install may use somewhat different arguments, actually
<bluefoxicy> mdz:  hoary amd64 install cd
<Kamion> mdz: no, that would imply that it was grub's fault, which it isn't
<bluefoxicy> Kamion:  I just use setup (hd0)
<Kamion> unless you count using nested functions as "fault"
<bluefoxicy> after using root
<bluefoxicy> o_o
<bluefoxicy> nested functions are the children of satan
<Kamion> grub-install does setup --stage2=/boot/grub/stage2 --prefix=/boot/grub (hd0)
<Kamion> or similar
* bluefoxicy has a list of 29 bugs he's trying to look through for this so-called workaround
<mdz> bugzilla is hiding it
<lamont> ok. so, no matter how well you swim, everyone where PFD's while you're in a boat.  'k?
<lamont> mdz: ia64 cloop runs 40-50 min, iirc
<mdz> maybe fabbione WONTFIXed it :-P
<lamont> mdz: flushing it is easy - just tell me when you want to pay the pain... Do you want to flush all 4, or just ia64/amd64?
<pitti> night everybody
<mdz> pitti: night
<mdz> lamont: I think RC would be a good time
<Kamion> bluefoxicy: there is no workaround that works on the install CD, as far as I'm aware.
<mdz> Kamion: the noexec=off or whatever doesn't help?
<Kamion> bluefoxicy: somebody who actually understands this nx bit crap needs to look at it
<bluefoxicy> Kamion:  what about regenerating /boot/grub/menu.lst
<Kamion> bluefoxicy: update-grub does that
<Kamion> mdz: that works around the bug in an installed system, but for some reason not when booting from CD
<mdz> bluefoxicy: #6082
<Kamion> mdz: I have absolutely no idea why
<bluefoxicy> Kamion:  yeah an NX-bit may kill nested functions
<Kamion> bluefoxicy: it bloody well shouldn't, that's what PT_GNU_STACK is for!
<bluefoxicy> mdz:  thatnks, I was on 5059 or such
<tseng> bluefoxicy: emuplt?
<Kamion> the entire design of all of that was to *prevent* it killing nested functions
<bluefoxicy> tseng:  emutramp?
<tseng> bluefoxicy: yes.
<tseng> that.
<Kamion> and /sbin/grub correctly has an executable bit set in its PT_GNU_STACK program header, which is being correctly read by the kernel
<bluefoxicy> tseng:  yeah, better design than PT_GNU_STACK for nested functions, but I didn't want to bring PaX into this
<tseng> is this kernel.org NX then?
<bluefoxicy> Kamion:  odd.
<bluefoxicy> hmm
<Kamion> as far as I can tell, the memory management layer that's supposed to make the page executable simply isn't working properly in 32-bit mode, or something weird like that
<bluefoxicy> tseng:  vanilla ignores PT_GNU_STACK?
<tseng> no
<Kamion> although I tried with a trivial 32-bit example and it seemed to work
<Kamion> tseng: yes
<Kamion> vanilla 2.6.10 does not ignore PT_GNU_STACK
<tseng> dumb question, does the app have the markings?
<Kamion> tseng: 00:24 < Kamion> and /sbin/grub correctly has an executable bit set in its PT_GNU_STACK program header, which is being correctly read by the kernel
<bluefoxicy> Kamion:  ahh, I've noticed with PaX that relocations are still killed in 32 bit on 64 bit kernels, even though PaX is set to allow relocations (as a legacy option until all relocations are removed from 99% of all code at least)
<tseng> right..
<Kamion> bluefoxicy: that sounds similar
<bluefoxicy> Kamion:  this may be a similar issue due to the design of the kernel, but I don't know.
<bluefoxicy> pipacs doesn't seem to know wtf is wrong with it either, last i asked
<mdz> Kamion: confirmed that noexec=off doesn't fix it when booting from the live CD, how weird
<Kamion> I reported to linux-kernel and there was no response
<tseng> maybe mingo was too busy trolling pagexec
<bluefoxicy> XD
<Kamion> mdz: it certainly baffled me
<bluefoxicy> tseng:  vanilla has no execshield though
<Kamion> *sigh* can we not get into inter-security-group flamewars here please?
<tseng> bluefoxicy: bits and pieces
<mdz> Kamion: aha
<bluefoxicy> Kamion: I'm trying so hard not to
<Kamion> it can't be that hard
<mdz> Kamion: noexec32=off ?
<Kamion> mdz: that option was removed, last I checked
<mdz> oh
<Kamion> mdz: (you could always try it though ...)
<bluefoxicy> heh
<wasabi> darn grub
<wasabi> argh
<wasabi> clean install still just boots to a blinking cursor
<mdz> Kamion: doesn't help
<mdz> confirmed that neither noexec nor noexec32 help on the CD boot, but noexec does on the hard disk boot
<mdz> maybe something with the command line parsing?
<Kamion> could be, but that would be ... strange
<Kamion> mdz: you could try editing syslinux.cfg and putting noexec=off on it earlier on?
<mdz> that's the only interesting difference I can think of
<Kamion> although I think Kurt Roeckx said that didn't help, iirc
<thully> just finished installing from latest install build... looks good, and at least in my experience is Array 4-ready
<thully> well, network applet crashes when you open it and quit it - that's the one new thing I've seen so far
<Kamion> netapplet recently got uploaded ...
<mdz> Kamion: hmm
<thully> I will try dist-upgrade and see if that fixes it
<mdz> Kamion: parse_cmdline_early uses memcmp for comparison, while nonx_setup (now called from it) uses strcmp
<mdz> i.e., the string is not null-terminated
<mdz> or may not be
<Kamion> thully: I was more thinking that it might have been introduced by that
<Kamion> mdz: hmm
<mdz> I would naively expect that it would still work if noexec were the last parameter on the command line
<lamont> Kamion: wrt ia64 boot magic - I assume that we'll create a separate boot image for livecd eventually, yes?
<mdz> but that's exactly where it should be ending up
<thully> It happens when you open it and close it quickly afterwards
<Kamion> lamont: yeah, that's the plan, or figure out how to push the bootloader config over to debian-cd
<lamont> mdz: do you want to flush the images for the RC image, or a few days earlier, so that some of us can sync the bulk of the CD before the RC ships?
<lamont> Kamion: cool
<mdz> lamont: I want to flush them at such a time that it doesn't interfere with rsyncing down iterations leading up to final, but still minimizes fragmentation
<bluefoxicy> um
<lamont> mdz: right.  and that requires a compromise between the two extremes, I think...
<bluefoxicy> still wondering about that keymap thing
* bluefoxicy wants to change the keymap for the console
<mdz> please take that to #ubuntu
<Kamion> mdz: I find it slightly puzzling that __supported_pte_mask is not set to _PAGE_NX by default
<Kamion> unless I'm missing something
<mdz> Kamion: got it
<mdz> Kamion: on the CD boot, 'console=tty0' ends up after noexec
<Kamion> oh, syslinux adds that?
<mdz> so I think changing strcmp->(strncmp|memcmp) will at least get noexec working properly
<mdz> apparently so
<Kamion> funky
<mdz> just checked with the daily-live amd64
<mdz> I wonder if it's fixed in bk already
<Kamion> I'll do a test build on concordia and bung it into an image
<mdz> that should be sufficient to roll an array 4
<Kamion> yep
<mdz> I can do a round of tests this evening, and you can bless it in the morning, if you like
<Kamion> mdz: I'll be up for a bit yet anyway
<lamont> mdz: did we want to sync mono 1.0.5 from debian?  that'd cure universe of it's tainted state
<mdz> lamont: sure
<lamont> 1.0.4 should really not be allowed to ship, since it's ftbfs, and all that...
<lamont> tseng: what all do we need to sync for 1.0.5?
<tseng> lamont: everything was in the mono source last i looked
* lamont keeps wanting to spell it 'thomboy' for some reason. :-)
<tseng> lamont: im doubting it changed from 1.0.4 to 1.0.5 heh.
<lamont> tseng: not what I meant... we need to sync mcs_1.0.5-2, what else?
<tseng> binary package names?
<mdz> so this bug was the first thing that made me realize that this noexec functionality exists upstream now
<mdz> does it actually provide us some security?
<Kamion> I think it does; stack pages are non-executable by default with any vaguely recently built binary
<Kamion> apart from a few wacko cases like grub
<mdz> vaguely recent, as in -> likely all of main?
<tseng> it certainly does provide a better situation than without
<tseng> without any NX that is
<Kamion> mdz: the toolchain patches have been in for ages
<Kamion> you can look for the PT_GNU_STACK header using readelf -l
<elmo> mdz: yes, for modern CPUs
<Kamion> if the header isn't there, it's an old binary
<tseng> lamont: mcs and all that iirc are all from one source package
<Kamion> mdz: oh yeah, you have to have the nx bit available in hardware, as elmo says
<tseng> lamont: i will grab it and play along
<mdz> if it makes exploitation slightly harder, and we don't pay for it in terms of having to maintain some awful patch, that's excellent
<elmo> mdz: the NX stuff in mainline only works with hardware support
<Kamion> so it's really new P4s or AMD64 systems
<elmo> mdZ: yep
<tseng> hm i was unaware that p4s had any NX
<mdz> elmo: are our P4s in the DC new enough?
<tseng> nocona does not
<Kamion> $ readelf -l /bin/ls | grep -A1 STACK
<Kamion>   STACK          0x0000000000000000 0x0000000000000000 0x0000000000000000
<Kamion>                  0x0000000000000000 0x0000000000000000  RW     8
<Kamion> ^-- new binary with non-executable stack pages
<Kamion> $ readelf -l /sbin/grub | grep STACK
<Kamion>   STACK          0x000000 0x00000000 0x00000000 0x00000 0x00000 RWE 0x4
<Kamion> ^-- new binary with executable stack pages
<Kamion> tseng: hm, I thought new P4s did, but I might have been misinformed; I know Intel and Transmeta have adopted the change in some CPUs
<mdz> mizar:[/usr/bin]  readelf -l tset | grep STACK
<mdz>   STACK          0x000000 0x00000000 0x00000000 0x00000 0x00000 RW  0x4
<elmo> mdz: the machines will be getting next week maybe; not the existing ones, I don't think
<mdz> that's the oldest thing in /usr/bin on my hoary desktop
<elmo> s/will/we'll/
<Kamion> mdz: you can check by looking in the 'flags' line in /proc/cpuinfo
<lamont> tseng: I see mcs, mod-mono, mono, monodevelop, monodoc, monopd.. which of those should we sync is the question...
<lamont> or is it really just mcs?
<elmo> BOGGLE
<tseng> monodevelop i believe will be the same version we have
<elmo> http://anandtech.com/cpuchipsets/showdoc.aspx?i=2111
<elmo> if that articles true, that may not be such a win
<tseng> debian didnt have it at the time so i bumped it and did CDBS love
<elmo> specifically the "you must enable PAE" bit
<tseng> you can grab the debian one if youd like, non critical
<tseng> mcs and mono are the biggies
<Kamion> mdz: AMD's NX got marketed as something like "Enhanced Virus Protection" in the Windows world. :-)
<elmo> yeah, they got slapped down in several european countries for advertising it like that too
<Kamion> not surprised
<tseng> lamont: want me to do a test run?
<mdz> does EM64T implement it in a non-suck way?
<elmo> if you're running in amd64 mode, yeah
<tseng> lamont: then i can give you better answers, its been a long time
<lamont> tseng: sure - I'm going to start with a sync req for mcs and mono, and we'll take it from there...
* lamont doesn't use mono, you see...
* tseng nods
<tseng> mcs and mono are the core
<tseng> the other apps you mentioned are ancillary
* lamont sends mail so mdz can ack it
<tseng> and i havent been tracking all of them in debian, admitedly
<lamont> s/sends/has sent/
<wasabi> grub or lilo, that is hte question
<tseng> i hooked up with meebey and dajobe today, pretty cool guys
<mdz> grub is so useful that I am enticed every time, even though it sucks
* lamont goes to feed horses -back in a few
<tseng> so ill be more up on the debian-mono scene soon hopefully
<mdz> Kamion: did I talk with you about publishing the install and live CDs together?
<mdz> Kamion: in terms of directory layout?
<Kamion> mdz: yeah, I thought I'd agreed?
<Kamion> oh, maybe not
<Kamion> surely /releases/hoary/array-4/hoary-{install,live}-$ARCH.iso?
<mdz> yeah
<Kamion> with one of those shiny HTML pages?
<mdz> I didn't know if that required changes in your publishing infrastructure or not
<mdz> definitely shiny
<Kamion> oh, probably requires minor changes, but practically every release I do does for one reason or another ;-)
<mdz> manual automation :-)
<Kamion> it doesn't really matter, I can always move them into place by hand if need be
<Kamion> the important thing is to have it not suck for the releases that I have to do in a real hurry (i.e. RC, final)
<mdz> do you think it would be at all sensible to build them in a single pass? i.e., merge cron.daily and cron.daily-live, and sync the archive only once so that it's consistent
<mdz> s/consistent/guaranteed &/
<Kamion> mdz: I think that's just going to increase build time to the point where it frustrates us both when we're trying to build install and live CDs separately
<Kamion> although I'm happy to do that as a one-off for array candidates
<thully> hi - I just put my laptop to sleep and woke it up, and the clock moved back 5 hrs - why may this happen?
<mdz> well, yeah, we would need to be able to limit it when needed
<mdz> thully: I think there's a bug open about that
<mdz> we need to reset the clock after resume
<thully> OK - that's what I thought the problem was
<mdz> maybe there isn't one; I can't find it
<mdz> I have heard of that problem before at any rate, and it needs to be fixed
<Kamion> mdz: hm, is an ISO from 2005-01-13 rsyncable?
<Kamion> (live)
<thully> OK - I'll make a bug report now
<mdz> Kamion: I think the rsyncability began at ~2005-01-20
<Kamion> mdz: oh well
<lamont> yeah it was the 20th or so
<thully> I just filed a bug - #6147
<daniels> fabbione: if xorg was failing on sparc, I'd be interested in the logs
<thully> I'll go look into this
<mdz> Kamion: in a fit of madness today I wrote a little program to sniff around and tell me which version of a package is present in (local mirror, isos, d-i initrds, cloop images) * (i386,amd64,powerpc) on little
<mdz> a bit like madison-lite on crack
<mdz> maybe this would be useful to you as well?
<Kamion> might well be; although I kind of concur with the fit of madness bit ;-)
<Kamion> but, cool
<thully> Hi - i know what the problem is that's causing the clock issues
<thully> it's how hwclock is invoked in the /etc/acpi/resume.sh script
<wasabi> this whole language pack idea is curious
<wasabi> im not sure I understand it
<lamont> mdz/Kamion: want me to have the build{LiveCD,DI} scripts immediately exit, or do you like having the boring output and the tied up terminal?
<thully> hwclock doesn't autodetect whether the hardware clock is set to UTC or local time - it assumes based on what options it is invoked with.  If there is no --localtime or no --utc, it will default to the last option used.  If no option was used before, it will default to local time.
<thully> in our case, there is no --localtime or --utc, so it assumed local time
<lamont> wasabi: the lang pack motivator is to be able to deliver new translations for packages after the release is out the door.
<Kamion> thully: so it should source /etc/default/rcS and get it from there, probably
<wasabi> ahhh.
<wasabi> So, all of the translations for ALL packages are moved into it?
<lamont> wasabi: but you're right.  trying to understand it makes brains hurt.
<lamont> all of main
<wasabi> odd.
<wasabi> that sounds like a lot of useless text.
<thully> Kamion - yes
<wasabi> for instance, if I had a server, headless, no GUI, but I wanted japanese translations of some console programs...
<lamont> wasabi: but only for the languages you want, as opposed to having all the languages you don't want in each of the individual packages.
<wasabi> I'd need all the translations for all of gnome too?
<Kamion> I think it's a net loss as it stands. On the other hand I can see that it'd be a net gain once we have enough translations. Dunno ...
<lamont> wasabi: what Kamion said
<wasabi> It sounds confusing as hell to me.
<wasabi> Like, files for one program are in another heh.
<Kamion> well, in another package, but yes.
* wasabi just not seeing teh point.
<thully> Kamion: once this is fixed in acpi-support, bug #6147 can be closed
<Kamion> wasabi: I think if you think of it in conjunction with the existence of Rosetta it makes a bit more sense
<mdz> thully: please add that information to the bug repoert you filed
<wasabi> i keep hearing that name
<wasabi> but haven't bothred to look it up yet
<lamont> wasabi: massive translation project
<lamont> (that's the 3 word summary)
* lamont cooks dinner
<mdz> wasabi: you also currently have translations for all languages installed for the packages you have
* netjoined: irc.freenode.net -> kornbluth.freenode.net
<mdz> wasabi: e.g., 500k * N for gcc
<mdz> so it has some gains and some losses
<Kamion> it's a question of which multiplier you remove
<mdz> we're betting that the language multiplier is going to grow faster
<jbailey> I have an initrd-tools bug that only occurs on 2.4.  The bugzilla page suggests that bugs like this should be closed as 'notwarty'.  Is that tag a generic Not For Us?
<mdz> jbailey: yes, there's aa bug open about renaming it to NOTUBUNTU
<mdz> but nobody's minding the bugzilla store at the moment
<wasabi> every day i see ubuntu-update manager improve... what an awesome program
<Kamion> mdz: oh, install CD build finished ages ago, BTW, if you want to kick off a live CD build
<Kamion> thully: ^--
<mdz> Kamion: kicked
<thully> I installed from the last one (released a couple hrs ago) and it works pretty good
<thully> also, live cd worked pretty good also
<mdz> Kamion: does this have the fixed amd64 kernel?
<thully> only main problem is that with the network applet crashing on close
<mdz> and if not, can I download one and patch it in?
<lamont> jbailey: NOTWARTY means 'look at it after we release, since it doesn't apply to the version in warty^Wubuntu'
<Kamion> mdz: what fixed kernel? :)
<mdz> Kamion: oh, I thought you said you were making one
<mdz> Feb 03 16:48:58 <Kamion>        I'll do a test build on concordia and bung it into an image
<Kamion> yeah, but only for test purposes as yet, I was going to patch it in and see what happened
<Kamion> but I get:
<Kamion> modprobe: FATAL: Could not load /lib/modules/2.6.10/modules.dep: No such file or directory
<Kamion> indefinitely
<Kamion> wonder what I broke
<mdz> you didn't set EXTRAVERSION
<lamont> mdz: fwiw, ia64 live is NFG until linux-source-2.6.10_2.6.10-14 - so no array 4 ia64-live
<Kamion> oh, good point
<mdz> you didn't build it using linux-source-2.6.10?
<mdz> Kamion: a little symlink love should take care of it, for a test...
<Kamion> I did, weird
<Kamion> although I stopped it partway through to use make -j50, maybe that did it
<jbailey> Do you just hate your io channel?
<mdz> yeah, it probably passes it on the command line
<mdz> jbailey: concordia loves it
<lamont> jbailey: he wants it to feel important
<Kamion> jbailey: concordia does a kernel in like a minute with that
<jbailey> Concordia is a box I haven't heard of yet.
<lamont> Kamion: way cool
<Kamion> jbailey: one of the porting boxes
<jbailey> Ah, cool.
<thully> so, is polypaudio still planned for hoary?  I saw it was in universe (or maybe it's main) but not used by default
<mdz> yes
<elmo> err
<elmo> it is?
<mdz> hypothetically speaking, GNOME is still planning to move, and we are still planning to follow them
<Kamion> mdz: EXTRAVERSION> ah, so it does
<Kamion> mdz: kdelibs in main; does that mean that we can revert some of the gross hacks to remove it that break stuff? :)
<Kamion> (kvim, frex)
<mdz> Kamion: absolutely
<Kamion> hoorah
<mdz> once elmo says it's done
<mdz> Kamion: live build is done, btw
<Riddell> what is frex?
<Kamion> lazy-man's shorthand for "for example"
<thully> is there going to be any audio cd burn support in Hoary - last I remember there was no forthcoming solution.
<Riddell> well kvim isn't in kdelibs (I would hope)
<Riddell> thully: with kdelibs in main, I humbly recommend k3b  :)
<lamont> Riddell: but kvim was killed so that vim didn't pull kdelibs into main.
<Kamion> and it was killed really badly; we ended up with a kvim package containing only a diversion of vim
<Kamion> and nothing to replace it
<lamont> Kamion: lol
<lamont> we should fix hta
<lamont> that
<thully> yes - if kdelibs goes in main, it would be great to find some way to make an exception to allow k3b, as we desperately need a decent CD-burning app - nautlius just doesn't cut it (no audio CD, no multisession CD)
<thully> nautilus
<Kamion> the plan for hoary was coaster, I believe
<Kamion> we have no intention of putting kdelibs on the CD
<jdub> Kamion: plan for hoary was "if any of them are actually ready"... :)
<Kamion> well, yeah :)
<Riddell> lamont: ah, ok
<mxpxpod> tseng: did that work for you?
<Kamion> mdz: do you object to pulling libqt-perl into main? it's pretty small once you have kdelibs, and would allow me to revert a debconf hack.
<tseng> mxpxpod: didnt get to it tbh
<mdz> Kamion: sounds fine
<tseng> mxpxpod: planning to just play with it here before cleaning it up
<mxpxpod> tseng: haha, ok
<tseng> mxpxpod: ill do it now
<tseng> it sounds like we need to uuencode the images in the diff
<mxpxpod> tseng: that sucks
<mxpxpod> tseng: can't you just submit the diff upstream?
<mxpxpod> and get them to release a new version ;)
<tseng> no, the author rejected the icons
<mxpxpod> WHAT?
<tseng> yeah.. doesnt fit with the goals of tomboy, too industrial
<mxpxpod> that's retarded
<tseng> whatever that means
<tseng> tintin can die
<mxpxpod> so he'd rather have a retarded icon?
<tseng> apperantly
<tseng> then some guy posted some absolutely awful icons of a notebook with stick notes on it
<tseng> the icon wasnt worthy of window 3.1
<tseng> thats where the thread ended..
<mxpxpod> haha
<mdz> Kamion: we ought to get in touch with henrik and get a copy of the latest OpenCD stuff to go on the hoary images
<wasabi> okay this is getting annoying. am i just not going to be able to attach these drives? the ordering will simply not correct itself.
<wasabi> there has to be a better long term solution for this too
<wasabi> the kernel root= option should take a uuid heh.
<wasabi> haha and my system just became unusable at "Checking all file systems". A failure, dropped me to console... no USB loaded!
<Kamion> mdz: cool, that kernel fix seems to work
* lamont dinners
<Kamion> just doing a full test now, then I'll fire it off to fabbione and go to bed
<wasabi> there is no way i can think of to boot my system with these drives attached. =/
<wasabi> except to boot, alter menu.lst and fstab, then reboot.... ugh
<mdz> Kamion: sounds good
<mdz> Kamion: how big a project do you think it would be to make the powerpc live CD automagically choose the proper kernel?
* jdub covers his eyes.
<lamont> Kamion: are we doing weekly dvd images yet?
<mdz> lamont: yes
<lamont> cool
<lamont> not that I have bandwidth, of course... but the full opencd should be on those..
<mdz> http://cdimage.ubuntu.com/weekly-dvd/
<mdz> lamont: how did that stuff work the last time around?
<Kamion> mdz: in what way?
<mdz> lamont: do you have a document which says which pieces go where, for the opencd content?
<mdz> Kamion: rather than having to type 'power4', etc. at the initial prompt
<Kamion> mdz: find me a yaboot guru who isn't already insane ...
<wasabi> okay... so... this is a fairly serious hoary problem, in my book anyways. Should I just file a bug on it or does anybody want me to screw with it?
<lamont> mdz: henrik provided a subset-ized opencd collection, that was untarred into the CD image before the final mkiso
<Kamion> it's not possible specifically for the live CD. It might be possible for both the install and live CDs in tandem
<lamont> mdz: it was litterally 'cd chroot; tar xzf .../WinFOSS-0.4.tar.gz' or some such
<mdz> Kamion: if it got done, I'd certainly want to use it for both
<mdz> lamont: ok, so we just need to ask him for a new tarball of the same kind
<Kamion> mdz: maybe a week or so for a powerpc expert, considering the need for extremely extensive testing of that sort of change
<Kamion> somebody would need to specify the yaboot.conf extension
<mdz> Kamion: well, ideally it would still ask, but choose a smart default
<lamont> mdz: with a size cap
<mdz> until we got confidence in it
<Kamion> nevertheless you need to extend the configuration file format (and upstream will guaranteeably not accept it)
<Kamion> and that whole thing's being done without a libc, so it's prone to breakage
<mdz> guaranteeably? :-/
<Kamion> pretty much, yes
<Kamion> the only things yaboot upstream is currently accepting are changes to stuff around the edges like ofpath
<Kamion> that's not to say that we can't do it anyway, he'll just throw a tantrum :)
<Kamion> on the other hand Sven Luther will probably love you for going against what Ethan wants ;)
<mdz> it's a serious usability handicap
<Kamion> anyway, personalities aside, need to figure out how to do it in a suitably generic way
<Kamion> the configuration file change will be encoded in people's yaboot.conf forever more, since no-one ever changes bootloader configuration if they don't have to
<Kamion> although actually not, I guess, it only has to go in CD yaboot.conf files
<mdz> yeah
<jba> hey guys
<Kamion> mdz: I'm going to put noexec=off in the amd64 syslinux.cfg in such a way that it gets propagated to after the first reboot
<mdz> Kamion: are you sure?  I'd prefer not to make that change permanent
<Kamion> mdz: this will unfortunately mean that when we finally fix the bug we'll need to include something in the upgrade notes telling people to remove that from their grub configuration
<Kamion> mdz: I see no other way, given that if somebody runs 'grub-install "(hd0)"' post-reboot then it'll hose their system
<Kamion> although I suppose we could just say "don't do that then", since it's a pre-release
<mdz> Kamion: people don't generally do that
<mdz> and grub or the kernel will be fixed eventually
<Kamion> true, I suppose I'm an unusual case
<mdz> at least it blows up spectacularly when folks attempt it
<mdz> as opposed to in the installer, where it appears to succeed
<mdz> grub-install desperately needs set -e
<Kamion> yeah, grub-install should be fixed
<mdz> I especially love the way that at the end, it says "no error reported"
<mdz> as if it has any idea whatsoever
<wasabi> surely the linux kernel supports some way to pass root= which is indepent of drive order. =(
<Kamion> mdz: actually it does sort of, it's grepping for "Error [0-9] *: " in grub's log file
<mdz> wasabi: the kernel isn't likely to ever support a feature like that
<Kamion> I wonder if earlier parts of grub-install are actually 'set -e' clean; there are a few bits that look suspicious to me
<mdz> but it should be straightforward to do it by label or by uuid in userspace
<wasabi> well this kind of makes my hotplug sata a pain in teh ass on linux
<mdz> which is where the root filesystem is really mounted anyway
<wasabi> or, at least on hoary.
<wasabi> when I boot with the drive in, it takes sda and pushes my real sda down to sdb
<mdz> Kamion: if you end up doing some more grub-installs for testing, it would be worthwhile to slap set -e on it
<mdz> and see if it smokes
<Kamion> ok
<wasabi> mdz: somehow windows does this right. =)
<wasabi> somehow warty did it right too, and that's a bit annoying too. =/
<mdz> you got lucky, probably
<mdz> maybe in both cases
<mdz> but this is off-topic for this channel
<wasabi> k
<mdz> unless you want to discuss the extensions to initrd-tools to add the functionality to mount root by label or uuid
<mdz> which would be a great feature
<wasabi> im not smart enough yet. =)
<jba> aah initrd my friend
* jbailey blinks.
<jbailey> mdz: Do you want that for Hoary?
<jbailey> mdz: I'd rather implement something like that against udev so that I could sanely get partition information but I don't think it should be that hard, really.
<srbaker> jba, what, mounting by label or uuid?
<mdz> jbailey: not for hoary, no
<jbailey> mdz: Oh lovely.  I think I have almost all of the initrd-tools bugs you assigned me as pending now and in a local tree.
<jba> jbailey,  i think that message by srbaker was meant for you
<mdz> jbailey: great
<jbailey> jba: Yeah, looks like. =)
<srbaker> that's what i meant
<mdz> jbailey: did you have a chance to look into the ide-{disk,cd,generic} stuff?
<mdz> that I really do want for hoary
<jbailey> mdz: I loaded the ide.rc onto my box today, and hotplug picks it up.  Tomorrow morning is for reviewing the init stuff.
<jba> sorry for stuffing up the tab completion
<srbaker> jba, you should be.
<jba> in that case, I take it back
* jba sticks his tongue out at srbaker
<jbailey> mdz: I haven't done anything with the ide-generic magic to make sure it gets loaded last, though.  
<thully> hi - found something interesting w/latest suspend code - suspend-to-RAM used to take 10% of my battery per hour, now it takes 5% (so it is actually tolerable for short-to-medium periods of time)
<jba> thully, now that you mentioned it, i did notice that suspend to ram on low power seemed to kill the laptop quickly (when i turned it back on laptop complained of being below 10% and wouldn't turn on)
<tritium> thully, S1 or S3 sleep?
<thully> S3, I think - whatever pressing Fn+F4 does in Hoary
<thully> I've got a ThinkPad T42 that has had trouble w/suspend - it has always taken 10% of power/hr in ACPI suspend-to-RAM,
<thully> This is a known issue for some T42s on Linux, and nobody has resolved it (although Ubuntu has made it work better somehow - 5%/hr I can tolerate somewhat - 10%/hr is intolerable)
<thully> I ended up using S4 exclusively in the past
<thully> (S4=suspend-to-disk, btw)
<tseng> daniels: what did you guys use for streaming at akademy? webcams, dv?
<daniels> tseng: dv with flumotion
<tseng> hm
<daniels> Kamion: ping
<daniels> mdz: ping
<daniels> amu: ping
<lamont> EFLOODPING
<daniels> ah, lamont, you'll do :)
<lamont> dambn
<lamont> wassup?
<daniels> i'm mastering a new live cd iso as detailed in LiveCDCustomizationHowTo
<daniels> but where do I get .disk/info, and isolinux/isolinux.bin?
<lamont> I rather expect you get them from a previous iso?
<lamont> that is to say, not sure - haven't read that page..
* lamont reads
<daniels> lamont: ah, so it is -- thanks
* lamont sleeps
<daniels> lamont: night dude
<Riddell> daniels: what's the status of dbus with qt?
<daniels> Riddell: awaiting testing to see if they're any good or not
<daniels> http://people.ubuntu.com/~daniels/dbus/
<fabbione> morning guys
<daniels> morning fabbione
<smurfix> *yawn*
<fabbione> mdz: ping
<fabbione> daniels: busy?
<daniels> fabbione: not hugely, just trying (so far in vain) to write a new live cd image
<daniels> fabbione: what's up
<daniels> ?
<fabbione> daniels: do you have time to prepare a l-r-m to handle the ABI change and send me diff so that i can upload after testing?
<daniels> not today, sorry
<fabbione> ok
<fabbione> no problem
<daniels> probably not till the weekend
<daniels> er
<fabbione> we have a chicken egg problem
<daniels> not till monday
<daniels> heh
<fabbione> i can't upload the kernel and without the kernel Kamion cannot release array4
<daniels> ah :\
<daniels> unfortunately my weekend is stacked full (more work on the other house, which is flooded, unavoidable family stuff) already
<daniels> but i'll see if I can't get you an l-r-m by your Monday?
<daniels> er, your Sunday
<fabbione> nah don't worry
<fabbione> i will see with Kamion and mdz
<fabbione> if the latter is awake
<daniels> ok, thanks
<daniels> i don't have any changes apart from some new modules
<fabbione> ok
<fabbione> interesting...
<fabbione> suse is looking at our kernel :-)
<mdz> fabbione: morning
<mdz> daniels: pong
<daniels> mdz: nevermind, lamont pointed me in sort of the right direction, and I got to remaster a live CD image
<mdz> daniels: was there an error in the howto?
<daniels> several
<daniels> firefox then thoughtfully crashed on my editing session, so I threw up the cbf flag and used the limited time I have for today on fixing casper instead
<mdz> I fixed a couple of things earlier today
<mdz> but I haven't actually tested the procedure myself
<daniels> -V needed quotes around its argument, isolinux/* and .disk/* won't exist for most people (need to prepend extracted_cd/)
<daniels> and a couple of other things
<fabbione> mdz: the fix for the noexec seems wrong to me, but i will apply it anyway if you tested it.
<fabbione> mdz: the problem is the ABI change.. Kamion would like to release Array4 today, but can we manage to do kernel -> l-r-m and d-i?
<daniels> mdz: any objections if I upload casper 0.35?
<mdz> fabbione: what ABI change? the patch does not change the ABI
<fabbione> mdz: also please change l-r-m ownership in bugzilla for daniels :-)
<mdz> fabbione: if you want to use strncmp instead of memcmp, that's fine; they're equivalent
<fabbione> mdz: your patch does not. another one does 
<fabbione> it's a security fix :-)
<mdz> fabbione: then let's apply my patch, and not the other one
<daniels> mdz: (with casper changes, we get a working x-on-livecd-under-qemu; not tested natively yet)
<mdz> daniels: quotes?  $() should expand to a single word
<mdz> daniels: what casper changes?
<fabbione> mdz: if you want i can revert it, but ....
<daniels> mdz: mkisofs bitches about not being able to find 5.04
<mdz> fabbione: why revert? you have not uploaded it yet, have you?
<daniels> mdz: but "$()" works fine
<fabbione> mdz: no i didn't.. but it's in my tree..
<mdz> weird
<daniels> mdz: don't call dpkg-reconfigure xserver-xorg with XORG_FORCE_PROBE=yes
<mdz> daniels: shouldn't that be a no-op now?
<daniels> mdz: yes
<mdz> fabbione: you could keep that tree, but create a second one based on -13, upload it, we build array 4, and then continue with your tree?
<fabbione> mdz: ok.. it's just a lot of extra work.. but i will do asap
<mdz> daniels: did you test the BusID thing?
<mdz> fabbione: is it?  I can do it if it is a problem
<fabbione> mdz: i will need to merge your changes anyway
<mdz> it is a one-line change
<fabbione> mdz: it's not your change the problem
<fabbione> it's the other bug fixes that breaks the ABI :-)
<fabbione> don't worry.. i will fix and upload asap
<daniels> mdz: yes
<daniels> mdz: bear in mind this is with ubuntu16, not 14
<mdz> daniels: ubuntu15 is on the current live CD, and that works
<mdz> I assume 15 and 14 are identical, debconf-wise
<mdz> daniels: so it's not necessary to remove the XORG_FORCE_PROBE in sync with ubuntu16, right?
<daniels> mdz: oh, and mkisofs throws volume id string too long too, so you have to use -V hoary-live-custom or whatever
<daniels> mdz: theoretically, no
<mdz> daniels: I want to get array4 out before changing this again
<mdz> but after that, let's do it
<daniels> frig!
<daniels> mdz: er, so as I understand it, no-one without the archive signing key can fully customise live CDs
<daniels> i just foolishly attempted to replace casper
<mdz> hmm, if so, we should fix that
<daniels> Packages.gz -> Release -> Releage.gpg
<mdz> I thought Kamion and I agreed that trying to authenticate the CD we just booted from was a bit excessive
<mdz> are you sure it's because of Release.gpg that it breaks?
<daniels> mdz: no, hence the 'as I understand it'
<mdz> daniels: what did you do exactly?
<mdz> did you regenerate Packages and Release?
<daniels> i didn't regenerate Release, no
<mdz> ah
<mdz> that'd do it, then
<mdz> Release.gpg shouldn't even be touched on the live CD
<daniels> ok
<mdz> emailed you a script
<daniels> thanks
<mdz> which will fix up Packages and Release to match reality
<aj_> mdz: ta for applying the patch
<aj_> authenticating a cd you've already booted from is pointless; the gpg you're using could already be corrupted anyway (or the kernel you tried to use to exec gcc)
<mdz> or a malicious boot loader!
<mdz> I think we do authenticate the CD when doing an install from it, but more incidentally in that it's treated the same as a network archive
<aj_> i imagine a malicious boot loader could only load a malicious kernel anyway
<aj_> (and a normal boot loader can do that!)
<mdz> a malicious boot loader could patch in the evil on the fly
<aj_> yeah, that's authenticating to ensure it's not accidently corrupt, or out of date though
<aj_> aren't boot loader's pretty restricted in size?
<sivang> Morning all
<mdz> aj_: grub stage2 is about 100k and does a lot
<aj_> oh, wow
<aj_> well, fair enough them!
<aj_> then!
<pitti> Hi guys
<mdz> morning
<fabbione> mdz: did you already tested the patch, right?
<fabbione> hey pitti
<mdz> fabbione: Kamion tested it
<fabbione> ok
<fabbione> -14 on the way to jackass
<mdz> thanks
<fabbione> np
<fabbione> *cough*beeer*cough*
<Treenaks> fabbione: dude, it's 9:32
<fabbione> Treenaks: and?
<fabbione> i am already drunk at 6am to manage the kernel dude...
<Treenaks> fabbione: oh yeah wait
<Treenaks> kernel stuff requires that
<fabbione> it's a build-dep :-)
<Treenaks> ;)
<Treenaks> hm.. gpg --update-trustdb is a LOT faster now I did a --rebuild-keydb-caches
<pitti> mdz: pmount 0.7 is up, so gvm can be uploaded. You really think that always mounting 'exec' is the way to go?
<fabbione> Treenaks: want my gpgupdate script?
<fabbione> Treenaks: it takes care of doing that stuff for you
<mdz> pitti: I just don't see what is gained with noexec
<Treenaks> fabbione: hm, cool
<pitti> mdz: prevent accidential execution
<pitti> mdz: nautilus makes it very easy on double-clicks
<Treenaks> fabbione: can you mail it?
<fabbione> Treenaks: www.fabbione.net/gpgupdate
<fabbione> you need to customize it for your setup
<mdz> pitti: hmm
<Treenaks> fabbione: thanks
<mdz> pitti: the same things are possible with samba shares, FTP sites, etc. though
<pitti> yeah, right
<fabbione> Treenaks: the rsync part is commented out, because you do it once
<pitti> mdz: hmm, nautilus still asks whether to execute or open a file
<fabbione> Treenaks: after taht you add the keyrings to your gpg.conf or whatever is called today
<pitti> mdz: okay, I upload it like this now, we can always change it
<fabbione> Treenaks: and gpg --refresh-keys will take care of it
<Treenaks> fabbione: ok, cool
<mdz> pitti: it asks when?
<daniels> mdz: how do I debug casper-udeb failing to install?
<daniels> mdz: all I get in syslog is that casper-udeb failed to configure
<fabbione> mdz: linux-source-2.6.10_2.6.10-14_source.changes ACCEPTED
<fabbione> have fun
<pitti> mdz: it asks when you have an executable file with another mime type (graphic, ASCII text, etc.)
<mdz> daniels: set -x in postinst, I suppose
<pitti> mdz: "Do you want to open this file or execute in a text terminal" or sth. similar
<mdz> pitti: oh, so there is already a safeguard against automatic execution?
<pitti> mdz: the autorun has a confirmation dialog in any case, yes
<pitti> mdz: I meant double-click execution, it should be mildly protected as well
<mdz> fabbione: thanks
<fabbione> no problem dude :-)
<fabbione> i will wait monday to upload -15
<fabbione> so we have time to prepare l-r-m and other stuff
<mdz> I just want to get array 4 out
<fabbione> yup.. i fully understand...
<mdz> it is late already due to this grub bug and the xorg stuff
<fabbione> we had some kind of chicken-egg problem here
<fabbione> probably we need to be more careful next time
<fabbione> because i was waiting to upload the kernel due to Array 4
<fabbione> and Array 4 was waiting for me
<mdz> array 4 was waiting for you?
<fabbione> well due to the amd64/grub bug
<mdz> we did not have a fix to give to you until a few hours ago :-)
<fabbione> since we don't have a real fix...
<mdz> s/fix/workraound/
<fabbione> still... if i knew about the parsing problem before i could have fixed it easily
<fabbione> i ahd to fight with it already for inotify
<mdz> you already knew that noexec=off was buggy?
<fabbione> no
<mdz> oh
<fabbione> but i knew how to fix it
<mdz> once we realized that was the problem, it was trivial to fix
<fabbione> ok :-)
<mdz> I thought we could just use noexec=off as a workaround
<mdz> I did not realiz euntil today that noexec=off wasn't working
<fabbione> but it wasn't working everywhere
<fabbione> yeah
<fabbione> let me send the patch upstream...
<mdz> we still have the underlying problem to fix :-/
<mdz> no one responded on lkml I guess
<fabbione> yup
<fabbione> no.. nobody
<mdz> that is crazy
<mdz> there is no 64-bit boot loader for amd64, is there?
<mdz> so this would affect everyone
<fabbione> on the other hand the trackpoint patch has been submitted upstream and it is receiving comments
<fabbione> also good ones to fix the detection
<fabbione> (including from Suse people that have been tracking our kernel/bugzilla)
<fabbione> so at the end i don't suck as much as i tought kernel-side
<mdz> I last heard from Kamion at 0200 UTC
<mdz> so I guess he will not be awake yet
<fabbione> i doubt
<fabbione> that was approx 7 hours ago...
<fabbione> so at least another 2/3
<mdz> once kernel -15 is up, he knows what needs to be done
<dholbach> morning
<fabbione> mdz: i will still wait monday. it will give me time to do more stuff
<mdz> fabbione: between you and Kamion, you can test all 3 major architectures, right?
<fabbione> mdz: since we must break the ABI, it is worth to backport more fixes
<fabbione> mdz: with Array4? i think so yes...
<fabbione> mdz: given that he can produce the iso's within a decent time...
<mdz> ok, so if everything goes OK, you guys can get array4 out while I am asleep
<fabbione> i promised my (future) wife to take her for dinner out this evening
<fabbione> mdz: ok. i will talk with Kamion and we will see how it goes
<fabbione> mdz: sleep tight :-)
<mdz> night
<daniels> i think partners of distribution team members will breathe a collective sigh of relief when hoary is out
<daniels> mdz: g'night
<sivang> mdz: night
<dholbach> hai sivang
<sivang> dholbach: morning!
<sivang> dholbach: 'sup?
<daniels> when you're a few hundred mb deep into swap on account of building a live cd image again, and your only swap device is a usb hard drive, it *hurts*
<fabbione> ahhah
<d3vic3> doko ping 
<daniels> qemu is sloooow
<d3vic3> if a package is 0.7.3, does it become 0.7.3ubuntu1 or 0.7.3-1ubuntu1 ? 
<daniels> d3vic3: hard to tell, but usually 0.7.3ubuntu1; sometimes 0.7.3-0ubuntu1
<d3vic3> hmm 0ubuntu1 seems close enough 
<sivang> daniels: yeah...:-/ I wish it would be bit faster, would be real nice, as it's quite stable from what I've seen and played with.
<doko> d3vic3: png
<d3vic3> doko scroll up a bit 
<daniels> mdz: ok, xorg on the live cd now works fine for me.
<daniels> mdz: (with ubuntu16)
<doko> d3vic3: I did choose 0.7.3ubuntu1 for packages with a tar.gz, and the schema with the dash for packages with an .orig tarball.
<daniels> aha!
<d3vic3> on 
<d3vic3> ok 
<daniels> mdz: ironically, the problem with writing out the new config you had was due to Branden's Debconf-fu not being anal enough :P
<d3vic3> this one has tar.gz, so I'll do same as you 
<daniels> later all
<d3vic3> dch changes dir name however
<sivang> hey _mvo_ 
<dholbach> guten morgen _mvo_!
<_mvo_> hi sivang, hi dholbach 
<pitti> Hi _mvo_ !
<_mvo_> hi pitti 
<sivang> morning amu 
* fabbione sighs... kdelib in main!
<thom> fabbione: but you're a kde fanboy
<fabbione> thom: no when it goes to kill my poor sparc 
<thom> heh
<sivang> so, does anybody know what is going to be hoary's official pdf reader (gpdf,xpdf...) ?
<amu> fabbione: *eg* 
<amu> hi sivang 
<thom> sivang: xpdf
<thom> sivang: we may change to evince in the next release, i guess
<sivang> thom: thom : errr :)
<thom> err?
<sivang> thom: sorry,
<sivang> thom: that was meant to be sounds of discontent :-))
<thom> whyso?
<sivang> thom: well, user interface wise, evince looks a bit better no?
<sivang> morning seb128 
<thom> sivang: yes, but it's nowhere near ready for hoary
<seb128> hi
<pitti> Hi seb128
<seb128> thom: evince ?
<sivang> seb128: do you read minds? ;-) (or have another nick which saves scrollback for you)
<thom> seb128: yeah
<seb128> sivang: <sivang> thom: well, user interface wise, evince looks a bit better no?
<seb128> thom: doesn't work fine for you ?
<sivang> seb128: oops, I am switching order of lines in my mind...
<infinity> kdelibs in main?...  Bah.  I no longer like Ubuntu.
<sivang> infinity: hehe
<infinity> Lacking KDE was a feature, not a bug. :)
<thom> seb128: works fine, it just is so young it scares me
<Riddell> sivang: kpdf!  (pretty please, it's relly nice)
<sivang> thom: what would be needed to make it hoary worthee? 
<seb128> thom: xpdf is ugly :/
<thom> seb128: yes
<seb128> Riddell: stop trolling
<jdub> seb128: is this the evince or gpdf in hoary discussion?
<thom> seb128: are you really planning to ask for evince in main?
<sivang> jdub: evince or xpdf :)
<Riddell> seb128: hay, they started it :)
<dholbach> evince is cool, but searching is a bit broken
<seb128> jdub: seems so :p
<jdub> seb128: i'm worried it hasn't had much testing
<seb128> jdub: me too
<sivang> dholbach: in what way?
<jdub> so i'd be more comfortable with gpdf
<seb128> jdub: but xpdf is really ugly :/
<seb128> jdub: yeah, if it gets type3 font ...
<dholbach> sivang: filed a bug yesterday... you hit ctrl-f - start typing - and it suddenly can't find anything anymore, it crashes
<sivang> seb128: it's also using a non std menu layout, if that can be called a menubar at all :)
<seb128> jdub: oh, themes/engines update, rock :)
* fabbione just got 600 empty DVD's
<smurfix> fabbione: wow. What are you going to do with those??
<thom> fabbione: send em back! ask for full ones next time!
<fabbione> thom: ahhaha
<jdub> seb128: yeah, decided to just epoch it harder
<fabbione> smurfix: well.. backing up my server and reinstall it from scratch.. 
<fabbione> smurfix: + other stuff...
<fabbione> i need a place where to store my pr0n collection
<d3vic3> fabbione, yuk!
<fabbione> now i need to buy a 600 DVD readers jubox
<pitti> fabbione: I thought the kernel sources were your pr0n? :-)
<smurfix> fabbione: Heh. I send the important stuff offsite, anything else is on a raid-5, and if that dies, well, I got the stuff from the net, I can do it again
<fabbione> pitti: no.. i still don't masturbate with it.. even if it's getting slowly sexier
* sivang wonders why gpdf is not in the desktop seed yet.
<fabbione> smurfix: that's the plan.. but basically they will be a huge help for me to reinstall everything here
<pitti> fabbione: maybe you should strip the kernel... 
<fabbione> shit has been piling up for ages
<fabbione> pitti: i don't compile with -g
<fabbione> it's already naked :)
<pitti> fabbione: ahem, 600 DVDs? and you are sure that you will find _anything_ on them?
<fabbione> pitti: i am pretty good at keeping order around
<fabbione> so yeah
* pitti imagines fabbione in a head-high pile of CDs
<fabbione> actually it's a very small box
<fabbione> approx the size of a midtower case
* Mithrandir imagines fabio sitting and writing "backup, 253/600" on a DVD.
<fabbione> Mithrandir: ahahha
<fabbione> approx 300GB to backup ;)
<fabbione> but most of it will stay on DVD
<fabbione> so it will be more like
<fabbione> misc pron #1/XXX
<pitti> weird guys...
<pitti> oh, another security bug - yeah, give it to me! try me harder!
<Treenaks> pitti: you just buy 2 identical servers? :)
<pitti> Treenaks: hmm?
<sivang> fabbione: trust me you will never touch most of the stuff that "just piled there" , I used to make lots and lots of backups, and they are still sitting in the closet, most of the important stuff is on imaps mail, cvs etc.. :-))
<Treenaks> pitti: oh.. instead of making backups on DVDs, you have 2 identical machines
<fabbione> pitti: what is about? kernel?
<pitti> Treenaks: why should I? one is more than enough
<pitti> fabbione: just kidding
<fabbione> ah ok
<pitti> fabbione: actually I have a bunch :-)
<fabbione> i expected so
<fabbione> and i am NOT surprised
<pitti> Treenaks: I upload my backups to the worldwide mirror net :-)
<Treenaks> pitti: oh yeah of course :)
<sivang> pitti: can anybody upload there?
<fabbione> the best backup around are gpg keyservers
<pitti> Treenaks: any my personal backup fits in 30 MB
<fabbione> i will let you figure out to use them for it
<pitti> fabbione: debian mirrors are not bad as well
<fabbione> you can remove stuff from a debian mirror
<fabbione> you cannot from a gpg keyserver :-)
<Treenaks> fabbione: ah, that's why you sent your private key there ;)
<Treenaks> fabbione: so you won't lose it!
<fabbione> Treenaks: EXACTLY!
<fabbione> Who uses XFS and run 686 ?
<fabbione> (and feels very lucky today...)
<pitti> fabbione: hmm, is XFS and k7 close enough?
<fabbione> pitti: i can make it close.. yes
<pitti> fabbione: alternatively, xfs and ppc?
<fabbione> pitti: if you want...
<pitti> fabbione: my multimedia partition is xfs
<pitti> fabbione: what do you want to destroy on it?
<pitti> fabbione: incidentially, this one is _not_ backuped... :-/
<fabbione> pitti: #6122
<fabbione> pitti: updating to XFS in bk
<fabbione> modulo a few bits that we can't backport
<pitti> "XFS crashed on 2.6.10-2-k7" -> hey, that's my kernel
<fabbione> pitti: just tell which flavour you prefer to trash... ppc or k7?
<fabbione> ok
<pitti> fabbione: well, k7
* pitti backs up his xfs partition
<pitti> fabbione: however, I never experienced an XFS crash
<sivang> fabbione: my home is xfs :)
<pitti> fabbione: hmm, good opportunity to write my first DVD :-)
<sivang> fabbione: is there some kernel sacrafices going to take place today? ;-))
<sivang> fabbione: using a 686-smp , btw.
<fabbione> sivang: do you use XFS?
<fabbione> pitti: good opportunity ;)
<Kamion> morning
<sivang> fabbione: yes
<fabbione> sivang: ok.. than i will build k7 and 686-smp
<fabbione> Kamion: goodmorning :-)
<sivang> fabbione: /dev/hdb7 on /home type xfs (rw)
<sivang> fabbione: is anything going to break? ;-)
<fabbione> Kamion: please read the scrollback from this morning.. it's about Array4.. the kernel is ready
<fabbione> sivang: possibly...
<Kamion> fabbione: yup, read it, thanks dude :)
<fabbione> Kamion: no problem!
<pitti> brb
<sivang> fabbione: this was planned as a regular kernel update ? (or just your pkgs that need testing)
<smurfix> array4? Somebody should update HoaryReleaseSchedule... it talks about array9 due next week. ;-)
<fabbione> sivang: both...
<Kamion> smurfix: oh yeah, been meaning to fix that
<thom> fabbione: if you break XFS i will cry
<fabbione> thom: can you test it too?
<fabbione> thom: according to 6122 is already broken
<thom> i'm on amd64
<fabbione> ok .. can you test it? i don't mind building on amd64
<thom> and it's not eaten my /home yet ;-)
<thom> sure
<fabbione> what flavour do you prefer?
<thom> -k8
<thom> (amd64-k8 that is)
<fabbione> roger
<fabbione> yeah yeah :-)
<fabbione> that crap over there
<thom> warm up concordia!
<fabbione> thom: how much do you want me to fire this time?
<thom> last time was maybe excessive ;-)
<Simira> yay, a jdub :)
<fabbione> eheheh
<Kamion> smurfix: done
<Kamion> jdub: I've updated the release schedule to reflect reality with respect to Array CDs, hope that's ok
<sivang> fabbione: please, I also don't want my /home to disappear :-) How much gpg keys do you want for that? ;-)
<Treenaks> "See here the reason I don't run JFS, XFS or Reiser" ;)
<sivang> Treenaks: I've been using it since hoary with no apprent problem so far :)
<fabbione> thom: last we tried 400... let see how it goes with 399 :-)
<thom> heh
<fabbione> kidding.. down to 200
<thom> fabbione: 200 is too slow ;-)
<fabbione> crap
<fabbione> it doesn't even build on amd64
<fabbione> (inotify)
* fabbione fixes...
<fabbione> this should be easy
<fabbione> is www.kernel.org down?
<Mithrandir> looks like it.  Use ftp.$countrycode.kernel.org?
<thom> fabbione: jabber me when you're ready? 
<fabbione> thom: sure...
<fabbione> thom: i have almost done.. these fixes are easy :-)
<Kamion> fabbione: just waiting for elmo to NEW the ia64 stuff, then I'll kick off a CD build
<elmo> the NEW stuff has been done a while
<Kamion> oh, bonus, ta
<elmo> tho, not in main
<elmo> I guess you probably want that ;)
<Kamion> ideally, yeah ;)
<Kamion> haha, I really must fix d-i not to copy init=/bin/sh to the target bootloader config
<elmo> Kamion: could you seed it?
<Kamion> elmo: sure, sec
<Kamion> um, minute. have to reboot to a system that actually has baz plus a seed checkout
<Kamion> elmo: it shouldn't need seeded, stuff should depend on it - I don't seed ext2-modules on powerpc
<elmo> casper-udeb depends on it for ppc
<Kamion> and ia64; there's a glitch where kernel-image still provides ext2-modules on ia64, though, which might be confusing germinate
<elmo> hmm, germinate doesn't mention casper-udeb for ia64.. 
<Kamion> fabbione: please remove ext2-modules from the kernel-image Provides: line in debian/d-i/ia64/package-list
<Kamion> fabbione: (not urgent for array 4)
<fabbione> Kamion: done
<Kamion> thanks
<fabbione> no problem
<fabbione> thom: check on people.u.c/~fabbione/
<fabbione> argh.. i did too fast.. bah.. damn dpatch
<Kamion> elmo: don't worry about it for now, it's probably useless given the incorrect kernel Provides:; when the Provides: are fixed, germinate should automatically ask for ext2-modules in main
<thom> fabbione: thanks ;-)
<fabbione> thom: thanks for trashing^Wtesting
<elmo> Kamion: ok, I promoted it in the meanwhile - want me to force cron.daily, or is next scheduled one ok?
<Kamion> elmo: next scheduled's fine
<thom> fabbione: i need to clean up my ~ anyway ;-)
<fabbione> ahha
<fabbione> thom: please stress it as much as you can
* thom archive-mirror's before reboot
* fabbione -> food
<thom> fabbione: well, my /home is still there
<fabbione> thom: can you do some high I/O on it?
<fabbione> check fs corruption.. stuff like that
<thom> fabbione: hrm, this new kernel is an oops-oh-rama
<thom> i'll save the oops, then i'm rebooting ASAP
<fabbione> thom: try to reboot with noinotify
<fabbione> or the oops are XFS related?
<dholbach> /haggai
<pitti> elmo: regarding #6124 (psql conffiles): which version did you try this with? This mess was already fixed in 7.4.6-6
<pitti> elmo: (which is not yet in Warty, though)
<thom> fabbione: RIP: 0010:[_end+534707758/2132627456]  <ffffffffa021ae2e>{:xfs:linvfs_ioctl+30}
<fabbione> what is the EIP?
<thom> wait one 
<elmo> pitti: yeah, it was warty - I had a quick look at hoary and it looked the same, if it's already fixed, sorry
<fabbione> thom: ok.. i guess we can't safely backport XFS...
<fabbione> thom: at least not on x86_64
<pitti> elmo: I don't think that I can put this change into hoary - it's not security and no major breakage, I think
<pitti> elmo: s/hoary/warty/
<fabbione> that's the one that suffer from the biggest ioctl changes
<elmo> pitti: no, if it's definitely fixed in hoary just close the bug
<pitti> okay
<elmo> pitti: umm, how has it been fixed?
<elmo> the function is still there and it still unconditionally chmods and chowns
<elmo> in 7.4.7-1
<thom> fabbione: www.clearairturbulence.org/syslog-xfs-broken
<pitti> elmo: it is not called on every upgrade
<elmo> pitti: when is it called?
<pitti> elmo: just right after initdb (installation from scratch) and in db_upgrade
<elmo> I don't think you can do it on db_upgrade either?
<pitti> elmo: but db_upgrade will not be necessary any more
<elmo> for hoary?
<pitti> elmo: see my bug followup, I send it soon
<elmo> ok
<pitti> sent
<fabbione> thom: thanks.. nothing i can fix without going 11rc3
<thom> oh well, it didn't actually trash the FS at all so i can't complain
<fabbione> thom: yeah i can see there are no thunderclouds in my house...
<fabbione> :-)
<Hwolf> When is the next array due?
<Kamion> Hwolf: today hopefully
<Kamion> Hwolf: I'm just building the candidate now
<thom> fabbione: thunderclouds? there would be a fucking v2 on its way ;-)
<Hwolf> kamion: Thanks. Was just planning to install array3. I'll save myself the agony then.
<fabbione> thom: ehehhe
<Kamion> Hwolf: what arch?
<Hwolf> x86
<Kamion> array 3 shouldn't be too agonising
<Hwolf> I couldn't for the love of god get an .avi, .mpeg or anything to play, last time i checked.
<Kamion> oh, no idea what that's about
<Hwolf> Kamion: My messed up pc, probably
<fabbione> Kamion, mdz: Andi Kleen thanks for the noexec option and he offered as direct contact point for future x86_64 patches
<Hwolf> fabbione: how is the ubuntu (kernel) support for bluetooth HID?
<Kamion> fabbione: cool
<Kamion> fabbione: can we ask him if he knows anything about the grub noexec bug?
<pitti> carlos: how far are you with the imports?
<pitti> carlos: gtk+2.0 has two important domains, which my script cannot yet handle
<carlos> pitti: yesterday I did a whole import
<pitti> carlos: shall I improve my script or wait for you?
<pitti> carlos: neat
<fabbione> Kamion: i think so.. sure.. do you have a link to your message to lkml handy?
<pitti> carlos: GIMME THE PO CRACK! :-)
<carlos> pitti: If all goes well, on Monday or Tuesday will be in production
<pitti> carlos: okay, I can wait until next week
<pitti> carlos: actually I wanted to produce a new set of update packages
<carlos> pitti: I'm going to have lunch now, could we talk later about the gtk+ problem? I'm interesting to know what's the problem exactly
<pitti> sure
<carlos> later!
<Kamion> fabbione: http://www.ussg.iu.edu/hypermail/linux/kernel/0501.3/1083.html
<fabbione> Kamion: ROCK 'N ROLL!!!!
<Mitario> hi everyone
<_mvo_> hi Mitario 
<thom> Kamion: how do i get all but the first line of output in shell?
<Kamion> thom: tail -n +2
<fabbione> thom: i think you need to do it via wc -l -1 
<Kamion> you so don't :-)
<fabbione> interesting :-)
<thom> Kamion: rocking, thanks
<thom> why oh why doesn't man tail mention this
<Kamion> it does
<Kamion>        If the first character of N (the number of bytes or lines) is a
<Kamion>        `+', print beginning with the Nth item from the start  of  each
<Kamion>        file,  otherwise,  print  the  last N items in the file.
<thom> argh
<thom> right, i was stupidly looking for an argument to -n
<thom> rather than a general comment
<thom> in the same style as head, actually ;-)
<Kamion> heh
<Kamion> yeah, could probably do with rewording
* thom adds to TODO list
<Mithrandir> is X.org in arch somewhere?
<fabbione> Mithrandir: it was.. but it's not updated anymore
<fabbione> at least.. the debian/ dir was
<Mithrandir> it's for sesse.  He's looking at making a X-to-RDP thingy.  (And yes, I know he's crazy.)
<fabbione> RIGHT!
<zul> hey
<fabbione> hey zul
<zul> hey fabbione how is it going
<fabbione> not extremely bad...
<zul> good...
<Hwolf> fabbione, why so gloomy?
<fabbione> Hwolf: because sometimes is just a royal pain to work on the kernel
<zul> hes always gloomy hes a kernel hacker
<Hwolf> fabbione: how far is the distro's kernel from the default?
<fabbione> Hwolf: what is default?
<Hwolf> vanilla, sorry
<Kamion> Hwolf: the source package has a debian/patches/ directory, you can look in that
<fabbione> also because there is no vanilla
<Hwolf> kernel,org then.
<fabbione> vanilla from a stable release? bk? rcZbk394738743+ac33-mm2?
<zul> heheh
<fabbione> There is no vanilla! There is only Zuul!
<tseng> hmm looks like industrial cursors got dropped for this round of gtk2-engines updates
<fabbione> BUGBUSTERS!
<Treenaks> fabbione: yeah, look at the xmlns for xul
<tseng> any ideas as to where it should go?
<zul> i like ice cream
<fabbione> never cross the flux of more upstream...
<Hwolf> Call me stupid, but I've rarely noticed the difference on debian between a debian kernel or a kernel.org one.
<Hwolf> Using it that is
<tseng> Hwolf: most things in debian are bugfixes.
<tseng> not magical fairy dust like some other kernel sources
<Hwolf> tseng: at this moment, I'm living under the impression debian prefers to patch a new version together rathen than get it upstream. :-)
<Hwolf> rather, even.
<tseng> upstream releases arent in the best shape these days.
<Hwolf> (popped the keys of my keyboard for cleaning, must've wrecked it)
<zul> fabbione: kernel team meeting is still next week?
<fabbione> zul: yes
<jbailey> I have a patch for a bug on evolution-exchange in warty.  Do I need to do anything more than upload a new version with the distro set correctly?
<Mithrandir> jbailey: uhm, warty?
<Mithrandir> jbailey: sure you don't mean hoary?
<tseng> hm, youll have to get that approved
<tseng> there isnt a real policy of fixing bugs in warty.
<jbailey> Mithrandir: Yes, certain.  Hoary I've figured out how to deal with already.
<Mithrandir> jbailey: as tseng says -- get approval.  jdub/mdz; drop them a mail.
<jbailey> evo-exchange is in main, and it's a stupid bug that keeps a good number of exchange configurations from working.  I patched it in Debian ages ago but I guess it didn't make the sync.
<jbailey> Mithrandir: Cool, thanks,
<elmo> jbailey: (btw, when/if you get approval, correct distro is 'warty-updates', 'warty' won't work)
<jbailey> elmo: Thanks!
<sivang> Hey jbailey 
<jbailey> G'day sivang 
<fabbione> jbailey: /wind goto 5
<fabbione> ops
<jbailey> fabbione: I suspect you don't actually want me to hop to my Hurd development window ;)
<fabbione> jbailey: that's for sure :-)
<tseng> oh hell yeah, mono 1.0.5
<Treenaks> time for beagle! :)
<elmo> Kamion: cute; you triggered a lintian error I've never seen before
<elmo> E: kickseed source: no-standards-version-field
<elmo> Kamion: can't you trigger them?  if not, I can for you if you want
<Kamion> elmo: happens with a lot of udebs, since they don't follow policy :)
<elmo> hmm
<Kamion> elmo: I'm supposed to be able to, but when I tried, mcmurdo wanted a password
<Kamion> elmo: in this case it was just an oversight though, I'll add the s-v field
<Kamion> done in arch
<elmo> the key in authorized_keys is fux0red
<Kamion> elmo: machines are: mcmurdo hooker ross yellow (d-i) terranova weddell adare king (live fs, which didn't work either)
<elmo> ok, triggered d-i on all of them; does live fs need to be after or can it run concurrent?
<Kamion> I don't need the live fs now, just observing that the key is fux0red there too
<Kamion> thanks
<Kamion> actually ... yes, I suppose I do need the live fs, but it can run concurrently
<Kamion> best not play too many games with version skew
* Kamion -> lunch
<fabbione> WOWWOWOWO
<fabbione>  initrd-kickseed - Load Kickstart file from the initrd
* fabbione claps his hands
<dholbach> bbl
<carlos> pitti: ping
<pitti> carlos: pong
<carlos> pitti: so, what's the problem with gtk+?
<carlos> pitti: the multiple domains?
<pitti> carlos: it has two domains which are both important
<pitti> carlos: and my script cannot handle that
<carlos> pitti: mine neither
<pitti> carlos: well, but mine is only a temporary hack :-)
<carlos> pitti: the only solution I found was to ask for a manual fix
<pitti> carlos: however, I can improve it if necessary
<fabbione> haggai: sparc is building OO2
<pitti> carlos: why, the override can be extended to a mapping of domain => path
<carlos> pitti: I record the domain for a defined path, and next import will know how to handle it
<jdub> Kamion: YAY KICKSEED (haha initrd)
<pitti> carlos: I do it similarly
<pitti> carlos: but I only support one path/domain per pacakge override right now
<tseng> morn jdub 
<Kamion> jdub: err ... ok
<carlos> pitti: don't worry about it (for me, if you want for your temporal solution, it's ok)
<pitti> carlos: that depends on how fast I can get the updates from Rosetta
<carlos> pitti: of course, if you could send me your current mapping table that will save me sometime :-D
<pitti> carlos: I already did
<carlos> pitti: no new additions?
<pitti> carlos: no
<carlos> ok
<sivang> is there a way to uncompress a .deb to it's source form? (if you don't have the source package)
<fabbione> sivang: uh?
<sivang> fabbione: like "reverse engineer" a binary package, if I don't have the source pkg and want to modify it.
<fabbione> sivang: it's easier to find the source :-)
<Kamion> sivang: no.
<Kamion> the source->binary transformation is lossy
<sivang> Kamion, fabbione : ok, will do, thanks
<sivang> jdub: has the skin competition closed for submission? when are you expecting to announce the winner?
<jdub> sivang: it's closed, no details yet
<sivang> jdub: cool, thanks, someone on the locoteam asked..
<mxpxpod> tseng: any luck?
<tseng> mxpxpod: no, it busted it pretty good
<mxpxpod> haha
<mxpxpod> well, that sucks
<tseng> the trayicon dies on your GdkPixbuf bit
<mxpxpod> what????
<mxpxpod> that's stupid
<tseng> well, it doesnt seem to install the gfx
<tseng> which is part of the problem
<mxpxpod> hrmm
<tseng> adding the applet fubared my panel
<fabbione> pitti: 6164!
<pitti> darn
<mxpxpod> I'd just like to say that you guys are all doing some really great work on the linux desktop.. thanks
<fabbione> mxpxpod: thanks :-) really appreciated
<zul> grrr...hate vnc
<fabbione> mxpxpod: if you find a bug, please complain with seb128 and GTK :P
<pitti> lamont: any idea about #6164?
<fabbione> pitti: the reporter is not the only one btw
<tseng> lamont: mono 1.0.5 is now rocking my box
* seb128 slaps fabbione 
<mxpxpod> fabbione: no bugs here... yet
<fabbione> hey seb128 :-)
<seb128> heyhey fabbione :)
<fabbione> i think i am off for a long break
<fabbione> Kamion: what is the status with Array 4? do i need to be around later or can you manage?
<fabbione> (for the tests)
<mxpxpod> is s-j 0.6.0 going into hoary?
<jdub> if it goes into gnome 2.10
<mxpxpod> jdub: cool
<jbailey> Anyone know what "    exec 3>&- 4>&- 5>&- 6>&-" means?  Herbert Xu seems to think that the ideal of shell is to make it look as much like Perl as possible. =)
<fabbione> jbailey: where is that?
<zul> jbailey: kernel rules?
<pitti> jbailey: this redirects file descriptors 3 to 6 to stdout
<mxpxpod> ok, I have some questions on powerpc... why does ubuntu-desktop install apmd and powernowd on powerpc laptops?
<jbailey> fabbione: initrd-tools.  I'm trying to figure out why my DSDT stuff is showing up first.   I'm trying to figure out if this would affect buffering.
<fabbione> jbailey: ah ok...
<mxpxpod> shouldn't pbbuttonsd take care of the apmd stuff?
<jdub> yes, file a bug on that one
<jbailey> pitti: Thanks.  Is it functionally any different than 3>&1 ?
<jdub> powernowd is for cpufreq stuff in general
<jdub> though i don't know if any macs support that (or if linux supports it on them)
<mxpxpod> jdub: so shouldn't cpufreqd be able to replace powernowd?
<tseng> <sivang> how much are you using mono? are you writing in C# ? (I', curious to 
<tseng>           know what mono can give me)
<jdub> no, we chose powernowd instead of cpufreqd
<mxpxpod> jdub: ah, ok
<mxpxpod> jdub: does powernowd work just as well?
<tseng> mxpxpod: i prefer cpufreqd, but pnd works pretty alright
<jdub> i believe we chose it because it is broken and uses more power than cpufreqd
<jdub> ;)
<mxpxpod> heh
<mxpxpod> jdub: so you prefer cpufreqd?
<jdub> no
* mxpxpod missed the sarcasm, he thinks
<jdub> i have a certain amount of faith that we chose the right tool for the job
<jdub> and if we didn't
<jdub> i can blame thom
<mxpxpod> haha
<zul> lolo
<zul> lol even
<jdub> dpkg: error processing /var/cache/apt/archives/mono-assemblies-base_1.0.5-2_all.deb (--unpack):
<jdub>  trying to overwrite `/usr/lib/mono', which is also in package libdbus-cil
<tseng> jdub: 
<jdub> daniels: ping
<tseng> sudo dpkg -i --force-overwrite /var/cache/apt/archives/mono-assemblies-base_1.0.5-2_all.deb
<jdub> tseng: use of --force-overwrite indicates LACK OF BUG FIXAGE
<tseng> i hit the bug in my custom mono package as well
<tseng> im sure it will be fixed when the real deal hits sid
<tseng> as for dbus-cil ... :)
<jdub> no, it's a libdbus-cil bug we've seen before
<tseng> jdub: hey, i met up with meebey and dajobe yesterday
<tseng> cool dudes
<tseng> meebey gave me a rebuttal to miguel
<sivang> tseng: who are those guys?
<tseng> basically he likes GAC and all that, but the policy is to allow people to use pnet and that stuff
<sivang> (miguel sounds suspiciously related to gnome :)
<tseng> sivang: miguel = vp of novell, meebey = debian-mono
<sivang> tseng: nice
<mxpxpod> jdub: who should I assign the pbbuttonsd bug to?
<thom> me, probably
<mxpxpod> thom: ok
<jdub> mxpxpod: pbbuttonsd bug?
<thom> and no, pbbuttonsd shouldn't be taking care of apm
<mxpxpod> seriously?
<thom> at least, not on x86
<thom> no
<thom> no way
<mxpxpod> but on powerpc, yes
<thom> meh
<thom> dunno, i don't know of any powerpc kit that uses apm
<thom> file a bug, i'll look
<mxpxpod> ok, thanks
<jdub> mxpxpod: the bug is that apmd is shipped on ppc
<mxpxpod> jdub: ok
<jdub> mxpxpod: ought to be filed against ubuntu-meta or ubuntu-desktop
<mxpxpod> ok
<lamont> pitti: looking
<tseng> lamont: hey, can we sync libgdiplus 1.0.5
<lamont> tseng: that'd be part of mono?
<tseng> lamont: goes with mono. i cant really test the apache stuff
<lamont> pitti: GAH!
<lamont> pitti: dup of 5025
<mxpxpod> thom: what's your bugzilla name?  I'll CC you
<tseng> lamont: also monodoc 1.0.5 has a seperate source
<thom> thom@ubuntu.com
<lamont> pitti: would you like an upload of ubuntu17.2?
<tseng> lamont: we already have latest gtk# and monodevelop, mod_mono and xsp i have never touched / know nothing about. i can ask meebey
<Kamion> fabbione: I'm fine
<Kamion> jdub: ... or against apmd?
<mxpxpod> thom: 6166
<lamont> tseng: monodoc is still 1.0.4-1 in debian.
<tseng> odd
<Kamion> thom: possibly non-Mac != Mac in this case
<fabbione> Kamion: ok.. i am off than
<lamont> tseng: as is libgdiplus
<fabbione> i might pass later
<tseng> lamont: yeah, looking at pkg-mono, updated page now
<tseng> hm
* Kamion builds new CD images while the last lot rsync. hmm
<tseng> mod_mono and xsp are at 1.0
<lamont> Kamion: did you get your d-i build, or do you still need one?
<thom> Kamion: yeah
<thom> what does pegasos do?
<Kamion> lamont: gotcha
<Kamion> thom: god knows, dunno if it even cares about power management
<lamont> Kamion: ??  want me to do a d-i build?
<Kamion> lamont: I've got the build now thanks. sorry, got mutilated into meaninglessness somewhere between brain and fingers
<lamont> Kamion: np.  I know that problem far too well.. :-)
<elmo> lamont: you could fix the key tho :)
<elmo> it looks like cut'n'waste damage
<lamont> elmo: ah, k
<lamont> Kamion: wanna email me a copy of what it should be for you?
<Kamion> lamont: done
<mxpxpod> is there a way to use bogofilter with evo?
<tseng> mxpxpod: not in the way you are thinking
<mxpxpod> tseng: ok
<tseng> it might not be a difficult patch
<tseng> s/sa-learn/bogoutil
<mxpxpod> what about a wrapper?
<tseng> or a config option.. spam command/ham command
<mxpxpod> hmm
<pitti> lamont: what was the cause? this bug did not look like it was introduced in 17.1
<pitti> lamont: if you have a fix, go ahead
* smurfix notices that directing the user to press nonprinting characters (without translating to something sane) is unlikely to work well
<jdub> tseng: it's not a terribly difficult patch (i did it at oxford), but evo makes some assumptions that don't really work well with it
<tseng> hm.
<jdub> you can mark as spam, but not as ham
<jdub> (not easily)
<jdub> and bogofilter doesn't like that
<mxpxpod> jdub: doesn't sa-learn have a --ham option?
<tseng> bogofilter didnt like me much w/o complicating things
<tseng> mxpxpod: yes.
<jdub> mxpxpod: *evo* makes some assumptions that don't work well with bogofilter
<mxpxpod> ooooh, gotcha
* mxpxpod reads good
<tseng> i only every got up to about 85% success with bogofilter after a month or so of use
<tseng> im back to s-a on the server side
<lamont> pitti: no - it was introduced in warty
<lamont> and fixed in hoary
<lamont> will upload
<lamont> Kamion: key fixed - sorry for not twigging to it quicker
<Kamion> lamont: np, thanks
<Kamion> was it just line-wrapped or something?
<jdub>      - beginnings of continuous viewing.
<jdub> seb128: !!! :-)
<sivang> Kamion: do you know if d-i is already in rosetta? (sorry to bug you on this)
<sivang> (but it's been long since it was promised for it to reside there so people could start translate)
<Kamion> sivang: -> daf
<sivang> daf: is d-i in rosetta already? we are anxiously waiting to start make a *good* translation this time :)
<Kamion> sivang: (though you'll probably find that once I apply your general rules for Debian->Ubuntu the translation level will go up markedly)
<Kamion> sivang: er that's a kind of worrying statement; are you implying that you intend to go through and retranslate stuff that's already translated? 'cos that's generally bad
<sivang> Kamion: no, but there are various parts that could use some lovin' , I am never in favor of duplicating work
<Kamion> are they strings that have been branded in Ubuntu?
<seb128> jdub: rock, isn't it :)
<sivang> Kamion: not AFAIK, more of bad wording and strange phrasing of stuff..
<Kamion> sivang: perhaps you could coordinate with the people translating d-i in Debian to get things fixed
<Kamion> I am going to be a very very poor go-between to get your translations merged upstream
<lamont> pitti: uploaded, bug closed
<sivang> Kamion: well, I would , but we do have rosetta no? and want people to use it? ;-) I'd prefer at the moment to use rosetta for this, which seems to me less time consuming at the moment. 
<Kamion> sivang: yeah, I'm not suggesting you shouldn't be using Rosetta, merely saying that this is something you can usefully do in the meantime rather than have everyone sitting on their hands
<Kamion> the distro team didn't wait for Soyuz, we got on and did things the old-fashioned way until it's ready :)
<sivang> Kamion: well sure, trouble is I already got someone with me that is eager to start working on d-i translations, and doesn't know a single thing about PO files...the bigger problem is that he is likely going to have more time to do them then me at the moment...
<Kamion> ok, fair enough
<daf> Kamion: are d-i source packages a normal part of the archive, or are they special?
<Kamion> daf: they're a normal part of the archive
<sivang> daf: Evening :)
<Kamion> for the most part they're maintained collectively upstream though
<daf> in that case, d-i should get pulled in when we do the mass import into Rosetta
<Kamion> so installer-po/ tries to reflect the upstream maintenance
<daf> given that, I'm not sure if we should special case it now
<sivang> daf: when is the mega import planned?
<Kamion> ok, that sort of thing's your call :)
<lamont> mdz: looking at 4642, and trying to fathom how mount is supposed to know that it's a windows partition that is being mounted...
<zul> lamont: doesnt mount look at /proc/mounts?
<lamont> zul: that's the stuff that's already mounted, no?
<daf> sivang: it's planned for next week
<zul> lamont: true
<daf> Kamion: coordination of changes in Rosetta with upstream is not a d-i-specific problem
<sivang> daf: could you point a specific day? or at least, estimtion, end of the week, beggining of ?
<Kamion> daf: that's true; I think d-i's aggregate master .po files are unusual though
<Kamion> aren't they?
<daf> yes
<daf> sivang: beginning of the week rather than the end -- Carlos has a better grip on the timing than I do
<sivang> daf: ok, thanks, I'll speak to him also :)
<lamont> zul: I may just have to go back and read the mailing list traffic to get more context..
<Kamion> I'm just worried about it because I have to deal with .po file merging A LOT when we're busy merging new stuff from Debian, and the edge cases that can't be auto-merged take up a lot of my time
<zul> lamont: yeah but couldnt you put in nls=utf8 in the /etc/fstab and be done with it. i dont have a windows partition here to test it out though
<zul> lunch...bbl
<lamont> zul: sure - that's the manual solution. The bug asks mount to default to that
<carlos> sivang: it depends on the speed we are able to move the needed code from my local computer to the production server (that implies tests cases to be sure all works)
<sivang> carlos: ah ok, cooool then. I'll shut untill end of next week :)
<daf> Kamion: you're right -- you shouldn't need to worry about this stuff
<daf> Kamion: for now, the ideal situations is that people who fix translations in Rosetta then contact upstream and try and get their changes merged there
<Kamion> fair enough
<jdub> sivang: is there a romanised way of expressing hebrew? (like pinyin for chinese or romanji for japanese)?
<sivang> jdub: do you mean to write hebrew prononciation in roman letters?
<jdub> yeah
<sivang> jdub: so maybe I could teach how to say some stuff ? ;-))
<jdub> heh
<sivang> jdub: yes ofcourse :)
<jdub> mostly interested if there's a standard way of writing things in roman characters
<sivang> jdub: not too much, just make sure you double the "e" when wanting to express the "eeeee" sound - for instance
<sivang> ok, I need to think up one :) but also,
<sivang> hrm, I need to teach you the sounds in it so you'll understand what I mean...hmm
<sivang> I need you to hear my voice, otherwise everything I would say make no sense :-/
<Kamion> sivang: just did a batch of Hebrew branding fixes; I think you only have about 30 fuzzy strings now, although I haven't counted untranslated strings
<sivang> Kamion: are these going to be in rosetta eventually? (so I could review them etc)
<Kamion> sivang: I should imagine they'll go in in the same way as everything else in the distribution
<Kamion> there was certainly nothing unusual about my uploads
<sivang> Kamion: cool, tnx :)
<sivang> jdub: I could teach you how to say some stuff, but for some specific sounds, you must listen to it, for example, when right something  "HAATOOL" (which means a cat (the animal) in hebrew) you would go and use the "H" sound for the first letter, which expresses only part of the sound in the correct pronounciation.
<sivang> s/right/you write something/
<mdz> morning
<sivang> morning mdz
<Kamion> mdz: note live CD build running at the moment
<Kamion> (hopefully array 4)
<mdz> great
<mdz> do you have an install set you're happy with?
<Kamion> mdz: dunno yet, still rsyncing/burning/testing
<daniels> jdub: pong
<mdz> ok, I'll pull them down as well
<jdub> sivang: i'm not interested so much in pronounciation, but whether there is a standard form of romanisation
<jdub> daniels: n/m
<daniels> jdub: phat
* daniels sleeps.
<jdub> daniels: you remember the libdbus-cil issue with /usr/lib/mono
<jdub> ?
<daniels> jdub: yeah
<jdub> daniels: that just bit me with the mono upgrade
<sivang> jdub: not too much, there is a "common convention" of how to write in roman letters the special sounds, like the "H" sound I Just mumbled about.
<daniels> jdub: libdbus-cil should have that fixed as of 0.23-1
<jdub> $ dpkg -S /usr/lib/mono
<jdub> mono-assemblies-base, libdbus-cil: /usr/lib/mono
<daniels> jdub: unfortunately there's no way to fix the upgrade without having newer mono conflict with older versions of libdbus-cil
<sivang> jdub: what do you need it for?
<sivang> jdub: (the romanizatio stuff)
<jdub> daniels: i had 0.23-2 on here before the upgrade
<jdub> sivang: interest's sake
<sivang> jdub: ah cool
<Kamion> mdz: oh, fyi, I'm uploading bazaar 1.1.1 to hoary as soon as I finish fiddling with tarballs and stuff
<mdz> Kamion: sounds good
<pitti> Hi mdz
<mdz> pitti: hi
<mdz> someone on the bazaar team needs to become an Ubuntu maintainer
<pitti> bye guys, I'm dragged away by my gf
<pitti> have a nice weekend
<jdub> mdz: bob2 wants to be a maintainer
<mdz> Kamion: sync-mirrors has been taking ages recently
<daniels> jdub: wackwackwack
<elmo> mdz: graphviz 2 is in debian/main; can I sync it into ours?
<mdz> elmo: definitely
<daniels> jdub: does the new mono provide it as a directory or a symlink?
<jdub> symlink
<tseng> lrwxrwxrwx  1 root root 20 2005-02-04 10:27 /usr/lib/mono -> ../share/dotnet/mono
<mdz> elmo: sync-mirrors on little has been running 40 minutes; has it hosed itself like yesterday?
<wasabi> So... What sort of policy is there about packages depending on themselves?
<wasabi> I have a situation where that is the only way to bootstrap it. =/
<wasabi> Without massive hacking at least.
<elmo> mdz: hanging on mirnyy?
<mxpxpod> did you guys change the default cursor theme in gnome?
<mdz> elmo: yep
<daniels> jdub: OH M YGOD
<daniels> jdub: symlink to directory and back to symlink again
<daniels> dear mono,
<daniels> make up your mind.  shit.
<daniels> cheers,
<daniels> daniel
<sivang> daniels: lol
<daniels> really bedtime now
<mdz> wasabi: for self-hosting compilers and the like, we live with it because there is no other way
<elmo> as long as it is a reason like a self-hosting compiler
<jdub> daniels: seems to be "dear debian mono maintainers who do ungodly things"
<mdz> Kamion: so the current daily-live has the amd64 noexec workaround?
<Kamion> mdz: the one currently building will have it
<mdz> Kamion: yeah, it's actually finished
<Kamion> oh, hence you talking about sync-mirrors, ok
<mdz> Kamion: the mirror trigger has been having some problems due to mirnyy being bogged down
<Kamion> I'll ^c it and try again
<mdz> Kamion: elmo fixed it up
<Kamion> oh, already mirrored?
<elmo> no
<elmo> done amd64 + i386 tho
<winkle> to what extent is the install sharing drivers with d-i? my cd isn't detected in latest snapshot but works fine in latest d-i rc.
<Kamion> winkle: the install *is* d-i; detection works somewhat differently though
<Kamion> likely to be some kind of weird hotplug issue, please send /var/log/* to a bug
<winkle> Kamion: ok, that's what I thought, thanks.
<fabbione> re
<fabbione> how is going guys?
<zul> fabbione: good except for setting up a winblows 2000 server
<fabbione> ehhe
<mdz> Kamion: I'm burning live CDs and downloading install
<Kamion> I so wish I had something that resembled bandwidth
<thom> it's overrated, your housemates will just use it all up
<elmo> any reason why we ship every moz-thunderbird extension we support except -enigmail?
<Kamion> thom: I'm the biggest bandwidth hog in this house by some distance
<bradb> Can a binary package possibly come from more than one source package? (Please say no, or that it /can/ but that would not be considered a sane thing.)
* _mvo_ is off to play some hockey. bbl
<elmo> bradb: yes
<elmo> sorry
<elmo> it's not common, and we could possibly avoid it for ubuntu, but there are several examples in Debian
<Kamion> also over time obviously the answer is yes, since sometimes binaries move between sources
<bradb> yeah, that makes sense. ooph, this throws a bit of a wrench in the works for figuring out the maintainer of a binary package though.
<Kamion> well you can certainly discard the "over time" bit, since you just take the most current in whatever distrorelease you're looking at
<Kamion> and there's only ever one binary of any given name in a Packages file at any one time
<Kamion> so you just find the source corresponding to that binary
<elmo> Kamion: yeah but if foo is from bar on i386 and baz on powerpc and bar and baz have different maintainers, who's the maintainer?
<elmo> oh, and foo is same version on both arches :)
<Kamion> oh, er, yeah
<Kamion> I'd be inclined to say "all of them", from the point of view of bug tracking
<Kamion> unless you know the architecture
<Kamion> being limited to a single maintainer is bad anyway :)
<bradb> a maintainer can be a group. in this case both groups would be subscribed.
<Kamion> (and I know Debian's generally single-maintainer for everything, but debbugs does actually handle multiple maintainers on a package
<Kamion> )
<Kamion> multiple maintainer addresses is semantically different from a group, but sure
<Kamion> as in the two maintainers may not be working together in any particularly meaningful way
<elmo> kamion: or 900 maintainers may not be working together in any particularly meaningful way
<elmo> oh, no, wait, that's Debian ;)
<Kamion> but I realise you probably only have one slot in the database or something
<Kamion> elmo: ;-)
<bradb> Kamion: right now there's no "slot" for binary package maintainer, because the semantics are a bit fuzzy.
<Kamion> actually surely this grand database of doom must be able to cope with a list? :)
<bradb> i guess all maintainers of all the sourcepackages from which that might be built in the most current release of a distro is the best answer.
<Kamion> bradb: mapping it via the source package seems sane anyway
<Kamion> it's precisely as hard as having a direct maintainer mapping
<bradb> so, in the worst case scenario, there are N sourcepackages for a given binary package in a distro release, where N == the number of arch's on which that distro release is supported?
<bradb> s/package/package name/
<lamont> source->binary is a 1->N mapping
<lamont> so there are N binary packages for a given source package in a distro release
<lamont> same source builds on all architectures.
<bradb> lamont: what elmo said earlier seems to disagree with that:
<bradb> [13:33]  <elmo> Kamion: yeah but if foo is from bar on i386 and baz on powerpc and bar and baz have different maintainers, who's the maintainer?
<lamont> except on insane distros where that's not true
<lamont> bradb: ew.
<bradb> i.e. N<->N!
<lamont> yeah
<Kamion> bradb: yeah - if I were implementing it, I'd take the binary package name, look up all the entries corresponding to the actual .debs on all architectures, and get the maintainer for each of those via the corresponding source package.
<lamont> binaries aren't maintained, source is...
<lamont> so yeah, the (binary,arch) tuple gets you back to 1 and only 1 source package
<bradb> lamont: yeah. i have to figure out maintainers from binaries in malone though.
<Kamion> certainly in the Debian control file format the Maintainer: field only exists in the source stanza
<lamont> but if they don't give you an architecture, then you have to grab all the possible source packages, I expect
<lamont> of course, that's (binary,version,arch), since it can change from version to version... :-)
<bradb> yeah, we're working towards a UI where the user can specify as much as they know about a bug (re: versions of various things), but I guess the less they know, the more fuzzy our job will be (i.e. maintainer subscriptions and such.)
<dholbach> re
<Kamion> (binary,version,architecture) uniquely identifies (source,version) uniquely identifies maintainer
<Kamion> if that helps
<bradb> yes, that makes perfect sense. thanks for the insight guys.
<Kamion> if you're missing version, you have to look up the most current in the distrorelease; if you're missing architecture, you either have to guess (grotty) or try all and take the union
<Kamion> if you've got a version but it doesn't exist, well, world of hurt etc. ;)
<Kamion> (bearing in mind that when you're syncing bugs from Debian, bugs may be filed on versions you don't know about yet because they're still in queues you can't see)
<Kamion> this is the point when people tend to take up a different hobby rather than think about it
<bradb> eesh, yar
<Kamion> so the versions *will* be valid in the future, they just aren't yet ... I think that's why versions tend to be stored as unparsed strings
<bradb> i hope our debbugs syncing script is creating those releases before creating the infestations. sabdfl wrote it, so he'd know for sure what it's doing.
<Kamion> well it's just not possible, not all versions you see in debbugs will be valid; in fact some will never become valid because the reporter was just wrong
<Kamion> IIRC the plan was to throw that version information away and pretend you never saw it, but I don't know what was to be done about the will-be-valid-in-the-future case
<bluefoxicy> anyone know which package I should install to build a .deb for a kernel source tree?  (and the appropriate documentation)
<Kamion> bluefoxicy: apt-get source linux-source-2.6.10
<Kamion> and satisfy its build-deps ...
<bradb> Kamion: i have no idea if our debbugs imports take that into consideration, but i guess we'll find out. /me makes some changes to his proposal about bug triaging and package reassignment to launchpad@.
<sri> hi all
<sri> I'm in a bit of a quandary after today's update from hoary
<sri> my xorg server has a box with lines in it for a pointer
<sri> (I'm using a matrox G400 as a card)
<sri> and my GNOME session looks like the default theme is not loaded.
<mdz> Kamion: live CD test was successful x3
<sri> btw I was told to come here because it doesn't seem like a common problem
<Kamion> mdz: install powerpc successful, live powerpc test pending
<sri> I can run back to #ubuntu if this is not appropriate :)
<mdz> Kamion: I'm going to do powerpc and amd64 installs next
<Kamion> thanks, I'll be doing amd64/i386 installs in a moment
<sri> rubenv: i figured out that the icon problem I was having is because industrial disapeared on me.
<sri> rubenv: and I'm wondering if my pointer is theme related as well.
<Kamion> bleh, stupid burner
<rubenv> sri: my mouse pointer has just resetted itself after upgrading :/
<sri> rubenv: ok..yeah, so I think thast why I'm getting that strange mouse pointer
<sri> rubenv: because my icon theme got resetted as well.
<sri> rubenv: in fact even though the industrial theme engine is installed it's not showing up in the themes manager.
<Treenaks> does anyone else's firefox look ugly?
<tseng> there was an update to gnome-themes, the engines were split out
<Treenaks> ah ok
<tseng> the industrial cursors dont seem to be installed anymore
<tseng> this is all #ubuntu stuff i believe.
<Treenaks> tseng: not only that..
<tseng> ya?
<sri> tseng: yep..thats why my mouse looks like ass :)
<tseng> yes
<Treenaks> tseng: it lost looks ugly :)
<sri> any quick fixes?
<tseng> um, install it from ximian-artwork srpm if it bugs you that much
<tseng> in novell i believe it is packed inside of the gnome-artwork srpm
<sri> tseng: I have a mouse pointer that looks like a box with lines in it
<tseng> older releases were ximian-artwork
<Treenaks> tseng: uh.. I /do/ have the engines installed
<Treenaks> or so it seems
<sri> tseng: so it sort of interferes. :-)
<tseng> i mean the cursor theme.
<rubenv> tseng: i have all industrial stuff
<tseng> not the engine
<rubenv> yet still no blue icons
<tseng> what do you mean, blue icons?
<tseng> are you talking about the icon theme now?
<rubenv> yeah, that got resetted too
<tseng> i have one guy telling me about his engines, one his cursor, and one his icon theme
<rubenv> as well as my mous
<tseng> slow down and read the facts
<rubenv> *mouse
<tseng> all you should have now is the industrial *engine*
<Treenaks> tseng: and the theme
<tseng> the icon theme and cursor are gone
<rubenv> eh :/
<tseng> Treenaks: yes.
<rubenv> why bork out those?
<tseng> you can install them, as i said, from novell srpm
<tseng> or hold onto your pants until jdub or whoever puts them back in
<Treenaks> jdub: I seem to be looking for my pants 8)
<rubenv> oh, they're only borked temporarly
<sri> jdub is always without his pants. :)
* rubenv disappears
<Treenaks> rubenv: it's hoary.. we should've expected this ;)
<tseng> seeing as that cursor was ubuntu default, id say its meant to be put back
<Treenaks> sri: I know.. I was in Mataro
<sri> tseng: indeed. :)
<tseng> also, its deadly obvious, so not much need to report it on irc like this
<Treenaks> tseng: anyway, mozilla in plain GTK theme looks ugly ;)
<tseng> if anyone wants to search/make a proper bug tracker however, feel free
<Treenaks> tseng: I always ask if it's known here... bugzilla's search feature is often useless
<sri> tseng: I agree.  I was just making sure that it wasn't something I changed
<tseng> no, its certainly valid
<sri> tseng: btw.. are you still creating bugzilla accounts?
<tseng> is there a problem with them? i know nothing about bugzilla.
<sri> tseng: oh..for some reason I thought it was you we wer supposed to send mail to for bugzilla account..nm if I'm wrong.
<tseng> no.. you can sign up on the web form
<Treenaks> sri: no.. bugzilla is all web-based afaik
<sri> yeah I have, months ago and I tried to follow up but I never got one created.
* sri was wondering why it was manual to create an account.
<sri> but that was back in november/december.
<sri> maybe it's changed now.
<tseng> i had a bugs account since october
<tseng> if not before
<sri> nod.
<Kamion> it was never actually manual
<Kamion> just sometimes if bugzilla and your mail system didn't like each other, there had to be manual intervention
<sri> oh nice, created abugzilla acct.
* mdz waits for baz 1.1.1 to rebuild its revision library
<Simira> jdub: ping?
<Treenaks> Simira: yes, themes are broken ;)
<douglas> hi !
<douglas> is there a place to download hoary images ?
<Simira> Treenaks: huh? what is broken?
<Treenaks> Simira: oh it looks broken here... nm :)
<Kamion> mdz: install/i386 is good; burning install/amd64; I'll be out at dinner for a while this evening, but will come back to do the release
<mdz> Kamion: amd64 and powerpc both in archive-copier at the moment
<mdz> douglas: http://cdimage.ubuntu.com/
<douglas> tnx :)
* lamont makes a note to go find bandwidth tonight to get his mirror current again
<elmo> Kamion: when do you plan to put array's on releases, if ever?
<Kamion> elmo: sabdfl said when RC happens
<elmo> boggle
<Kamion> I was fed up with the to-and-froing and that seemed a reasonable answer, so I left it at that
<elmo> [sorry about hoary-changes...] 
<mdz> Kamion: powerpc and amd64 both chugging along happily through stage 2, going very well
<mdz> your prompting changes have really accelerated my test cycle
<mdz> I switched the KVM over to powerpc to answer the prompts, and when I finished and switched back to amd64, it was already unpacking packages :-)
<Kamion> mdz: heh, fair enough :)
<Kamion> elmo: what about it?
<elmo> Kamion: 79x auto sync spam
<mdz> blame me
<Treenaks> elmo: that explains the beeping
<Kamion> d'oh
<sri> woo..got it going
<sri> mouse pointers look good
<sri> only my icons need fixin
<sri> jimmac to hte rescue :)
<Kamion> amd64 working well and installing ubuntu-desktop, I'll be back later
<Kamion> (to publish)
<mdz> Kamion: amd64 complete
<fabbione> Kamion, mdz: fix grub!
<fabbione> :P
<fabbione> you both got emails BTW
<elmo> can anyone rember any previous imports from non-Debian sources, other than MythTV and Marillat?
<tseng> elmo: imports from me pre-hoary
<elmo> tseng: right.. but, we get mono stuff via Debian and/or MOTU uploads now, right?
<tseng> yes.
<elmo> ok, thanks.. anything else, anyone?
<mdz> not that I recall
<elmo> heh, nice sign off
<mdz> elmo: do you know if i'm supposed to be able to login to the wiki this week?
<sm> mdz: the main wiki ?
<sm> if so: yes you are
<mdz> then it isn't working for me
<mdz> "you are not logged in"..."Welcome, you are logged in!" on the same page
<sm> here's what I just did: went to http://www.ubuntulinux.org/wiki , clicked "log in" at top right, entered name/pw, then it showed me FrontPage again, logged in
<sm> what did you do ?
<elmo> mdz: WFM - are you using ul.o still?
<mdz> elmo: I tried www.ubuntu.com, www.ubuntulinux.org, and site-edit.ubuntulinux.org
<mdz> none work
<sm> I logged in at  http://www.ubuntulinux.org, and ended up at https://www.ubuntulinux.org
<sm> as long as I stay at https, I'm logged in.. any other url and I'm not
<elmo> umm, not being funny, but try some browser you don't normally use? in case your normal one has it's cookies all confused
<sm> this sounds like https://bugzilla.ubuntu.com/show_bug.cgi?id=5725
<sm> at least it would help
<mdz> elmo: as a matter of fact, this browser has another tab which is logged in and working
<elmo> mdz: score
<mdz> elmo: score + WTF
<elmo> maybe logging in twice confuses it?
<mdz> possible, if idiotic
<sm> elmo, are you apache/squid admin ?
<elmo> sm: one of, yeah
<sm> I am the wiki guy and know plone/zope some
<elmo> we don't use squid tho
<sm> oh, my mistake
<elmo> we use apache's own caching
<elmo> sm: yeah, I figured from the list of channels you're on :) nice to meet you
<sm> likewise
<sm> any thoughts on 5725 ? this multiple urls can really confuse logins
<elmo> yeah, I'll take a pass at it tonight
<elmo> we're a bit headless chicken when it comes to plone atm, with Lu gone
<sm> oh, gone ?
<sm> didn't know.. well ping me if I can help at all
<elmo> sm: thanks, will do
<elmo> sm: yeah, she got a job working on a movie
<sm> ah.. plone not glamourous enough eh
<sm> :)
<lamont> sm: amazingly, plone was not quite the dream job for her that the movie one is...
<sivang> lamont: hehe
<sivang> elmo: She told me it was something for the discovery channel right?
<sivang> (IIRC)
<rcaskey_> are things looking good for Array4 today?
<sivang> mdz: regarding #6092, would you favor a patch to remove the option completely from the gui?
<sivang> mdz: (that is the input box for the UID)
<mdz> rcaskey_: yes
<rcaskey_> mdz: great, although it looks like I won't have it by the time I leave work ;)
<rcaskey_> I guess it's no big loss, can't get on the torrent anyway from here
<mdz> sivang: the problem is not the code changes, but agreeing on what should be done
<mdz> carlos seems to disagree
<sivang> mdz: I know, but you seemed to really discontent the fact that such an option is so "east" with the desktop, well, maybe add a confirmation dialog when someone chages that?
<sivang> s/east/easy
<sivang> and that can be understandable, IMHO
<mdz> I don't think the feature should exist at all
<sivang> (he said he doesn't mind us patching it, as upstream we're after FF)
<sivang> ok, I can take this to the mailing list if you like, let's see if we can get some concensus wrt what to do? The thing is, g-s-t is meant for the desktop sysadmin, which supposedly knows what he's doing..I think that can be attributed to his disagreement
<carlos> mdz: ?
<carlos> oh gst.
<carlos> ok
<sivang> carlos: hehe, yeah, not you :)
<rcaskey_> mdz: any thoughts about an admin group that has sudo rights?
<rcaskey_> mdz: and then users could create new admin users by just using g-s-t
<mdz> rcaskey_: yes, this has come up several times and I think it is a good idea
<rcaskey_> Is that to major to happen by Hoary?
<rcaskey_> %s/o h/oo\ h/
<mdz> it is a bit late in the game for that kind of change
<mdz> while many people have talked about it, no one has written code
<srbaker> what's g-s-t ?
<rcaskey_> it would just be adding a group and one line to the default sudoers file
<sivang> srbaker: gnome-system-tools
* tseng wonders what happened with this big sync
<srbaker> ahh
<mdz> rcaskey_: yeah, it sounds pretty simple. could you send a tested patch?
<mdz> rcaskey_: I'm very busy with other things
<zul> tseng: evilness is afoot
<zul> later
<sivang> rcaskey_: I can could an "Admin" profile to g-s-t, which would make creating new "admins" only choosing their profile in the add user dialog :)
<sivang> rcaskey_: that is, add an admin profile
<rcaskey_> mdz, I might could actually manage to do that
<rcaskey_> what package governs /etc/groups?
* dholbach sighs: using auto* to do stuff which belongs in {post,pre}{inst,rm} should be punishable
<mdz> rcaskey_: base-passwd, but you don't want to touch that
<mdz> rcaskey_: the two packages which would need changing are sudo and passwd
<mdz> sudo to change the default /etc/sudoers, and passwd to do add the user to the group instead of modifying /etc/sudoers
* lamont goes to fetch kids
<rcaskey_> mdz: any problem with using the group name admin?
<mdz> rcaskey_: it's a tough call
<mdz> we already have adm both adm and admin would be confusing
<rcaskey_> mdz: curses you and your beagle!
<rcaskey_> finding my email address
<sivang> rcaskey_ , mdz : maybe the group "super" ?
<bluefoxicy> god I suck
<bluefoxicy> I made it build the kernel
<bluefoxicy> tried to install the package
<sivang> or do we have something liek this already?
<bluefoxicy> no kernel installed
<rcaskey_> is wheel the traditional name?
<rcaskey_> it's admin over here in OS X land
<bluefoxicy> yes wheel
<tseng> rcaskey_: traditional for bsd, gentoo, osx. mdz argued that the meaning was slightly different
<tseng> wheel is users who can su, he wanted a new group for sudo
<mdz> wheel actually has the right semantics
<mdz> but we don't have a wheel group
<mdz> and if we're going to create one, wheel is a silly name :-)
<sivang> doens't imply much of what it entails to do..
<dholbach> i'm off to bed - sleep tight everyone
<mdz> fabbione: still here?
<rcaskey_> wheel is dumb
<rcaskey_> what does the adm group do?
<smurfix> rcaskey_: wheel has 20+ years of history behind it ...
<smurfix> ... fortunately, all the zealots about that one tend to be *BSD people.
<rcaskey_> if someone sees admin on a dropdown though, they might actually guess what its for
<sivang> smurfix: is wheel used in debian for the same purpose?
<smurfix> rcaskey_: I agree.
<smurfix> sivang: No. Doesn't have one.
<jbailey> IT doesn't look like LSB specifies that it be called wheel, which is nice.
<bluefoxicy> wheel is still defacto
<rcaskey_> so what does adm do?
<HrdwrBoB> bluefoxicy: so is browse-in-one window
<bluefoxicy> it is preferable that the defacto standards be stuck to in this case to avoid confusion
<bluefoxicy> HrdwrBoB: Change defactos only when they cause a problem, not just to change them
<rcaskey_> is visudo deprecated?
<bluefoxicy> HrdwrBoB:  are we going to use wheel to control access to the mouse wheel?
<bluefoxicy> :)
<HrdwrBoB> heh
<bluefoxicy> more pertainently, even if you change the name, you must avoid making another 'wheel' group
<HrdwrBoB> at the same time, why be afraid of changing something
<bluefoxicy> because other tools may rely on 'wheel' to be the symbolic name
<bluefoxicy> unless there's a greater gain than loss, care should be taken in avoid change :)
<bluefoxicy> (a principle commonly called "improvement" isn't it?  :P)
<bluefoxicy> anyway
<bluefoxicy> i'm done talking
<rcaskey_> basic procedure is apt-src the package, copy the resulting directory, make changes, patch to get the diffs, and submit the patch?
<rcaskey_>   --with-all-insults
<rcaskey_> hrmm
<HrdwrBoB> rcaskey_: yeah
<rcaskey_> thanks all
<rcaskey_> I'm gonna be on later with some more newbieish questions after I finish making the needed changes
<eruin> did you decide to remove the pretty mouse cursors?
<bluefoxicy> https://www.ubuntulinux.org/wiki/NewHoaryHedgehog  do not edit  o.o what should be edited then
<bluefoxicy> " Security update notification GUI (MichaelVogt?)"  <-- that thing popping up in the status bar once in a while with updates, I like it, but it's completely passive
* mdz deletes NewHoaryHedgehog
<bluefoxicy> the damn thing just makes an icon, and then when I go down to click on i.e. gaim, I see it.  It doesn't pop up a baloon or un-autohide the panel
<bluefoxicy> which may be a good idea
<bluefoxicy> (considering on a stable system it should only be popping up for security updates)
<bluefoxicy> on Windows though there's a billion of these that do that (firewalls, antivirus, windows update, disk cleanup) and they all get annoying pretty fast, so uh.  o.o
<mdz> it displays a notification icons when updates are available, when you hover, it tells you how many, and when you click, it applies them.
<bluefoxicy> _____________________________________ -> [ (o) <(New updates are ready to be installed) 12:31] 
<bluefoxicy> mdz:  yeah.  My notification area is not onscreen though.
<mdz> well, the default one is
<bluefoxicy> true.
<bluefoxicy> also the icon is very still from what I can see
<bluefoxicy> Fedora has a similar thing
<sivang> bluefoxicy: what's the pkg name for this notifier?
<bluefoxicy> which displays a check mark when there's no updates, and a slowly pulsing/fading ! in a red sphere when there's updates
<bluefoxicy> sivang:  I have no idea.  When I installed hoary it was there
<bluefoxicy> or rather, a day after I installed hoary, an icon popped up in my taskbar
<bluefoxicy> I have no idea what the running process even is
<sivang> interesting, I didn't get it. and I dist-upgrade all the time
<bluefoxicy> update-notifier is the process
<mdz> sivang: sudo aptitude install ubuntu-desktop
<bluefoxicy> Package: update-notifier
<bluefoxicy> or what mdz said
<bluefoxicy> htf it got running I'll never know; I have an old, left-over gnome-session from gentoo that doesn't have it in there
<sivang> mdz: I had it :) I wonder if an upgrade removed it..
<sivang> hmm depencency list is 10M
<bluefoxicy> mdz:  I'm annoyed that the icon actually dissappears when there's no updates, trying to find it so I can see if there's any options to change that behavior but . . . umm.  I can't find the icon, it's dissappeared  o.o
<mdz> that is by design
<bluefoxicy> I noticed.  I like my running processes to be non-interactive daemons or accountable though :)
<mdz> it is not something which should be displayed on the desktop continuously; it is only interesting when there are updates available
<sivang> No Gimp-Print PPD files to update.
<sivang>  * Restarting Common Unix Printing System: cupsd                         [ ok ] 
<sivang> Setting up ubuntu-desktop (0.25) ...
<sivang> touch: cannot touch `/var/lib/upgrade-notifier/dpkg-run-stamp': No such file or directory
<sivang> E: Problem executing scripts DPkg::Post-Invoke 'touch /var/lib/upgrade-notifier/dpkg-run-stamp'
<sivang> E: Sub-process returned an error code
<mdz> sivang: sudo dpkg -P upgrade-notifier
<bluefoxicy> heh, true but it has options doens't it?
* bluefoxicy shrugs
<bluefoxicy> ok what's eating 80% of my net
<bluefoxicy> since when the heck do you get 190k/s in bittorrent   o.o
<sivang> bluefoxicy: when downloading from a.u.c I do :)
<bluefoxicy> sivang:  I thought the upgrade notifier may have been downloading things in the background, forgot about bt :)  but bt only ever does like 15k down anyway  o_O
<bluefoxicy> anyway
<bluefoxicy> I'm trying to find the thing to see if there's options to have it auto-download or (not that I actually recommend anyone set this) auto-install updates
<sivang> well you can do this "manually" by adding cron entries
<sivang> (I did it once, didn't end all too good, for a sid machine)
<sivang> dholbach: hey, didn't you say you were going to sleep? :)
<bluefoxicy> yes but while we're flashing icons around we might as well have one appear that in hover says "updates being downloaded (20%)"  "Uploads being installed (45%)"  "*blink* *blink* GPG key updates, attention REQUIRED"
<dholbach> sivang: couldnt sleep
<sivang> hmm, I now have readahead. cool
<dholbach> sivang: i guess i'll learn a bit - that will make me sleep well :-)
<bluefoxicy> heh.  "GPG updates are available.  Please check ubuntulinux.org, browse the site, make sure it hasn't been owned, and then check to make sure the key fingerprints match before installing"
* bluefoxicy is just being weird.
<sivang> now that's a first timer that I don't really feel updatedb slashing down my disk acces , nice
<Kamion> bluefoxicy: speaking of de facto, the wheel group on many systems is de facto gid 0. (a) we already have root as gid 0, adding another name for it would be confusing, (b) I don't think we should be adding users to gid 0 by default, since that gives them significant extra privileges without the need even to use sudo (therefore without passwords etc.)
<Kamion> sivang: there's already a program called 'super' which is similar to but distinct from sudo, so I feel we should be careful about using that name
<bluefoxicy> Kamion:  wheel == root wtf?
<bluefoxicy> I thought wheel was 76
<Kamion> bluefoxicy: wheel is gid 0 on lots of systems. There is currently no gid wheel in Debian/Ubuntu; if it were to exist, it would really have to be defined in base-passwd.
<Kamion> (which I maintain)
<Kamion> bluefoxicy: 76 must just be one particular system, I've never heard of it having that value
<Kamion> there is almost no standard for gid name/number mapping
<Kamion> there are a couple which are common and even those you can't rely on 
<Kamion> bluefoxicy: FreeBSD has wheel:0 for example; see http://www.freebsd.org/cgi/cvsweb.cgi/src/etc/group?rev=1.31&content-type=text/x-cvsweb-markup
<Kamion> I'm sure the other BSDs and practically any Unix directly descended from BSD are similar, since according to FreeBSD CVS that was in 386BSD
<bluefoxicy> hmm
<bluefoxicy> Kamion:  odd.  I've seen wheel in i thought gentoo and one other I can't remember. . . I think itm ight have been mandrake, I dunno anymore though
<Kamion> also note pam_wheel which refers to traditional semantics of the wheel group
<bluefoxicy> I remember noticing it when i tried to su
<bluefoxicy> it was like "authentication denied" and I was like "BUH?"
<mdz> Kamion: welcome back
<bluefoxicy> a bit of googling brought up the wheel group
* bluefoxicy shrugs
<bluefoxicy> my mistake
<mdz> Kamion: I'm 5 for 5 in my tests of the current dailies
<Kamion> mdz: yeah, I'm publishing as I type
<Kamion> fabbione: grub> aha!
<Kamion> fabbione: ... although I see no PROT_anything in grub. will have to investigate.
<mdz> Kamion: do we need thom to get the torrents going?
<Kamion> mdz: yes
#ubuntu-devel 2005-02-16
<mdz> Kamion: do you have an announcement prepared already?
<Kamion> not even a little bit
<mdz> thom says ETA: 30 minutes
<mdz> mako: ping,, re: array 4 announcement
<Kamion> I'm starting one now
<Kamion> um ... I was just going to do it based on the array 3 announcement, I think that's worked pretty well so far
<mdz> ok
<mdz> was looking for a copy
<mdz> you send these to where, -devel and -users?
<Kamion> yeah
<Kamion> I always need to go through the installer changes I've made in order to write the release notes anyway
<Kamion> haha, bonus, due to the lazy way I wrote the end of publish-release, all I needed to do was 'publish-release daily 20050204.2 install no array-4; publish-release daily-live 20050204.2 live no array-4'
<mdz> the only interesting user-visible casper change is that it doesn't cause init to emit scary messages anymore
<sivang> hrm I'm tired, night everyone!
<Kamion> mdz: ok, thanks
<Kamion> that's since array 3.5 live right?
<mdz> yes
<jbailey> Kamion: Does the installer have tac and tsort available to it when it's running hotplug, or are you just in busybox land at that point?
<mdz> jbailey: busybox
<ajmitch> hello
<bluefoxicy> mdz:  how are users expected to upgrade ubuntu when a new version is out
<Kamion> mdz: and the localisation fix
<jbailey> mdz: Thanks.  Time to conjure some awk magic, I guess =)
<mdz> Kamion: oh, good call
<Kamion> jbailey: neither appears to be in busybox
<bluefoxicy> mdz:  all the answers I can think of involving altering a setting to point at a new source, whether using synaptec's package manager or editing some files
<jbailey> Kamion: No, they're definetly not.
<jbailey> Thanks, though.
<Kamion> mdz: (have you confirmed it to work, actually?)
<mdz> Kamion: let me do a quick test
<mdz> someone did confirm it at the time, sivang I think
<robertj> mdz: ok I have a /shadow-working and a /shadow-prestine, what args do I need to force feed patch to get the output you need?
<mdz> robertj: diff -ruN
<mdz> Kamion: confirmed, it works
<robertj> mdz: note to self: doh!
<robertj> note to self: set a root password
* robertj rm'd /etc/sudoers to test ;)
<robertj> brb
<robertj> actually I wont be, im gonna fix this and then be off to dinner
<Kamion> mdz: where was 3.5 announced?
<Kamion> mdz: oh, never mind, found it
<mdz> 3.5 went to -announce because it was the first live CD milestone EVAR
<mdz> do you think we should do broader announcements of any Arrays, or not until Preview?
<jbailey> Mm.. no awk in the busybox udeb.
<mdz> what's the required task?
<Kamion> mdz: not until preview, I feel
<Kamion> I think the announcements to -users and -devel have served the intended purpose of Sounders and Arrays pretty well up to now; they've had a substantial amount of interest and testing, but not volumes that we can't cope with during development
<Kamion> mdz: could you glance over http://people.ubuntu.com/~cjwatson/array-4-announce?
<Kamion> jbailey: sed, tr, and 'while read ...; do' tend to be enough for most things IME ...
<Kamion> most awkish things, that is
<Kamion> plus good use of ${var#...}, ${var%...}, etc. :-)
<srbaker> whoa
<srbaker> 123 upgraded packages.
<elmo> gar, I so wish apt had rate limiting
<jbailey> Kamion: I need to do an ordered sort with some guarantees put on it.  Like the pci hotplug run has to happen before the IDE one.  I can probably do a series of ugly pipes with grep -v to just extract them and force them to the end, though.
<mdz> Kamion: glancing
<mdz> Kamion: I think elmo might object to:
<mdz> I recommend rsync if possible, as you can then download future images
<mdz> based on this one to save bandwidth.
<Kamion> hm? that's been in the sounder/array announcements since sounder 6 or so
<mdz> I think we ought to change it
<Kamion> oh, but the rsync limits, blah
<mdz> only users who download ISOs regularly should use rsync
<mdz> and they certainly don't need to use rsync the first time, in order to be able to rsync later images
<Kamion> true enough
<Kamion> just delete that paragraph then?
<mdz> that sentence and the rsync:// URL, I'd say
<Kamion> I do think the rsync:// URL should stay; it is not obvious how to construct it from the http:// URL
<Kamion> at least I assume that it's not obvious because everybody seems to have to ask about it when we don't mention it explicitly
<mdz> isn't it on the Archive page in the wiki?
<mdz> I think "here are http and torrent URLs; for other stuff look at this page" is fine
<Kamion> dude, I'm nearly convinced *you* asked about it :)
* thom shivers
<Kamion> hm, Archive is actually wrong, correcting
<thom> right, so we need to sync to torrent.u.c and then i'll kick
<mdz> we're nearly there
<elmo> ARE WE THERE YET??
<thom> #ubuntu-devel, featuring James Troup as ADD boy
<Kamion> ok, removed the rsync: line with reservations
<lifeless> someone put that in the topic, puhlease
<thom> lifeless: go for it ;-)
* ..[topic/#ubuntu-devel:lifeless] : Ubuntu development channel | use #ubuntu for support and general discussion | http://www.ubuntulinux.org/wiki/DeveloperResources
<Kamion> creating .torrent files, then I'll sync
<lifeless> # | http://www.ubuntulinux.org/wiki/HoaryGoals 
<lifeless> bah
<thom> lifeless: um ;-)
* ..[topic/#ubuntu-devel:lifeless] : Ubuntu development channel | use #ubuntu for support and general discussion | http://www.ubuntulinux.org/wiki/DeveloperResources | http://www.ubuntulinux.org/wiki/HoaryGoals
<lifeless> silly copy n paste
* ..[topic/#ubuntu-devel:thom] : Ubuntu development channel | use #ubuntu for support and general discussion | http://www.ubuntulinux.org/wiki/DeveloperResources | http://www.ubuntulinux.org/wiki/HoaryGoals ||  #ubuntu-devel, featuring James Troup as ADD boy
<thom> hurrah for tab completion
<mdz> Kamion: thanks
<lifeless> oh thats nice, I did not know that.
<thom> lifeless: irssi > *
<mdz> Kamion: we'll revisit the rsync thing when we have more server-guts to throw at the problem
<lifeless> yah, irssi is love
<mdz> at this point, fewer people finding the rsync url is a feature :-/
<Kamion> mirrors syncing now
<thully> hi - I have a question - when the X bug was causing problems, did this effect dist-upgraders or just people installing/using live CD snapshots?
<Kamion> both as far as I know; it was a cat-induced typo in the postinst
<elmo> we dropped mozilla-locale-* ?
<mdz> we did?
<thom> elmo: they were only seeded by the language packs
<thom> s/seeded/depended on/
<elmo> mdz: anastacia wants to remove a whole bunch
<mdz> ah, pitti removed the deps
<mdz> elmo: feel free to add them to supported, we want to keep them
<mdz> in fact I think they were there, and were removed because they were added to the language packs
<Kamion> score
<elmo> mdz: okay, what about {i,w}{danish,dutch} ? they're built by source packages that got promoted for building aspell i18n dicts.. do we want the {i,w} variants too?
<Kamion> I really must automate that HEADER.html thing, doing it by hand each time is no fun
<elmo> re-seeding mozilla-locale for ca, cy, da, el, es-es, it, no-nb, pl, ptbr and sl 
<Kamion> and .htaccess, come to that
<mdz> elmo: if ispell is in main, and the source packages are in main for other reasons, yeah, why not
<Kamion> mdz: should I put "(Install and Live)" or something in the subject line?
<Kamion> I like the pun anyway :)
<Kamion> INSTALL OR DIE
<mdz> Kamion: sure
<mdz> Kamion: "installation and live editions"?
<elmo> mdz: hmm, ispell is in main but we don't seem to have {m,}any other i18n dicts for it
<Kamion> bah, how boring
<Kamion> ok, done
<Kamion> ARE WE NEARLY THERE YET, mirrors
<mdz> live stuff is still appearing on cdimage.u.c
<mdz> is the torrent mirror up to date?
<elmo> thom's working on it
<elmo> mirnyy's only up to ia64
<elmo> powerpc...
<thom> orcadas is syncing now
<Kamion> orcadas? new torrent?
<thom> yeah
<Kamion> ok, since I want to get to bed, if you don't mind I'll send the announce as soon as mirnyy's complete; mail delays should take care of the rest anyway
<thom> fine from where i'm sat
<Kamion> ah, there it goes
<elmo> mirnyy's done
<Kamion> sent, night all
<thom> orcadas is at ia64
<thom> night duder
* tseng trys to snag array-4 before the masses hit
<mdz> tseng: use the torrent and benefit from the massis
<mdz> masses
<tseng> heh, good call
<tseng> i just used gnome-bt on array-3.5 and it rocks
<mdz> it's installed by default now
<jdub> Kamion: night, rock :)
<thom> torrents should be kicking ass and taking names
<mdz> seeding {install,live}-i386
<thom> aww, the ia64 live cd doesn't have any peers
<mdz> it also doesn't work, I don't think
<thom> really? i should grab a copy and try it next week
<thom> but now, i should go to sleep
<thom> or at least leave my computer
<thom> g'night
<mdz> night, thanks
<thom> no problem
<lamont> mdz: ia64 livecd won't work until it's built with -14 kernel, I believe
* lamont checks
<lamont> nope.  -14 still lacks the needed ia64 changes.
<lamont> those will be in -15, I believe - fabbione had them in his tree
<mdz> lamont: is mplayer all happy now?
<elmo> when his last 3 uploads push through, it should be
<elmo> I asked him to do the ffmpeg stuff we discussed
<mdz> yeah, I saw the uploads and that prompted the question
<mdz> the array 4 announcement seems to have gone over quietly
<jdub> mdz: can fix.
<elmo> uh
<elmo> 	dpkg-distaddfile gpgv-udeb_$(VERSION)_$(DEB_HOST_ARCH).udeb debian-installer extra
<elmo> how can that possible be right?
<mdz> looks reasonable to me?
<elmo> mdz: not so much if you're cross building
<mdz> ah, ok
<lamont> elmo: like that actually works...
<lamont> mdz: no clue if it's happy yet, but elmo tells me it should be...
<mdz> daniels: so, array 4 is done
<mdz> daniels: feel free to break xorg
* lamont giggles
<mdz> daniels: can we do something about my KVM regression?
<mdz> daniels: it seems that if we can't probe, and so go to the trouble of asking the user which modes they want, we should give them what they ask for
<daniels> mdz: yes, that's already fixed locally
<daniels> (i fixed it about 10min after you first tlold me about it)
<mdz> daniels: oh, great
<mdz> so that'll be in ubuntu16
<daniels> yes
<mdz> which will also eliminate the need for XORG_FORCE_PROBE=yes
<mdz> and is free of live CD regressions in your test
<daniels> mdz	afaict, yes
<mdz> let me know if you want to send some debs my way to test
<daniels> mdz: (X_F_P can be unset or yes for the same effect; no to disable it)
<daniels> sure.  might throw up some source packages later, but for some reason my local build is screwed with strip (it just point-blank refuses to strip them), so all my debs are hoooooge.
<mdz> DEB_BUILD_OPTS=nostrip lingering somewhere?
<daniels> mdz: nope, strip gets called, but bails out
<daniels> strip: unable to copy file 'debian/xserver-xorg/usr/X11R6/lib/modules/input/palmax_drv.o' reason: Permission denied
<daniels> ad infinitum
<daniels> umask doesn't seem to be a problem, not sure of what's up
<wasabi> Remember earlier when I asked about the cyclic build dependencies being acceptable? I am working on going over Debian's Java stuff and cleaning it up... seems there are lots of these.
<wasabi> XML libraries requiring utilities requriing XML libraries, and onward.
<wasabi> Should I even try to sort this out? Or is it acceptable?
<mdz> jdub: still here?
<mdz> wasabi: if it is possible to build the packages without the cyclic dependencies, then yes, that is preferable
<mdz> wasabi: these cases need to be handled manually when we bootstrap a new architecture, which is labour-intensive
<wasabi> yeah.
<wasabi> Well, it being Java might not make that that important.
<wasabi> It's arch all
<mdz> lamont,jdub: I'm ready to make the ubuntu-live metapackage, but the current contents of the live seed are sort of random
<mdz> we should have some guidelines/rationale/sanity before we start to use it
<jba> hey gang
* jba lurves he's working acpi on dell x300 laptop
* jba hugs ubuntu
<lamont> mdz: does ubuntu-live Depend: ubuntu-desktop, I wonder?
<lamont> in any case, you say when, and I'll switch the script over
<jba> lamont, i was thinking of installing tomboy from ubuntu apt servers, but my mono prefix is /user/local
<jba> should i just install it from source ?
<lamont> "my mono prefix" == something you did, or does our mono package have things broken?
<lamont> hoary has mono 1.0.5, or should
<tseng> jba: er, why?
<tseng> install tomboy + mono all from hoary
<jba> lamont, something i did
<jba> i install mono form source cause I hack on mono sources
<jba> lamont, i would be using mono/gtk#/gecko# and so on from svn as of two days ago
<tseng> sounds like you are on your own, dude
<jba> tseng, I'm actually a mono hacker (working on MWF at the moment), that's why
<lamont> then either tomboy from source, or point it at /usr/local after you install, I guess
<jba> cool
<jba> just thought I'd ask
* lamont has never used mono
<jba> I'm not adverse to installing from source, but was wondering if you wanted me to test the installation
<jba> sorry dude (lamont), I thought you were packaging mono stuff, must have been tseng instead
<tseng> not jumping to support non-standard installs from svn, no
<lamont> jba: I just build the stuff
<jba> i wasn't asking for support guys
<jba> just wanted the lowdown on how it's installed
<tseng> well install whatever works, your own your own
<jba> I'll give it a whirl from apt, and let you know how it goes ?
<tseng> is how i mean.
<jba> tseng, I know that, I'm cool with it
<jba> just thought maybe you wouldn't mind some testers
<jba> apologies for coming off as someone asking for suppot
<jba> catch ya round later
<tseng> odd.
<tseng> battlstar, bbl
<mdz> lamont: no, ubuntu-live will not depend on ubuntu-desktop
<mdz> dependencies between the metapackages get ugly
<lamont> mdz: ok
<thully> hi - I was trying to rsync an iso to array 4, and I wondered - where do I see how much has to be downloaded in order to rsync?
<zul> hey
<robertj> hey all, Im bumbling around trying to create a diff of the stuff that has changed from the apt-src package, but it's picking up all the new stuff in the debian directory
<robertj> is their an equivalent of a dpkg-buildpackage mrclean or something?
<lamont> robertj: "fakeroot debian/rules clean"
<robertj> ahh
<zul> lamont: what are you still doing up?
<lamont> zul: about to go to bed, truth be told
<zul> lamont, what time is it there?
<lamont> 2131
<zul> thats not too bad..
<zul> 2331 here
<tseng> daniels: ping
<daniels> pong
<tseng> i just did a clean install of hoary, i have a ~/.Xresources with settings for rxvt
<tseng> any ideas why its not seeming to be picked up?
<tseng> did xrdb -all .Xresources even
<daniels> try .Xdefaults instead; other than that I'm not sure, sorry
* daniels wanders off towards the kitchen.
<tseng> yeah i copied it there also.
<tseng> stupid thing
<crimsun> tseng: err, xrdb -merge ~/.Xresources ?
<tseng> crimsun: still nothing
<wasabi> What would I use in cdbs to do something before the build starts?
<crimsun> this is "true" rxvt, correct?
<tseng> no, rxvt-unicode
<tseng> this was working until i reinstalled
<crimsun> I presume you use URxvt* ?
<robertj> what params do you need to reapply a diff created with ruN
<tseng> crimsun: yes.
<tseng> robertj: patch -p1 < ~/diff
<tseng> robertj: or so
<crimsun> hmm, puzzling.
<robertj> hrmm, how can I test the configure script?
<tseng> actually its kind of working, just not the font
<robertj> the closest I managed to get was to coerce a message that it was already configured
<ajmitch> ogra: around?
<crimsun> (probably still asleep)
<ajmitch> nah, he's only 40min idle
<ajmitch> although he was disconnected then..
<crimsun> timed out, yeah
<wasabi_> i wonder if having EVMS set up by default removes the need for the md startup scripts
<zenrox> whos the nivida god in here
<fabbione> mdz, Kamion: andrew morton acknoledge the patch :-)
<mdz> wasabi_: nearly so, yes
<mdz> fabbione: cool
<dilinger> which patch is that?
<fabbione> dilinger: noexec=
<fabbione> mdz: did you read the other mail about grub?
<fabbione> (btw Robert released another inotify patch yesterday with our fixes and it should fix our critical bug)
<fabbione> i will test it on monday :-)
<fabbione> hmmm
<fabbione> what do we use to burn dvd's?
<crimsun> dvd+rw-tools+nautilus-cd-burner?
<fabbione> crimsun: without natilus?
<fabbione> dvd+rw-tools are ok to format/clean but they can't burn
<fabbione> and cdrecord needs the "PRo" version
* fabbione would like cmd line
<crimsun> that's a good question. Unfortunately I don't know.
<fabbione> dvdrtools - DVD writing program
<crimsun> ah, in multiverse?
<crimsun> sorry, I presumed you meant something in main
<fabbione> eheh no problem :-)
<fabbione> crimsun: how do you blank dvds?
<fabbione> apparently dvd+rw-format doesn't do it properly...
<crimsun> fabbione: (no dvd drive here)
<fabbione> ah ok
<mdz> fabbione: yes, I did read the mail, but I'm not sure how to implement the fix
<mdz> fabbione: I use dvd+rw-tools to burn, all the time
<fabbione> mdz: what command do you use?
<mdz> growisofs, the program with the completely uninformative name
<fabbione> ok
<fabbione> thanks
<mdz> growisofs -Z /dev/scd0=hoary-live-i386.iso
<mdz> is my finger macro
<mdz> you can also burn DVDs with dd :-)
<fabbione> i am having some weird problems and i am trynig to figure out if it is a media problem or not
<mdz> what kind of media?
<fabbione> "budget" dvd-r
<fabbione> the same iso can be burned without any problems on dvd+rw
<fabbione> but whatver i use i cannot burn it on the dvd-
<fabbione> the strange thing is that the rw reports even less space than the dvd-
<fabbione> it always fails at the end
<fabbione> not being able to close the disc (on windows)
<fabbione> and it doesn't even start in linux
<mdz> I use dvd+rw exclusively
<fabbione> (indipendently from the media)
<mdz> so I don't know much about other media
<mdz> but I have had no problems with +rw
<fabbione> ok
<fabbione> neither do i, but i cannot store everything on +rw :-)
<fabbione> not after i got 600 DVD's -r :-)
<mdz> that is a lot of DVD
<fabbione> i know :-)
<fabbione> somebody was kind enough to give them as present for the wedding
<mdz> only 7 days to go :-)
<fabbione> 7 days, 6 hours and 35 minutes
<fabbione> don't try to steal my (still) FREE TIME!
<fabbione> :P
<fabbione> mdz: to clean the dvd do you use dvd+rw-format?
<mdz> I have never had to do that
<fabbione> so you never reuse a dvd?
<mdz> of course I do
<mdz> I just growisofs over it again
<fabbione> or growisofs does it for you?
<mdz> there is no need to explicitly erase
<fabbione> cool
<mdz> you just rewrite
<fabbione> i am kinda "new" to dvd mastering
<fabbione> ok
<mdz> DVD+RW is so much nicer than CD-RW
<mdz> very simple
<fabbione> i get that ;)
<smurfix> I still need to get a DVD burner for the server -- the thing is busy enough, backup over the network would be deadly
<fabbione> smurfix: i have a LITE-ON.. cheap and nice
<smurfix> mdz: new initrd image for the key selector available
<smurfix> I'm off for a week of {supervising the kids while they do some,} skiing now, but I'll take the cellphone and the laptop
<mdz> smurfix: you don't think we should put it into hoary yet?
<smurfix> mdz: Need a Python bugfix for that, and d-i doesn't yet know how to build the file.
<smurfix> I'll do that work over the next few days.
<smurfix> mdz: The Python fix is already in CVS, and the next release will be soon; if not I'll do an interim bugfix update.
<mdz> ok
<mdz> enjoy your holiday
<mdz> ogra: ping?
<smurfix> mdz: I will, assuming I won't freeze my ass off :-/
<dholbach> good morning
<sivang> dholbach: morning
<dholbach> hi sivang
<sivang> dholbach: what's up?
<dholbach> sivang: got to do some shopping and some learning afterwards :-)
<sivang> dholbach: when is your test?
<dholbach> sivang: what are you up to, today?
<dholbach> monday
<sivang> oohh
<dholbach> last exam :-)
<sivang> :-)
<dholbach> couldnt sleep last night, so i packaged gparted
<sivang> dholbach: hehe, nice going for someone who can't sleep :)
<dholbach> it really looks nice, but i discovered a SERIOUS bug
<dholbach> unmounting a vfat partition caused the box to die
<dholbach> so i put this in a kind of "experimental" repo :-)
<dholbach> 0.0.9 (next release) should be better :-)
<sivang> Ah I see, well, do you have any idea why tomboy won't start ? (sheesh all my notes..)
<dholbach> on amd64 there is no mono atm :-/
<dholbach> so i couldnt test... but does it say anything, if you start it from console?
<sivang> no
<sivang> :((
<dholbach> strace ?
<sivang> and tseng is 3 hours into away ..
<sivang> lemme check
<dholbach> does it look for a file it can't find?
<sivang> clock_gettime(CLOCK_REALTIME, {1107596150, 55674000}) = 0
<sivang> futex(0xb70504cc, FUTEX_WAIT, 126, {0, 99326000}
<sivang> seems like it's stuck somewhere...
<sivang> doesn't go out of this
<dholbach> nothing funny before?
<sivang> no, everything was working just fine, and I was using tseng's repo's before, oh wel..
<dholbach> imean in strace
<dholbach> <- shower
<sivang> I'll check and let you know
<sivang> mvo_: morning
<mvo_> hi sivang 
<mvo_> hi all
* sivang wonders how come his theme changes so much after last night's upgrade
<Kamion> fabbione: I saw the grub mail even if mdz didn't. working on it now(ish)
<fabbione> Kamion: cool, i am talking with Anderw Morton that is asking why we are having this problem and pushing for the noexec fix for 2.6.11
<fabbione> they scheduled for 2.6.12 but that was not clear from the first emails
<sivang> seb128: any idea why my theme changed completely after last night's upgrade? ;-)
<sivang> seb128: and the mousr cursoe became plain old X's insteaf of the gnome one? 
<fabbione> Kamion: i think anyway that grub is not the only that needs to be fixed
<seb128> sivang: what theme are you using ?
<Kamion> fabbione: there are extraordinarily few applications that this affects; if grub isn't the only one, it's almost certainly the only one we care about
<fabbione> roger :-)
<Kamion> fabbione: and reading ak's mail I understand the problem and it makes sense for it to be fixed in grub, imho
<sivang> seb128: I had a customized one...
<sivang> seb128: can't recall
<seb128> sivang: so no way to help you
<sivang> seb128: ok, I'm searching...btw, I see now that I can really page through the available themes in the them manager window, do you have the same problem?
<seb128> "can really page through"
<seb128> ?
<sivang> no matter if I try scrolling using the kbd or mouse, it goes back to the first theme
<seb128> oh, yeah, known issue
<sivang> there
<sivang> 's a bug number already and an assumtpion what causes this?
<seb128> I think that's fixed in the CVS with all the patches commited this week
<seb128> let me know if that still happen next week with the new release
<sivang> ok, I made the changes back,
<sivang> for some reason the "custom" theme was still there,
<sivang> but contained no info probably as it was plain white without borders etc..
<sivang> I am using Glider as my Controls theme, and metabox for the windows
<seb128> I think industrial is broken
<seb128> k
<sivang> industrial seems working here ;-)
<seb128> you said that your mouse cursor is the standard one and now you say that's working fine
<seb128> is that working or not ?
<sivang> seb128: err, yes, *BESIDES* the mouse cursor :) Detail, details...
<syn-ack> Im thinking I may need to submit another bug report Rhythmbox.
<seb128> feel free :)
<syn-ack> Its crashing when one tried to load a /dir with multiple directories in it.
* mvo_ grumbles about baz and the "corrupt pristine" message 
<blixtra> Hi all, For a bug in a universe package, do I submit to ubuntu or debian?
<syn-ack> to its maintainer.
<blixtra> the debain mantainer I assume, since it's in universe.
<sivang> mvo_: how did the pristine got corrupted? ;-)
<syn-ack> hrm
<mvo_> sivang: I don't care if they are it should just rebuild it
<Kamion> ooh, grub-install worked
<fabbione> Kamion: cool... i need to leave now.. going to test ubuntu sparc on a TELCO datacenter
<fabbione> bbl
<mdz> Kamion: nice
<sivang> morning pitti 
<spiral> hi
<spiral> Any new about smart batteries support ?
<pitti> Hi sivang 
<mjg59> spiral: I've seen no progress on the kernel driver, I'm afraid
<spiral> mjg59: saki told me that this worked on his computer, when he rebuild the kernel
<mjg59> spiral: Yes. That's not much use to us, though
<mjg59> Currently it's not possible to usefully support normal batteries /and/ smart batteries
<spiral> mjg59: hmmm... incompatibility between two kinds ?
<spiral> and wouldn't it be possible to have a specific kernel for smart batteries ?
<mjg59> No
<mjg59> The maintenance hassle would be large
<Kamion> there are major benefits for us in having just one supported set of kernels
* sivang just experienced a very strong lightning. machines started to work, displays glittered
<spiral> mjg59: ok... So I suppose the only way is to wait for an upgraded version of the patch, that could work for both situations ?
<mjg59> spiral: It's possible that we'll provide smart battery support in the kernel for hoary, but userspace tools won't be able to work with it
<mjg59> By the time Bendy comes around, everything ought to be using HAL for battery information, at which point it ceases to be a problem
<spiral> mjg59: so this means that the battery indicator of KDE or gnome wouldn't work ? until HAL usage ?
<Treenaks> Bendy?
<Treenaks> that's Hoary + 2?
<Treenaks> +3 ?
<sivang> hoary+1
<sivang> :)
<sivang> mdz actually refuses the recognize the name of the beast :)
<sivang> s/the/to/
<mjg59> spiral: Correct
<Treenaks> sivang: according to the wiki that's still grumpy :)
<Hwolf> Bendy? Bendy what?
<Kamion> don't ask
<azeem> hey, is there a way to test IRDA on the hoary LiveCD? Any apps installed/anything to activate?
<Hwolf> Treenaks: right.
<Hwolf> Kamion: Enlighten me.
<Kamion> Scott was trolling Mark and Mark took him seriously; a lesson for us all ;)
<Kamion> Badger
<Treenaks> LOL
<sivang> hehe
* Kamion takes noexec=off back out of the amd64 CD configuration
<sivang> Kamion: but really, how did scott think of a Bendy ?
<Kamion> Scott has a twisted mind
<Hwolf> Bendy Badger? Stylish. :-)
<Mithrandir> please stop it.
<Kaloz> :P
<Josephus> :D
<Hwolf> ;)
<Hwolf> Feature freeze in a few days?
<Kaloz> bendybunny :p eh :) 
* Kaloz hides
<Kamion> Hwolf: welcome to the Manic Coding Emporium
<Kamion> it's feature freeze! get your mad hacks in now!
<sivang> Hwolf: monday
<Kamion> Wednesday I think
<sivang> Kamion: oh ok, oops++
<Hwolf> sivang: That means no usplash; you just blew my weekend :-P
<sivang> Hwolf: wednesday as Kamion noted :)
<Kamion> the release schedule's confusing, but there's a bit at the top that says "Tasks listed for a given week are, in general, due on the Wednesday"
<sivang> Hwolf: doesn't it help?
<Kamion> I think sladen's still going for it but I don't know how he's doing
<Kamion> sladen: ?
<Hwolf> sivang: Only pretty artwork will help. Sorry
<sivang> Kamion: btw, thanks for mentioning me on the d-i changlog :) (a suprising way to find my name there)
<Kamion> heh, you're welcome
<Hwolf> Hoary is a lot more user-friendly compared to the warty I'm currently using, but besides the installer, boot is a major weak piont, imho
* Mithrandir thinks the installer is a strong point, not a weak point.
<Kamion> he did say "besides the installer"
<Mithrandir> oh, I misparsed
<azeem> congrats on the Hoary-LiveCD, btw. Great work.
<Hwolf> Mithrandir: It's straight forward, it works like a dream, but I pretty much dislike that you get 'booting into your ubuntu system' and then spend x hours watching -desktop being installed without a progress bar.
<Kamion> Hwolf: yeah, I really would like to fix that, but it requires implementing progress bars in perl debconf
<Kamion> which keeps slipping down my to-do list
<Mithrandir> Hwolf: for x == 0.5 or so? ;)
<Mithrandir> Kamion: that ought to be simple enough, or?
<Kamion> Mithrandir: it's not extraordinarily difficult, but I want to do it for all frontends which is a fair bit of API research
<Mithrandir> true.
<Mithrandir> I can imagine the "editor" frontend having some problems there.
<Mithrandir> and the http one
<Kamion> I actually implemented a little bit of the PROGRESS interface in debconf recently, just enough to allow it to passthrough to cdebconf
<Kamion> well, some of them would certainly have to ignore it, that goes without saying ...
<Kamion> I suppose I could do it for dialog and make the rest fail or something
<Kamion> or capb it :)
<Mithrandir> I think capb is the way to go, really.
<Kamion> guess so. I added progress to cdebconf's capb recently too.
<Kamion> and capb can be per-frontend ...
<Mithrandir> yup
<Mithrandir> MPE
<Kamion> MPE?
<Hwolf> Kamion: In the meantime, change the texts to mention that installation is not finished, but now progressing to the installing of -desktop
<sivang> Kamion: the new grub is your work ? :) 
<Kamion> sivang: yeah
<Kamion> Hwolf: I thought I already did that
<Kamion> _Description: First stage of installation complete
<Kamion>  The first stage of the installation process is complete. Your computer
<Kamion>  will now reboot, ask you a few remaining questions, and install more
<Kamion>  packages. Make sure to remove the installation media (CD-ROM,
<Kamion>  floppies), so that your system boots from the disk to which Ubuntu was
<Kamion>  installed.
<Kamion> since prebaseconfig 0.69ubuntu2, which was pre-warty
<Hwolf> Kamion: I must have completely missed that.
<Kamion> it's at the point when it ejects the CD
<sivang> Kamion: eh, a new upstream, nice
<Kamion> it does say "Rebooting into your new Ubuntu system", though, but I was reluctant to change too much because it kills translations
<Kamion> sivang: hm, no?
<Kamion> it was my patch for hardware you probably don't have unless you're on amd64 :)
<Hwolf> Kamion: Please do. :-S
<sivang> Kamion: ah ok , I thought I read on the changlog that's it's a new upstream :) nevermind
<Kamion> no, just "New" as in "new patch"
<sivang> Kamion: ok, cool, btw how is the weather in London today?
* Kamion digs out his old debconf progress diff
<Kamion> haven't been outside yet - looks like a fairish day for winter thoug
<Kamion> h
<Kamion> oh yes, I had trouble working out where to keep the fd for communication with whiptail while the gauge was being displayed, that was it
<thom> Kamion: you've moved to london now? ;-P
<Kamion> thom: not last I checked
<thom> (because it's grey and 'orrible, here ;-) )
<sivang> Kamion: Ah oops, I assumed you were in london like sladen is :)
<infinity> I've heard some pretty terrible things about London.
<infinity> Not the least of which is "thom's there"
<thom> it's a great city :P
<sivang> infinity: like what? is one of the best places to be I reckon
<infinity> Oh, and people say "reckon" a lot.  But I have that problem where I live now, too.
<sivang> pubs close around 11, peace and sound all day long :)
<sladen> it's not as crap as I was expecting it to be when I moved here ...alot of what goes on in this country goes on here
* sivang wishes to visit picadilli square (or whatever it's spelled)
<sivang> sladen: G'afternoon
<thom> picadilly, you were pretty close
<sladen> Kamion: no I don't know either, but we'll see
* infinity is happy his devel box came back to life today.
<sivang> infinity: where are you in?
<infinity> thom : Which means, expect a barrage of uploads tomorrow afternoovening.
<infinity> sivang : Cairns, QLD, Australia.
<thom> sladen: so how do we proceed with cpufreq? try to load what we think, then try speedstep-smi, then acpi?
<thom> infinity: when are y'all actually moving?
<sladen> thom: trying -smi is ''just going to work'' on more machines
<infinity> thom : We leave on the 15th or 16th, get there 4 or 5 days later.
<infinity> thom : So.. Uhh.. Friggin' soon.
<sivang> infinity: why are you moving?
<infinity> sivang : Greener grass.
<sladen> thom: I don't know what to do about the PIV machines without EST, p4_clockmod is supposed to be deprecated
<sivang> infinity: yay
<thom> sladen: nod
<sladen> thom: and I think the detection should be rewritten to check family/model/make and then fallback to the string to differentiate separate models
<thom> sladen: right, seems reasonable; should we change to trying -smi soon and then the rewrite can be a bit more opportunistic
<sladen> mjg59: some other distro (can't remember where I read the code), is writing a 'resume' line into the config during hibernate and only allow resume from that line  
<sladen> yup
<sivang> infinity: are you like moving to a more countrysideish place?
<sivang> (as opposed to urbanic and grey area)
<thom> sladen: i can get that done now, then
<Hwolf> sladen: Will we see usplash in hoary?
<sladen> Hwolf: how long is a piece of string.
<Hwolf> sladen: depends on how you cut it. 
<sladen> Hwolf: bingo
<Hwolf> *snif*
<sladen> Hwolf: at the very worst, you'll see it in an apt repositary you can apt-get
<Hwolf> sladen: You're my newest hero then.
<sivang> Hwolf: so it your weekend not ruined completely? ;)
<sivang> s/it/is/
<Hwolf> sivang: It is, but for other reasons
<sivang> Hwolf: ah ok :-/
<Hwolf> I spent weeks and long hours writing a business plan for a company that just decided yesterday to move all engineering and production to china. I can start from scratch, and have 10 days to do it if I want to make sure I get a grade for it.
<Hwolf> (studying business administration)
<tseng> sivang: eh?
<sivang> tseng: no more tomboy for me :(
<tseng> sivang: oh
<tseng> sivang: did you read the changelog?
<infinity> sivang : No, moving from a city of 250 thousand to a city of 3.5 million.
<tseng> sivang: im guessing you are trying to run `tomboy`, right?
<infinity> sivang : Which, for me, is a "grass is greener" thing. :)
<sivang> tseng: yes
<sivang> infinity: hehe
<tseng> sivang: well, two choices
<sivang> tseng: didn't read the changlog, let's check
<tseng> sivang: add the applet, or tomboy --tray-icon
<mjg59> sladen: Hrm. Any chance that you could find that?
<sivang> tseng: I do apt-listchanges on it and nothing comes out 
<sivang> tseng: ok, wow, it's now an applet? or just the command line changed?
<tseng> both
<tseng> theres still a tray icon with --tray-icon
<sivang> yay!
<sivang> tseng: it's coool
<sivang> all my notes are there! thanks tseng 
<tseng> np
* T-Bone curses cdimage.u.c for claiming that max rsync connx are reached...
<daniels> T-Bone: try checking if mirnyy.u.c works for cdimage rsyncing
<T-Bone> daniels: same error message
<T-Bone> i think i'll just dl the full ISO, it'll be as long as waiting for a rsync slot to open :P
<Mitario> hi everyone
<Kamion> sivang: apt-listchanges --all
<sivang> Kamion: k, thanks
<sivang> Kamion: eh, the joys of the changlogs :)
<tseng> ogra: ping
<sladen> mjg59: I can't find it from casual googling with  'grub patch resume alternative' alikes.  It was using two menu.lst's and mv'ing between them.  I suppose you could extend the idea, set the password to 'yes' and require them to type 'yes' to do anything but boot the first option
<Treenaks> mjg59: my laptop still cycles back into suspend on resume from suspend-to-RAM
<mjg59> Treenaks: We should have support for fixing that now
<mjg59> I don't know if thom has uploaded an acpi-support package that uses it, though
<Treenaks> mjg59: how do I check?
<thom> oh, to lock acpid? no, i've not done that yet
<mjg59> thom: If you could, that would be great
<mjg59> That's really something that should be pushed upstream, too
<thom> yeah, i intend to
<thom> and yes, intend to do that also
<sivang> hmm, lunch is calling, bbl
<mjg59> thom: Hm. Maybe we should only be doing the vbestate save on laptops.
<Mithrandir> Kamion: "MPE" = "My point exactly"
<thom> sladen: -smi fallback in
<Kamion> Mithrandir: ah, right
<Mithrandir> what's the magic invocation to show all the stuff one has installed from universe?
<thom> Mithrandir: http://people.ubuntu.com/~thom/lscomponent ; run as lscomponent universe
<thom> if it's buggy it's jdub's fault
* Mithrandir blames jdub preemptively
<daniels> boo jdub
<Mithrandir> it worked.
* Mithrandir stops blaming jdub
<Mithrandir> (for now)
<Kamion> mdz: current grub in unstable has fixes for ida/ataraid/cciss devices and added support for raid1; can I merge?
<ogra> tseng : pong
<ogra> mdz: pong
<ogra> morning everybody
<tseng> hi ogra 
<ogra> hi, whatsup ?
<tseng> i still didnt get a chance to send my key to mark, so no upload
<tseng> just noticed muine in hoary needs rebuild against libflac (again?)
<Kamion> the key would go to James, wouldn't it? unless you were already told otherwise, in which case ignore me
<tseng> yes, I was.
<Kamion> ok
<ogra> i thought that was already done....do you mean the mail on the -users list ?
<tseng> it needs to be notarized, which is its not done
<tseng> ogra: personal experience, i tired to install it, and it depended on libflac4. current is libflac6
<tseng> i dont see a recent -users mail with muine
<ogra> ah, ok
<ogra> subject: broken package
<tseng> i have a cdbs question as well
<ogra> very informative ;)O
<tseng> this is a tricky one
<tseng> muine 0.7.1 pre packages patch a file to install to /usr/share/dotnet
<tseng> 0.8.1 has an option to the make install, ${exec_prefix} that looks like it will do this for us
<daniels> so is /usr/share/dotnet actually the right path now?
<tseng> yes
<daniels> as opposed to /usr/lib/mono
<daniels> because they were /u/s/d, then /u/l/m, and ah we're bored now, back to /u/s/d
<daniels> not that I'm bitter
<tseng> yes.. its meant to take into account other interpretations apperantly
<tseng> such as pnet
<tseng> or whatever else crack smoking vm comes along
<[m0rph] > libsdl-sound1.2 also needs a rebuild for flac6
<tseng> but anyway, trying to find where cdbs actually calls make install
<tseng> so i can pass in the var
<tseng> best i see is:
<tseng>  include $(_cdbs_rules_path)/buildvars.mk$(_cdbs_makefile_suffix)
<daniels> /usr/share/cdbs/1/class/
<daniels> and either makefile.mk or autoconf.mk in there
<daniels> or maybe it's autotools.mk
<daniels> but they'll have a common-install-impl target
<tseng> hm so i can overload that
<tseng> or maybe setting DEB_MAKE_INSTALL_TARGET
<Kamion> tseng: notarised> oh yes, that was you
<tseng> yeah =/
<tseng> monday i hope
* Kamion is lost in a twisty maze of file descriptors, all alike
<Kamion> I need to sit down with pencil and paper here, which is just silly
<daniels> Kamion: d-i/casper/debconf?
<Kamion> daniels: debconf/whiptail
<daniels> Kamion: bongtasmic
<Kamion> cdebconf has it easy, it uses the newt library in-process
<daniels> heh
<Kamion> whereas debconf has to fork whiptail and then juggle desperately
<infinity> Kamion : You could just give joeyh your requirements and a pot of coffee, and have it done in the morning.
<infinity> Kamion : The man's a machine.
<Mithrandir> Kamion: wouldn't it be easier to have a libnewt-perl?
<infinity> There is a libnewt-perl...
<Kamion> Mithrandir: there already is one; I'm assuming there was a reason for not using it, like it was hopelessly broken or something
<infinity> The description claims it's "very useable".
<Kamion> well I'm not going to totally upend debconf when I don't have to
<mjg59> Hmm. The RTL8180 driver is now actually working for some people, impressively.
<sladen> Kamion: is there clean way to rename kernel-* or add a provides: to linux-* so that ex-Debian people don't keep finding the wrong packages
* zul thinks he needs a faster computer for kernel compiles
<lamont> sladen: the best answer is probably to drop the kernel-* packages (well, 2.6 that is..)
<mako> mdz: still need help with array 4 announcement.. i worked offline yesterday.. jane knew.. not sure if she got the message to you
<lamont> speaking of MTA's...  /me tries to remember which way we decided...  drop postfix from base after modifying base to behave in the absence of an MTA?
<dholbach> hai
<sivang> hey dholbach 
<dholbach> hi sivang! :-)
<wasabi> this evms stuff is unbelievable.
<wasabi> i am tempted to make / a evms volume...
<wasabi> wonder what the potential to do that automatically in ubuntu is. it kind of solves the drive order problem.
<sivang> wasabi: it allows so many things...I was amazed to see it, and it has complete backward compatibility with lvms
<sivang> wasabi: meaning you can leave your volumes as they were and evms would use them no prob
<wasabi> yeah it seems that doing that is better
<wasabi> using lvm as the disk linker
<sivang> I am using everything bu /boot under lvms on the laptop, should switch to evms sometime
<wasabi> I'm thinking that if hte Ubuntu initrd has evms support... then I should be able to pass root=/dev/evms/root to the kernel.
<wasabi> does ubuntu's initrd support it?
<wasabi> See, this solves my one big problem... I can't hot swap my sata drives, because they make linux reorder sda to sdb, etc... causing grub to not boot and fstab to be inaccurate.
<sivang> I am using lvms on the lappi, and /boot is the only partiton not under lvm, so at least for lvm it has?
<wasabi> seems so.
<sivang> ah well, go ahead and test it on some non important data :)
<wasabi> heh
<Treenaks> sivang: no, you test with real important data
<Treenaks> sivang: that way you can blame the developers
<sivang> Treenaks: hehe, I always do, but I reckon wasabi has much more important data then I have on my syste :)
<wasabi> sivang: to auto mount an evms vol, you just plug the evms path into fstab right?
<wasabi> I have been moving 600GB of anime back and forth between hd's for two days, reformatting ubuntu, and setting up evms.
<sivang> wasabi: I am not sure, just read a couple of bits about it , using lvm on the laptop, not evms.
<wasabi> ahh.
<wasabi> did you see evms?
<wasabi> it's even better. ;0
<sivang> wasabi: I read about it sometime ago, after mdz noted to me it's apparent benefits.
<sivang> wasabi: I think on my lvm entries in the fstab on the laptop, it as simple IIRC
<wasabi> I'm seriously beginning to think that if Ubuntu set it up by default during an install, making / an evms vol, it would be Really Neat.
<sivang> well, this is rather a drastic decision to do, only time would tell :)
<sivang> (IMHO)
<mdz> mako: announcement went out, no problems
<mdz> Kamion: sure
<sivang> seb128_: ping
<seb128_> sivang: pong ?
<sivang> seb128_: hi :) just wanted to know, if I want to modifiy some of the gtk+ code, I need to open the tarballs under the gtk+2.0-2.6.2/upstream dir of the source pkg and work on them? how would I go about modifying this pkg?
<dholbach> sivang: i guess you have to  tar xfz  it, modify it, make a patch, put that patch in debian/patches as 99_sivangs_special_something.patch :-)
<seb128_> right, that's it
<sivang> seb128: ah ok, simple patch system ? (cdbs)
<sivang> dholbach: thanks
<dholbach> sivang: de rien :-)
<Burgundavia_> Hello all
<sivang> dholbach: merci beaucoup
<dholbach> :-)
<dholbach> sivang: we'll take french lessons together... maybe seb128 will volunteer for it ;-)
<sivang> sure, and you should do germen lessons :)
* dholbach wipes out the blackboard for Monsieur seb128. :-)
<wasabi> Oye. The kernel instalsl break horribly when using EVMS
<wasabi> Failed to create initrd image.
<mdz> wasabi: -ENOTENOUGHINFO
<wasabi> I'm looking at it trying to get info
<wasabi> Okay... during postinst, it does some setting up stuff. Spits out a ton of errors related to LVM, and says two of my volumes have duplicate PV identifiers... which I suspose is true.
<wasabi> One of my LVM disks is a md raid 1 disk. =)
<wasabi> Comprised of two seperate physical disks. I suspect it's reading the PV id from each and getting confused.
<wasabi> Would you like the output?
<wasabi> Guess i'll make a bug report.
<bluefoxicy> some people really can't boot from cd and need a floppy
<bluefoxicy> any ideas?
<bluefoxicy> i'm thinking you could put grub on a floppy image
<bluefoxicy> with chainloader (cd)+1
<bluefoxicy> to boot from cd
<azeem> bluefoxicy: that's not specific to Ubuntu though, is it?
<bluefoxicy> azeem:  this can't get woody or sarge installed, and can't even try ubuntu because the machine is 10 years old and doesn't do boot from cd in the bios
<azeem> you can install sarge via floppies
<bluefoxicy> azeem:  but I think the grub idea is a good one, since it'd be more of a generic boot-from-cd disk, which means the problem only has to be solved once.  Then again, is there anything like that?
<bluefoxicy> azeem:  he has a boot disk but sarge won't work there either
<bluefoxicy> it broke
<azeem> what makes you think Ubuntu would work then?
<bluefoxicy> he's tried woody and sarge, but can't try ubuntu, because it can't be installed, because there's no boot from CD
* bluefoxicy shrugs
<bluefoxicy> nothing else's worked
<bluefoxicy> so why not :P
<bluefoxicy> anyway
<bluefoxicy> this is irrelavent
* bluefoxicy heads out
<sivang> dholbach: ok, but that's after I know my patch is good and working, how do I test build change by change?
<sivang> dholbach: like chanign a source tree before diffing with the orig to make the patch
<dholbach> sivang: what do you want to do? check if the build works before you try to patch?
<sivang> dholbach: yes, like change the package inline, without having to make a patch for every single attempt I make
<dholbach> erm... cant you remove the according patch from debian/patches?
<sivang> dholbach: what do you mean?
<dholbach> oh... now i see what you mean merging the diffs is a bit of a pain
<sivang> dholbach: yes, everytime I change some small bits :-)
<dholbach> you'll have to find a clever way of applying-and-removing-while-preparing-a-new-diff
<sivang> dholbach: I wish this package would use dpatch :)
<dholbach> since i never used  dbs , before, i'm not sure, if there's a cool tool
<sivang> dholbach: it's way cool to do stuff that way
<azeem> (you can use cdbs together with dpatch)
<sivang> dholbach: I just want an easy way to make modification, without _having_ to do them as patched everytime :) like, work on the source pkg, debuild from the same dir several time , when I reach the my desried results, then make diffs against the orig and create patches.
<sivang> azeem: I can imagine, however, this specific package doesn
<sivang> azeem: use dpatch, I suspect it uses the simple patch system.
<sivang> seb128: how do you apply all the patches in their order to get a sourcetree to do more work on when working on this package?
<seb128> start the build and ctrl-C ? :p
<robertj> I'm trying to test some changes I made to a package but the config script bombs when testing it by doing sh passwd.config reconfigure, is there a better way to test it?
<sivang> seb128: I thought there must be a way to do that more, hrm, elegantly ? :)
<sivang> err, my upgrade is stuck :-(
<sivang> does anybody know if setting up linux-kernel on lvm volumes should take, like, forever, on an inspiron machine ?
<sivang> ehh it's just continued..phew, that was a close one
<seb128> sivang: perhaps, but I'm not working on the computer atm and I don't want to search
<jdub> yo seb128 
<jdub> seb128: "ugh" to the industrial cursors/stock stuff
<sivang> seb128: ok
<robertj> hey jdub, do you have any hints on how to test the config portion of a package?
<robertj> I just get a bunch of debconf complaining about missing templates and the like
<jdub> not i, check the debian documentation
<Treenaks> why would logging out & back in fix themeing in firefox?
<dholbach> brb
<lamont> ../mantools/postlink: line 715: 24692 Segmentation fault      perl -e '
<lamont> bad perl
<sivang> ooouch
<lamont> well, it is 55988 bytes of file that says 'perl -e'
<sivang> buffer size exceeded?
<dholbach> unmounting my vfat-partition crashes my box... completely
<dholbach> and i thought it was a gparted-bug...
<YokoZar> When is Hoary universe going to get frozen?
<jdub> it's in upstream version freeze
<jdub> but we are more open to universe updates
<dholbach> jdub: this reminds me of g*mm *whistle silently*
<seb128> jdub: evening, yep ...
<bluefoxicy> .rhythmbox[10107] : segfault at 0000000000000000 rip 0000000000000000 rsp 0000007fbfffeb18 error 14
<bluefoxicy> so much for ogg vorbis
<bluefoxicy> actually no, other oggs play  o.o
<bluefoxicy> does anyone want this file?
<bluefoxicy> it's reproducibly killing rhythmbox on hoary as of 5 hours ago
<bluefoxicy> on standard ubuntu kernels (amd64-k8)
<dholbach> bluefoxicy: you could talk to the guys at   irc://irc.gnome.org/rhythmbox  about it
<bluefoxicy> sure, though they might not be able to reproduce it (everything kills rhythmbox on gentoo, and they can't reproduce that, the gstreamer guys say it's gentoo's fault)
* robertj gets ready to make his whining list
* robertj is burning Array-4 (finally)
* robertj will be back in an hour
<netdur> firefox (1.0 hoary) doesn't apear to render unicode well! I have the same site shown in both browsers (firefox 1.0 and mozilla 1.8, both character set to uft-8) while mozilla show it well, firefox doesn't, anyway, I'm not firefox (not stable enough) user so I don't need help, this is just to inform you!!!
<sivang> sladen: yay! cpu scaling works again :)
<sladen> sivang: btw, can you remind me the specs of your machine;  was it /not/ working because of a duff ACPI DSDT
<sivang> sladen: DSDT? duff? :)
<sivang> sladen: basically, dell inspiron 8200, 256MB ram, Brookdale 82845 chipset
<sivang> sladen: anything else?
<lamont> hrmpf.  page ranking fell to #3
<sladen> sivang: what's the CPU?
<sladen> lamont: Google?
<sivang> sladen: pentium mobile, pre centrino technology
<lamont> yeah - basketball and college football player beat me out
<sivang> sladen: the one that eats the hell out of you batter
<lamont> I need to have mako mention me in traffic a again
#ubuntu-devel 2005-02-17
<YokoZar> haggai: ping?
<sladen> sivang: grep name /proc/cpuinfo
<sivang> model name      : Mobile Intel(R) Pentium(R) 4 - M CPU 1.80GHz
<sladen> sivang: grep -c flags.*est /proc/cpuinfo
<sivang> 0
<pvh> Why is the resume= option needed for disksuspend not included in the menu.lst on laptops?
<mdz> pvh: https://bugzilla.ubuntu.com/show_bug.cgi?id=5230
<YokoZar> mdz: are you interested in signing my GPG key?
<sladen> pvh: if mjg59's patches went in, you should be able to do it by echo'ing > /proc/...something
<pvh> sladen: It's a bit messy at the moment, isn't it?
<dholbach> does anyone have an idea, how i could debug a umount-of-a-fat32-partition-that-completely-kills-the-system?
<pvh> sladen: Someone else was telling me to use /sys/power/state
<pvh> sladen: And some of the documentation talks about /proc/acpi/event
<dholbach> bye guys... i'm off to bed
<Mithrandir> mdz?
<sladen> pvh: (1) ACPI events (power-button-press).  (2) cause the system to enter the state (hibernate).  (3) onto the device selected (>/proc/power/resume)    Which bit do you feel is unneccessaryily messy?
<pvh> sladen: Mm, no it's not messy in that sense. I don't mean to insult.
<pvh> sladen: It's just that there are still lots of obsolete ways left in.
<pvh> sladen: I think that a little bit of Hoary targeted documentation would resolve the situation.
<sladen> pvh: I doubt anyone is insulted.  How do you feel it could be improved?
<pvh> sladen: Once I've figured all the steps out, I might be able to supply a first-pass at that.
<pvh> sladen: Unless there's already some good documentation out there that I've missed?
<pvh> sladen: The wiki stuff is targeted to 2.4 kernels.
<sladen> kinnison: your P4 appears to share the characteristics of sivangs;  does the -smi fallback fix^W work?
<bluefoxicy> anyone wanna show me a walkthrough for building an official amd64 generic here?
<bluefoxicy> uri or whatever
<bluefoxicy> I tried on my own but i wound up with a kernel package which didn't actually install anything in /boot
<bluefoxicy> (using make-kpkg)
<lamont> bluefoxicy: apt-get install linux-source-2.6.10; dpkg-buildpackage
<bluefoxicy> lamont:  nothing I have to touch around there?
<lamont> don't think so...
<bluefoxicy> i.e. to put out another release or another arch or such
<lamont> assuming the kernel you want to build is one of the flavors found in the archive, dpkg-buildpackage will build it...
<lamont> along with the others, mind you.
<bluefoxicy> I'm trying to gauge if I'd be able to maintain grsecurity sources for amd64
<bluefoxicy> I can patch the thing easy (2 misses, 1 is relavent 1 is just makefile EXTRAVERSION)
<bluefoxicy> err, *kernels
<bluefoxicy> pitti's got a few experimental ones up for x86
<bluefoxicy> but none for amd64
* bluefoxicy of course has an amd64 O:)
<AndyR> hi all
<bluefoxicy> until ubuntu *cough* actually picks up grsecurity (possible?  maybe, maybe not), I've got two choices: build my own directly (I can do that), or build my own packages (I can't do that).  The latter provides a better learning experience; I can build kernels by hand with my eyes closed.
<bluefoxicy> (hopefully so can everyone else here)
<jdub> bluefoxicy: building kernel packages is easy, see kernel-package
* bluefoxicy google kernel-package. . . and ubuntu. . . and metallica. . .
<sivang> I'm dead tired, good night freedom lovers! :)
<Mitario> hi everyone
<jdub> when using debmirror, will the target directory end up being $ROOT/{dists,pool}
<jdub> or have dists/pool in it
<jdub> directly
<jdub> n/m, appears to put {dists,pool} directly
* lamont heads to town
<sladen> wow, this looks *nice*:  http://www.ubuntu-fr.org/
<macewan> ubuntu frog?
<zul> crunchy frog
<lamont> sladen: looks very french. :-)
<macewan> rather elegant layout. easy on the eyes & pleasant.
<lamont> yes.  even with my poor-to-nonexistant french, it looks nice
<tseng> looks nice besides the nipples-of-doom shot
<wasabi> heh. somebody just gave me the crazy idea of putting .torrent files in apt
* infinity cleans up apache1.3 and is subsequently very frightened by fabbione...
<dholbach> morning
<dholbach> hmmm, i thought my unmount-vfat--system-crash was related to autofs and i solved it that way.... but unfortunately - it's still there - hmmmmmmmm
<sivang> morning all
<dholbach> hi sivang :-)
<sivang> dholbach: hey daniel
<dholbach> sivan, how are you?
<sabdfl> hi guys, what's our best answer for wifi network selection from the desktop?
<sabdfl> in hoary
<jdub> sabdfl: install netapplet
<jdub> sabdfl: it's not on-by-default yet
<sabdfl> jdub: is that what we plan to make on-by-default?
<jdub> for hoary, yeah
<jdub> it's only just been appletised
<sabdfl> cool, thanks
<dholbach> bye, i'm out... running
<sabdfl> elmo: good work on the universe / multiverse sync
<sivang> rehi sabdfl :)
<sabdfl> hey sivang
<dholbach> re
<jdub> hrm
<jdub> how do you get the installer stuff with debmirror?
<jdub> aha, figured it out
<jdub> sections should include main/debian-installer,restricted/debian-installer
<jdub> daniels: around?
<Treenaks> hm, tsclient displays a localized banner, using gtk_get_default_language() to get the locale
<Treenaks> but the banner contains text, and gtk_get_default_language() returns the wrong part of my locale for that (i.e. not LC_MESSAGES)
<Treenaks> Where's the bug? tsclient or gtk/pango?
<Treenaks> I'd say GTK (it returns LC_CTYPE, not LC_MESSAGES)..
<dholbach> re
<dholbach> would anyone sponsor me a bluefish-1.0 upload?
<jdub> daniels: http://www.cse.unsw.edu.au/~chak/linux/c400.html#xfree86
<amu> dholbach: url?
<dholbach> amu:    deb-src http://ubuntu.gplan.info hoary main    (although i should change main to universe or something) :-))
<mdz> morning
<sivang> morning mdz 
<fabbione> morning
<sivang> morning fabbione, how do you feel?
<fabbione> trashed
<fabbione> yesterday they managed to drag me out of the house with a really fancy excuse... and organized a surprise bachelor party
<Treenaks> what was the excuse? ;)
<fabbione> installing ubuntu sparc in a telco datacenter
<Treenaks> LOL
<fabbione> i couldn't resist the amount of nice hardware they put in the list
<Treenaks> jdub: a link from that page (http://linmodems.technion.ac.il/pctel-linux/welcome.html) would likely make my winmodem work :) thanks! :)
<Treenaks> (hm, no, 2.4 only)
<infinity> fabbione : That's some excuse. :)
<dholbach> fabbione: you have an idea, what could cause  umount -ing a vfat partition to kill the whole system? or how i could debug it?
<fabbione> dholbach: #5431
<dholbach> oh ok *has a look*
<dholbach> funnily enough, if i did it in the console and stopped gnome-related processes, i could umount it flawlessly
<dholbach> but both times (according to lsof) no processes had open files on it
<fabbione> dholbach: the "open files" are in the kernel
<fabbione> you don't see them in lsof
<dholbach> aha... ok 
<fabbione> mdz: confirmed.. it works perfectly with growisofs :-)
<mdz> fabbione: yes, someone should mail its author about the silly name
<fabbione> or we can just ln -sf growisofs irockondvds
<jdub> is growisofs generally better than cdrecord?
* fabbione still feels a lot of alchool flowing in his blood...
<fabbione> no correction..
* fabbione feels very few blood in his alchool stream
<jdub> aha
<jdub> bong
<jdub> Package: sl-modem-daemon
<jdub> Depends: libasound2 (>> 1.0.8), libc6 (>= 2.3.2.ds1-4), debconf, sl-modem-modules-new | sl-modem-source (>> 2.9.6-1) | kernel-image-2.6
<jdub> *kernel*-image
<Treenaks> jdub: scary
<sivang> Treenaks: that's a link to a webserver on my former uni :) how did you come by it?
* jdub goes to fix
<Treenaks> sivang: the page jdub pasted had a link to it :)
<sivang> Treenaks: ah cool. *searching the backlog*
<jdub> hrm
<Treenaks> slmodem is scary
<jdub> can you use globs/regexps in Depends package *names*?
<jdub> mdz, fabbione: ^
<Treenaks> jdub: linux-image-2.6.[0-9] + ? ;)
<fabbione> jdub: put down the pipe man...
<jdub> fabbione: i know :-)
<jdub> but
<mdz> jdub: BONG
<jdub> we don't have a metapackage that is cpu independent
<jdub> so i'm stuck depending on linux-image-386 and -686 and -k7 and -386-smp and -686-smp and -k7-smp and any future ones :)
<fabbione> hmm
<fabbione> Package: linux-image-2.6.10-3-386
<fabbione> Provides: linux-image, linux-image-2.6
<fabbione> that's all you need
<fabbione> and it's there already
<jdub> och
<jdub> good point
<jdub> thank you fabio
<jdub> it is not even late :)
<fabbione> so you can just Depends: linux-image-2.6 | linux-image-whatever-real-package
<jdub> do i have to | it with a real package?
<fabbione> yes
<fabbione> or the other way around
<fabbione> check with lintian
<infinity> The other way around.
<infinity> Though, it's pretty sick to be depeding on a kernel image at all.
<infinity> jdub : Why is that necessary?
<jdub> infinity: alsa driver in 2.6 instead of driver module provided
<infinity> Yeah, I read the package description.  I'm still not convinced it's necessary. :)
<infinity> Especially since "linux-image-2.6" could have anything builtin, including no sound support.
<infinity> ARGH.
<infinity> How does one stop CVS from doing keyword expansion?
<infinity> It just destroyed a massive patch.
<Treenaks> infinity: I think it was something with -k and cvs admin
<Treenaks> 1 mom
<Treenaks> +
<Treenaks> infinity: https://www.cvshome.org/docs/manual/cvs-1.11.19/cvs_12.html#SEC97
<Treenaks> https://www.cvshome.org/docs/manual/cvs-1.11.19/cvs_12.html#SEC100 even
<infinity> Thanks.
<infinity> Oh, thank god it's recoverable.  I didn't want to redo that patch..
<dholbach> hi seb128
<seb128> morning
<sivang> seb128: morning
* sivang is away for about an hour, be back soon
<dholbach> jdub, seb128: gtkmm2.4-2.5.5 just hit debian experimental :-D
<seb128> yeah, I know
<seb128> jdub: what's going on with beagle ?
<jdub> got a prelim package without any depends :)
<jdub> haven't spent much time on it since last weekend
<seb128> k
<seb128> jdub: and about *mm, is that ok to sync 2.5.n ?
<mvo_> jdub: when is feature freeze? at monday or after monday :) ?
<jdub> how much stuff will that break in universe? :)
<jdub> mvo_: wednesday
<mvo_> jdub: ah, misread the schedule. thanks
<jdub> yes, current format makes that confusing
<seb128> jdub: gtkmm is in main, but since that's a GNOME stuff, for the freeze ... the breaking part is probably not an issue, the is not a ton of rdepends and dholbach has runned a part of them and that's fine
<jdub> seb128: ok
<jdub> seb128: (i am being abruti about C++ :-)
<seb128> jdub: should I mail matt/you about this ?
<seb128> ah ah
<jdub> nah, go ahead
<seb128> k, thanks
<dholbach> jdub: what does abruti mean? :-)
<jdub> dholbach: it's french for meathead.
<jdub> kind of
<jdub> seb was being very mean to me one day ;)
<dholbach> abruti... sounds... erm ... nice :-)
* seb128 hides :p
<jdub> oh man
<jdub> hrm
<amu> jdub: any new from Luis? he wanted to gimme some docs/artwork about gnome, looks like he's lost in bermuda ;) 
<amu> s/new/news
<jdub> i'll nudge him
<jdub> interesting
<jdub> anything playing through alsa plays fast
<LarryT> hi people :)
<jdub> unless it's playing through dmix
<jdub> then it plays at normal speed
<Kamion> jdub: depending on kernel images at all has always generally been considered BONG, except for kernel modules specifically compiled against a particular module ABI
<jdub> Kamion: yeah? hmm.
<jdub> Kamion: should i just take out all the kernel related depends?
<jdub> seems like a very bong package
<Kamion> I would, but I haven't looked at the package :-)
<jdub> that said, everything but the driver seems to be Free
<jdub> a no advertising clause is not considered non-free is it?
<amu> hmm daily-live has still keyboard problems, no @ and | if i choose german locale, xorg say "UNKOWN"      
<LarryT> someone could tell me if gparted will be on ubuntu , pleae ? :)
<Kamion> LarryT: nobody's been working on it in Ubuntu. However, since Debian recently did a big parted upgrade, it might come into Debian soon; if so, there would be a case for us syncing it into universe.
<LarryT> may be i am not on the right channel ? ...
<amu> jdub: thx
<dholbach> LarryT: i'm working on it
<LarryT> there you're back :)
<Kamion> ah, I wasn't aware dholbach had been doing stuff
<dholbach> LarryT: but i want people to test it a bit, before it gets included and people jump down my throat because their partition was eaten :-)
<amu> Kamion: tried remaster the ppc, as you suggested with a hfs.map from CVS, CD still does not boot :(      
<Kamion> I'll have to try the instructions out myself later
<amu> Kamion: thx
<dholbach> but LarryT was right... gparted on the liveCD would be *NICE*
<dholbach> so i probably should start a big call on package testing :-)
<lifeless> can we get fuse in the official kernels ?
<lifeless> or at least a built module ?
* Kamion discovers another d'oh in timezone configuration, and fixes
<sladen> hostap would be groovy too;  then I could have wifi back on this laptop
<sivang> I'm back
<jdub> ahr! all my sound is playing fast
* Mithrandir kicks python
* sivang goes to grab some coffe
* Mithrandir kicks python some more
<Mithrandir> does python -c  'import locale; locale.setlocale(locale.LC_ALL, ""); print locale.getlocale()' do anything useful for any of you?
<Mithrandir> (generating a backtrace is not considered useful.)
<sivang> ('en_US', 'utf')
<Mithrandir> bah, stupid python.
<sivang> this is my default one, should I list me all the ones I have?
<Mithrandir> no, no need.
<mvo_> Mithrandir: 'C'
<Mithrandir> I found out what the problem is, and it's that python is dog stupid, having a hard-coded list of locales.
<sivang> bah
<daniels> jdub: solved problem; the video RAM hack has been in for ages so it will give you however much you ask for, and we have DRM too
<jdub> daniels: didn't seem to work on avdd's
<jdub> daniels: btw, i noticed that neither my laptop nor his loaded the appropriate drm kernel module
<jdub> mine has never loaded it, it seems
<daniels> i915?
<daniels> should get loaded when needed
<daniels> hoary-only, btw
<jdub> his is an i830, mine's an i855
<jdub> the Device>VideoRam setting didn't work
<daniels> bongtasmic
<daniels> using hoary?
<jdub> but he got this awesome letterbox video mode
<jdub> yeah
<daniels> hmmmmm
<jdub> he'll be over on wednesday, and possibly here earlier
<daniels> haven't heard any other reports of that
<daniels> and, I mean, I have an i855 ;)
<jdub> does yours always load the i830 module?
<amu> *hpf* shit, uploaded a source-packaged to debian 
<mjg59> jdub: For 855, the  correct module is i915
<jdub> (does it always unload it when X quits?)
<mjg59> With Xorg
<mjg59> For 830 as well, come to think of it
<jdub> oh
<jdub> right, xorg change
<jdub> i see
<daniels> jdub: mine always uses i915
<daniels> jdub: and nah, it won't unload it
<daniels> only load
<jdub> ok, he must have i915 going
<amu> elmo: ping
<bob2> daniels: did you see the vberestore thread on lkml?
<aj> elmo/lamont/anyone: ping? :)
<daniels> bob2: nope
<daniels> don't read lkml
<bob2> ah
<amu> daniels: i've still trouble with the liveCD, german keyboard, no @ and | is possible   
<daniels> amu: sounds like you have pc104 instead of pc104
<daniels> er, instead of pc105
<daniels> bob2: when was it?
<amu> xorg.config say 105
<daniels> amu: really?
<amu> yep
<azeem> same here, pc105
<daniels> bob2: ah, got it
<bob2> daniels: hrm, yesterday I think
<bob2> ah
<bob2> dunno if it's got anything interesting, but it seemed like you might be able to fob some stuff off to the kernel now ;)
<mjg59> bob2: Not as yet, sadly
<bob2> dang
* sivang is stunned at the looks of the new gimp "about" box
<amu> daniels: XkbLayout says "UNKNOWN" 
<daniels> amu: ?!?
<daniels> is the debconf priority at that stage high, or critical?
<daniels> i suspect we need to bump the question to critical if it's unknown
<daniels> either that, or default to us/pc105 and hope for the best :\
<daniels> anyway, I need to sleep.  'night all.
<sivang>  night daniels 
<daniels> amu: what language/location did you select?
<amu> daniels: ..on a booted liveCD, i must check the debconf prio ..    
<amu> daniels: german/german
<daniels> amu: ok, i'll check it out tomorrow or tuesday
<amu> daniels: ok, just let me know, if you need me to test something   
<daniels> thanks dude, will do
<amu> daniels: thx2 and sleep well 
<lamont> aj: sup?
<aj> lamont: irc.parisc isn't
<lamont> aj: seems to be working for me... - see other window
<sivang> Mithrandir: what are you using for your python hacking as in an IDE? vim/emacs/other? :)
<Mithrandir> emacs
<sivang> Mithrandir: (I am looking for something with object insight)
<sivang> Mithrandir: cool, could you email me the python highlight parts of the config file? or is it some kind of a pluging that I have to install?
<sivang> Mithrandir: (the one that tells which methods are available when issuing the dot :-)
<Mithrandir> no idea, I just browse the docs with firefox.
<infinity> object insight.  Bah.
<infinity> That's crazy talk.
<infinity> (but if you find a text-mode editor that does it well, tell me what it was?)
<Mithrandir> it's hard to do with python, since it's so dynamic.
<sivang> infinity: hehe
<sivang> Mithrandir: how do you enable the highlighting in emacs for python (it works quite well for me on C and Perl)
<Duck_busy> anyone working at the python 2.4 transition ?
<Mithrandir> sivang: python-mode, possibly?  Also  (global-font-lock-mode t)
<Mithrandir> in .emacs
<sivang> Mithrandir: how do I enable it? (it's a major or minor mode_
<sivang> )
<infinity> Mithrandir : <shrug>... If visual studio can manage object insight in their crappy text editors, I'm sure some enterprising free software developer can make a text mode editor not suck at it.
<sivang> infinity: we should try do something up, how hard can it be ? ;-) <hides>
<Mithrandir> infinity: it's a lot easier to do in, say C++ than python.
<infinity> I don't know about "hard".. But it'd be difficult to do it efficiently.
<infinity> Visual Studio cheats by making you tell it ahead of time what you may or may not be linking to.
<infinity> The "right" way would be to parse the source and determine what's being loaded, what it does, and how it's being used.  Which sounds.  Painfully inefficient.
<sivang> infinity: right
<sivang> :-/
<infinity> Maybe I should extend ae to be the ultimate python editor. :)
<sivang> infinity: ae?
* sivang apt-cache searches
<infinity> sivang : My tiny editor of choice, cause I'm weird.
<infinity> sivang : It was removed before woody.  Remind me to upload it before Sarge (and get it in Hoary universe.. Hrm.. I have how many days?)
<sivang> infinity: till wedensday
<sivang> ah, my crappie spelling...
<infinity> Anyhow.  It's tiny.  It's featureless.  It's be a great base for adding worthless features like this, cause I wouldn't be stuck trying to slot it into the already-determined frameworks of vim and emacs.
<sivang> infinity: right, what is it written in?
<infinity> C.
<sivang> infinity: superb :)
<Mithrandir> infinity: you are _sick_
<sivang> Mithrandir: LOLs
<sivang> how it seems to me that all of the nice features an object has in python, would make it ideal to write such an editor in python , no? (let's not talk about the efficiency for the moment)
<Mithrandir> sivang: have you ever used the monstrosity that is ae?
<sivang> Mithrandir: I don't think so, does it follow vim/pico/nano/emacs bindings?
<Mithrandir> well, you'd need to know the type of an object to introspect it.
<Mithrandir> actually, you need the object itself.
<sivang> Mithrandir: eh right..which mean instantiating it?
<Mithrandir> you can't just do that.  Imagine a method foo(self, bar); how are you going to introspect on bar?
<sivang> hrm right....:-/
<Mithrandir> even introspecting on self can be hard enough, since something might have added properties to self which you use.
<Mithrandir> not a good coding style, I agree, but very much possible.
<infinity> Mithrandir : Oh, it's not that bad. :)
<infinity> sivang : Keybindings are completely configurable, though it ships with some defaults people might be comfy with.  Does modal and modeless, etc.
<infinity> Mithrandir : Doing it in a foolproof manner might be tough, but getting it "close enough" mightn't be too hard.
<sivang> infinity: maybe to mere ease off the reference searching task...
<Mithrandir> infinity: how would you introspect at bar above, then?  Analyze the call graph?
<infinity> I could always embed python and use it to figure itself out...
<sivang> infinity: is there a way to embed python in a python script?
<infinity> Maybe.  I certainly hope not.
<infinity> I suppose you could write a python python library that linked to libpython, but.  Uhm.  Why?
<sivang> yes, that sounds, a bit how to say? strange?
<Mithrandir> lamont: cyrus-sasl seems to be missing on amd64
<Mithrandir> sivang: in general, for my emacs stuff just look at http://err.no/dotfiles/emacs
<sivang> Mithrandir: thanks, this is a domain of yours?
<Mithrandir> yes
<sivang> wow :)
<lupus_> seb128, can you update libdbus-cil for the new mono
<seb128> why me ?
<seb128> ask to one of the guys who work on it rather
<tseng> lupus_: whats wrong with it
<seb128> ie tseng :)
<lupus_> dpkg: error processing /var/cache/apt/archives/mono-assemblies-base_1.0.5-2_all.deb (--unpack):
<lupus_>  trying to overwrite `/usr/lib/mono', which is also in package libdbus-cil
<lupus_> Errors were encountered while processing:
<tseng> oh like that you mean
<seb128> oh, there is a bug in bugzilla about it
<tseng> has nothing to do with the "new mono" really.
<lupus_> true
<lupus_> let's say the new mono package :)
<tseng> for now you can dpkg -i --force-overwrite /var/cache/apt/archives/mono-assemblies-base_1.0.5-2_all.deb
<lupus_> lets 
<tseng> and CC yourself on the bug.
<lupus_> k
<lupus_> thx
<seb128> tseng: do you know if somebody has planned to update f-spot ?
<tseng> i do not
<seb128> k
<tseng> havent met the maintainer yet, and i cant get on the pkg-mono list
<tseng> as of yesterday
<seb128> k
<seb128> I'll ping the maintainer on the debian side first :)
<tseng> alright.
<sivang> seb128: do you know if there was any decisoin about removing the change UID field in users-admin "advanced" tab? There's a major bug report about this.
<tseng> yay, got on the list now
<seb128> sivang: I know, the bug is assigned to me :p
<tseng> someone fixed mailman
<seb128> sivang: I think we should just mask it from the UI
<sivang> seb128: ok, that would be a very trivial patch to do, using glad etc, would you like me to do it and make a new pkg for you to review?
<sivang> seb128: (i.e. a change only to the interface file)
<seb128> yeah, that's probably a few lines changes
<seb128> if you want to do it you're welcome
<sivang> seb128: ok
<sivang> seb128: tnx :)
<seb128> thank you
<T-Bone> Kamion: ?
<Kamion> T-Bone: ?
<Kamion> (here for about five minutes)
<T-Bone> Kamion: did you change something to d-i lately?
<T-Bone> yesterday's iso doesn't detect my CDrom drive anymore on ia64
<Kamion> T-Bone: all my changes are mailed to hoary-changes, to which I'd expect developers to be subscribed to find out what's going on :)
<Kamion> T-Bone: nothing springs to mind
<T-Bone> i'm not subscribed to hoary-changes
<T-Bone> i wonder what's going on. kernel modules seem properly loaded
<Kamion> step through cdrom-detect's postinst I guess
<T-Bone> Kamion: it's worth than that
<T-Bone> off hand it looks like the kernel is fucked up
<T-Bone> all ide modules are loaded, but it doesn't see anything on the ide bus
<T-Bone> ok the kernel is fucked up
<T-Bone> /proc/interrupts is mostly empty. The only thing working in USB!
<Kamion> hmph, when my fiancee logs out of GNOME, a bunch of processes keep running, so she can't log in properly the second time round
<Kamion> reproducible with a freshly created test user
<sivang> Kamion: last upgrade?
<Kamion> sivang: since a while, I think
<ZorroBytes> Hi, what's the status of Java for ubuntu - does the license for java prevent it being bundled as an install? It comes with Suse 9.2 Pro default isntall
<sivang> Kamion: I'm upgrading to see if it happens here
<Kamion> most of them go away if I add the user to the audio group; with a user that I just created with 'adduser', the panel keeps running
<sivang> Kamion: adduser doesn't apply all the needed groups I think, try to create a user in users-admin? 
<Kamion> ZorroBytes: AIUI, main problem is that if we ship Sun Java, we can't ship any other Java
<Kamion> sivang: oh I realise that pointy-clicky tools will add more groups and I've done that now by hand; however things should not break if users aren't in the groups they want
<ZorroBytes> Kamion, good point, but in reality (I'm a java developer) it's the sun one that I install first off. Then if I want another version, say IBM's, I go get that myself.
<Kamion> ZorroBytes: sadly, legal issues are even more real. :-)
<ZorroBytes> but for the normal joe user out there, having sun installed as default wouldn't be too much of a problem?
<Kamion> ZorroBytes: there's lots of stuff on the wiki though and jbailey is working on it
<ZorroBytes> url?
<Kamion> search for "Java"
<ZorroBytes> ta.
<Kamion> www.ubuntulinux.org/wiki/
<Kamion> no, we're not going to install Sun Java by default, sorry
* T-Bone has NFC what's happening, gives up
<ZorroBytes> Got the page.
<Kamion> there are a couple, there's JavaIntegration
<ZorroBytes> that's the one I'm looking at at the moment :)
<Kamion> anyway it's a long time since I used Java at all, so I'll bow out of the conversation now
<ZorroBytes> ta for the info :)
<Josephus> was there any change in gdm lately? I rebooted, and now gdm could not write my x auth file
<Treenaks> Josephus: did you run some X program as root?
<Josephus> possible yes
<Treenaks> Josephus: that could be the problem then.. and don't run X programs as root :)
<Josephus> ok i won't, but how can i get my X back? :)
<Treenaks> remove .Xauthority from your ~, and this is really a #ubuntu question
<Josephus> Treenaks: i thought it was because of some update
<Josephus> But default cursor change was because today's update, as it was mentioned on ubuntu-devel list
<sivang> Kamion: right
<sivang> Kamion: well, upgraded I'll check around if it happens here
<mxpxpod> Josephus: are they going to change back to the old default cursor?
<sivang> Kamion: hrm, I can confirm that :-/
<sivang> Kamion: only I couldn't even logout, but didn't any problem logging in
<pitti> Good evening everybody
<sivang> godd evening pitti :)
<sivang> s/godd/good/
* netjoined: irc.freenode.net -> kornbluth.freenode.net
* smurfix sighs
<sivang> why smurfix ?
<smurfix> I can IRC from here. But for some reason, ssh is totally impossible.
<sivang> where are you at?
<sivang> (if I may ask)
<mdz> pitti: good evening
<pitti> Hi mdz
<mdz> pitti: do you have a reproducible test case for the udev bug?
<smurfix> Tegernsee. Alps. The phone works, normally, but packet data doesn't like me here.
* smurfix will complain to his service provider if they try to actually bill him for this atrocity
<pitti> mdz: no, I cannot reproduce it at all on my machines
<pitti> mdz: I tried to debug it on smurfix' machine, but did not come very far
<smurfix> pitti: feel free to try again there, if necessary.
<smurfix> I can also try to track it down -- next week, when I'm back home
<mdz> pitti: I can reproduce it here
<mdz> pitti: by uninstalling/installing hal
<mdz> pitti: do you know the cause of hal.hotplug[18165] : SEQNUM is not set
<mdz>  ?
<pitti> mdz: I tried that several times (un/reinstall, down- and upgrades)
<pitti> mdz: I don't know the cause
<pitti> mdz: something seems to induce hotplug events without sequence numbers (which should normally be there)
<pitti> but I have no idea what generates them
<mdz> pitti: it is the hal postinst
<mdz> the do_udev function
<pitti> aha
<mdz> that entire function should be replaced with a call to udevstart, I think
<pitti> but events without a sequence number should just be executed immediately
<pitti> so I don't see where there could be a feedback loop
<pitti> why udevstart?
<pitti> can udevstart be limited to block devices?
<mdz> no, i don't think so
<mdz> but why does it need to be?
<pitti> mdz: well, just to avoid some redundancy, I guess
<pitti> mdz: udevstart takes a considerable amount of time
<mdz> pitti: dpkg-reconfigure hal reproduces the problem for me
<mdz> pitti: modifying postinst to call udevstart fixes it
<pitti> mdz: does it help to replace do_udev by udevstart?
<pitti> ok
<pitti> great
<mdz> it is strange that the maintainer did this
<mdz> it is hal's own hotplug hook which fails if SEQNUM is not set
<mdz> I do not know what causes the loop, though
<mdz> pitti: I think that udev should have an update-udev script
<pitti> sjoerd: ^ any idea?
<mdz> pitti: so that packages which install a udev config file can call it, to have the changes effected immediately
<pitti> sjoerd: (about do_udev without sequence number)
<pitti> mdz: hmm, good idea
<pitti> mdz: however, what should this script do apart from udevstart?
<pitti> just wrap it, in case it changes in the future?
<sjoerd> pitti: shouldn't be a problem.. we can't fake sequence numbers from usersspace anyway
<pitti> sjoerd: <mdz> it is hal's own hotplug hook which fails if SEQNUM is not set
<pitti> sjoerd: maybe that is what is causing the feedback loop
<sjoerd> hrm.. is that run on an udevsend..
<sjoerd> oh.. does hoary have udev in hotplug mode ?
<pitti> sjoerd: I think so
<pitti> sjoerd: /etc/hotplug.d/default/10-udev.hotplug -> /sbin/udevsend
<sjoerd> that's the same as in debian
<mdz> pitti: yes, I think it would only call udevstart at this time
<sjoerd> anyway, there is no problem if the hal program fails there
<mdz> sjoerd: Ubuntu uses /sbin/udevsend as the hotplug helper
<sjoerd> mdz: ah, right, so your udevsend actually causes the hotplug scripts to be run
<sjoerd> which isn't the case in debian...
<mdz> correct
<mdz> I don't know why this results in a loop
<pitti> hal -> udevsend -> this causes a hotplug event -> calls udevsend again?
<sjoerd> the symlink pitti has is strange then ? 
<smurfix> Yeah, something like that seems to happen.
<mdz> no, the symlink is standard
<mdz> udev has some loop detection which should prevent that
<sjoerd> ah
<mdz> otherwise this would happen with every hotplug event
<pitti> smurfix: does replacing do_udev() with udevstart help for you, too?
<pitti> mdz: right, but maybe because it does not have a sequence number (no kernel event), the loop detection fails?
<smurfix> pitti: No idea at the moment
<mdz> pitti: it's possible; I don't know how the loop detection works
<pitti> mdz: it might rely on the same sequence number
<sjoerd> guess there is no, way to tell udev to just recheck the permissions and naming and not call the hotplug scripts..
<pitti> mdz: the only odd thing is, why I can't reproduce it
<mdz>                 /* prevent loops in the scripts we execute */
<mdz>                 if (strncmp(key, "UDEVD_EVENT=", 12) == 0) {
<mdz>                         dbg("seems that the event source is not the kernel, just exit");
<mdz>                         goto exit;
<mdz>                 }
<mdz> the strange thing is, if I run the do_udev function from a shell, it doesn't cause a problem for me
<pitti> mdz: I pinged Md in #d-devel, I will ask him for update-udev
<mdz> but it does when run from the postinst
<mdz> it seems like a race
<pitti> mdz: in #d-devel
<mdz> perhaps related to the fact that it starts many udevsend processes in the background, and then restarts dbus
<mdz> pitti: ok
<mdz> why does it run them in the background, anyway?
<sjoerd> no good reason that i remember
<mdz> hmm, I can't reproduce anymore
<mdz> after undoing my workaround
<pitti> Heisenbug...
<jdub> http://bugzilla.ubuntu.com/show_bug.cgi?id=4271
<jdub> ^ i've been pinged about this a couple of times now
<mdz> jdub: ...
<mdz> jdub: it doesn't happen to me, so if you can reproduce it, you're in the best position to debug it
<pitti> mdz: according to Md, running udevstart might have unintended side effects, so we should not do that in a postisnt
<mdz> <Md> currently your best option is running udevstart
<jdub> mdz: i can't, have never used en_US
<mdz> I certainly do
<mdz> and if it were broken, I would have noticed and fixed it before Warty released
<pitti> mdz: okay, I'll modify hal to use udevstart for now
<pitti> mdz: after Md finds a better solution for udevstart, we can switch over to update-udev
<mdz> pitti: or can we disable that code altogether?
<pitti> mdz: well, it would cause hal not being able to read CD-ROMs etc.
<pitti> mdz: wrong, not CD-ROms
<pitti> mdz: but already existing USB devices
<mdz> why?
<pitti> mdz: hal isntalls udev rules to change group disk to group hal for USB devices
<pitti> mdz: s/USB/removable/
<pitti> mdz: so hal does not need to run in group disk
<mdz> can we not do that in the udev package, instead of hal?
<mdz> (using a different group)
<pitti> mdz: so it can mess with removable devices, but not with hard disk ones
<pitti> mdz: in the very first packages we indeed did this in udev proper
<pitti> mdz: but after some discussion this was moved  to hal, by installign an udev rules script
<mdz> I think that udev is the right place
<mdz> removable devices should have different permissions regardless of whether hal is installed
<pitti> mdz: to get rid of do_udev(), we need to move /etc/udev/rules.d/z_hal-plugdev.rules from hal to udev
<pitti> mdz: that's easy to achieve
<jdub> 08:24 < luis> jdub: 'install hoary CDs, choose en_US as locale'
<jdub> 08:24 < luis> jdub: 'use liveCDs, choose en_US as locale'
<jdub> 08:25  * luis is booting a liveCD at this very moment, will test again
<mdz> changing permissions of devices based on whether a certain package is installed, seems fairly evil
<mdz> jdub: seriously, I do that about 20 times per week, easily
<pitti> mdz: okay, then I do that
<jdub> mdz: i don't doubt you
<jdub> mdz: just relaying
<mdz> jdub: in which program is he seeing the problem exhibited?
<jdub> gnome stuff
<jdub> as noted in the bug
<pitti> sjoerd: do you think this can be done in Debian, too? (setting device permissions in udev instead of hal)
<mdz> I don't know which gnome stuff has different strings for en_GB vs. en_US
<jdub> hrm, now that i look at /etc/environment on my machine, i get:
<jdub> LANGUAGE="en_AU:en_US:en_GB:en"
<jdub> and i totally shouldn't have en_US before en_GB ;)
<jdub> mdz: nautilus 'wastebasket'
<sjoerd> pitti: you should discuss that with md.. 
<seb128_> you guys should all use fr_FR :p
<sjoerd> pitti: but i don't think there is a generic solution and this one is basically temporary for hal 0.4.x..
<mdz> jdub: Trash here
<mdz> jdub: just tested with an array-4 live CD
<Hwolf> Would it be possible to mark Openoffice.org2 as a subsitute for OO01?
<pitti> mdz: hmm, but putting removable devices into the hal group even if hal is not installed seems a bit weird, too
<pitti> mdz: we could revert the group back to plugdev
<pitti> mdz: however, that would mean that normal users can repartition/reformat removable media
<pitti> mdz: i. e. malicious software could circumvent permissions on USB hard disks
<sivang> seb128_: hehe
<kent> hmm, mono-assemblies-base is giving me problems. Can i solve it by hand, or will it be solved automatic with a future update? i cant seem to be able to remove the conflicting packages, it always wants to do apt-get -f install, but that one dont work, since its a conflict. 
<seiya> hi guys
<mdz> pitti: I can't think of a realistic attack scenario
* ..[topic/#ubuntu-devel:mdz] : Ubuntu development channel | use #ubuntu for support and general discussion | http://www.ubuntulinux.org/wiki/DeveloperResources | http://www.ubuntulinux.org/wiki/HoaryGoals
<seiya> do you know anything about website contest?
<pitti> mdz: as I said, normal users can circumvent permissions on USB hard disks
<pitti> mdz: the "users" in the sense of a human being can of course do this anyway
<pitti> mdz: (by moving it to another computer)
<pitti> mdz: but the user processes shouldn't
<Hwolf> Guys: With my latest upgrade I lost the ubuntu-themed mouse pionters. Which package is responsible for those?
<mdz> Hwolf: https://bugzilla.ubuntu.com/show_bug.cgi?id=6172
<Hwolf> mdz, ok, couldn't find it.
<Hwolf> btw, am I the only one who thinks a filled trash-applet looks like a clipboard?
<tseng> yes
* Hwolf whiches he could use hoary with warty theme, atm. :-S
<Hwolf> -c +s
<seiya> jdub: are you going to show us projects submitted to ubuntu website contest?
<bluefoxicy> update-notifier has been insisting that there are 7 updates available for the past 7 hours now
<bluefoxicy> after installing them
<geppy> The gstreamer-jack package is broken.  Is there anything that I can do to fix it?
<tseng> geppy: how about gstreamer0.8-jack ?
<tseng> gstreamer-* is 0.6, pretty old
<geppy> tseng:  I have 0.8-jack
<tseng> is that which is broken?
<geppy> tseng:  In my experience, they've both been broken.
<mdz> bluefoxicy: thanks for testing it; feel free to add your comments to the bugs already open about such issues
<trulux> hi
<jdub> geppy: probably worth talking to gstreamer upstream about it, more work has been done on the jack plugin since last release
<geppy> jdub: Alright, thanks.
<bluefoxicy> mdz:  right now I'm more interested in #5779, which now has a patch to correct the problem.  The patch didn't pop up till about 2 days ago so *shrug* it hasn't reached the maintainers.  No big deal, I'm too busy playing dragon warrior to care :)
<bluefoxicy> mdz:  the update notifier bug seems to be #6071, so it's known.  *nod*
<seiya_> jdub: hi
* bluefoxicy gets tired of waiting for things to load when there's images around, i.e. bugtraq.
* bluefoxicy hijacks HTTP and sends it to squid
<trulux> mdz: I've just came back and read the message on features freeze
<trulux> mdz: is there anything I could do for getting some new SELinux stuff on Hoary before it gets freezed?
<trulux> at least bringing updates to the packages
<robertj> hey mdz, I've been making an effort to get my act together and actually learn enough to provide a patch to create an admin group for sudoers and have made some progress but am having difficulty testing my changes
<robertj> mdz: sudoers is fine but the passwd package does its action during config and it's already configured...
<robertj> running sh passwd.config throws up errors about templates and the like so I assume it's not something your supposed to do
<bluefoxicy> o.o
<bluefoxicy> what group does Squid run as
<bluefoxicy> I need it running in its own group
<bluefoxicy> ahh, cache_effective_group
* sivang is going to get some sleep
<sivang> Night everybody
<robertj> should I take this one to d-d?
<robertj> are they still pretty hospitable ;)
<Duck_busy> sjoerd: coin ?
<sjoerd> Duck_busy: pong
<Duck_busy> sjoerd: :-)
<Duck_busy> sjoerd: i want to talk about the python transition in hoary
* sjoerd has no clue about that
<Duck_busy> people r complaining the depends r wrong
<Duck_busy> because debian pkg depends on python 2.3 and ubuntu now uses 2.4
<Duck_busy> do you plan some mass rebuilding ?
<sjoerd> Duck_busy: you need to ask the ubuntu people about this, not me
<Duck_busy> ho, i though you were one of them
<mdz> trulux: is there a list of what needs to be done?
<jdub> seiya_: yes, there will be a poll soon
<mdz> trulux: if you make a list in the wiki, we can discuss it, but it is very close to the freeze
<sjoerd> Duck_busy: nope ;)
<mdz> robertj: ubuntu-devel@lists is the place to discuss it
<Duck_busy> sjoerd: who could i ask ?
<robertj> mdz; thanks
<Duck_busy> there's not ubuntu tag on people
<Duck_busy> -t
<seiya_> jdub:oh, pool - ok, thx for answer
<sjoerd> Duck_busy: this channel seems like a nice target....
<jdub> seiya_: pool! :)
* jdub is in sweltering heat atm, so pool *is* cool :-)
<seiya_> jdub: and soon means few days?
<jdub> seiya_: oh, most likely less
<seiya_> jdub: he he right poll :)
<trulux> mdz: sure, I have a wiki page in hardened debian wiki, lemme dig for the link
<crimsun> Duck_busy: most of those packages need at least a bump in debian/control:Build-Depends. I believe mdz talked about this issue a couple weeks ago, though I don't have a log of it.
<Duck_busy> crimsun: yes, depends must be changed and build-depends too, is there a way to be sponsored as a debian maintainer, so as to have my pkg fixed quicker ?
<mdz> Duck_busy: yes, these packages will be fixed in due course
<crimsun> for my part, I've been sending diffs to MOTU for the python packages I've run across
<mdz> crimsun: that's great; if a few more people would do a few packages each, it would be done very quickly
<Duck_busy> mdz: can i come back here with fixed pkg to upload ? (understand ubuntu people r complaining to me and not you, as they see my name as the maintainer)
<jdub> oh man
<jdub> local lug list
<jdub> bunch of people being banged up the sh*tter by consolehelper
<jdub> most are completely confused
<jdub> (multiple users logging in, exclusive permissions, etc)
<jdub> one blames it entirely on gnome
<mdz> Duck_busy: yes, definitely
<jdub> eeeek
<Duck_busy> mdz: thanks
<Duck_busy> crimsun: thanks too
<mdz> Duck_busy: or you can mail ubuntu-devel@lists.ubuntu.com if no one is here to upload
<crimsun> Duck_busy: np
<Duck_busy> mdz: roger
<mdz> jdub: what is consolehelper?
#ubuntu-devel 2005-02-18
<trulux> mdz: http://wiki.debian-hardened.org/SELinux_on_Debian
<jdub> mdz: the red hat thing that switches permissions around so console users can do things like play sound
<mdz> jdub: so glad we didn't go that way
<jdub> indeed
<mdz> trulux: where is the patch for dpkg?
<jdub> but libuser would still be nice
<mdz> trulux: has it been reviewed by the dpkg maintainers?
<jdub> (i don't think we ever seriously discussed consolehelper)
<mdz> trulux: where are the patches for coreutils, fileutils and initscripts?
<mdz> we discussed pam_console
<mdz> and it sounds like consolehelper is the same idea
<jdub> pam_console uses consolehelper
<jdub> you can use pam_console without molesting everything on the system though ;)
<trulux> mdz: http://www.golden-gryphon.com/software/security/selinux.xhtml
<mxpxpod> tseng: ping
<tseng> mxpxpod: yes sir?
<mxpxpod> tseng: did you ever figure out the tomboy stuff?
<tseng> no
<tseng> i did make some progress with muine 0.8.1
<mxpxpod> tseng: oh? how so?
* bluefoxicy starts killing deny lines in squid's acl to try and get net access back
<mdz> trulux: thanks.   that seems to answer only the first question, though
<tseng> mxpxpod: i have a working package
<tseng> mxpxpod: the one patch im not happy with yet
<mxpxpod> tseng: what's your repo
<tseng> mxpxpod: had to hardcode a path
<mxpxpod> ugh
<mxpxpod> not good
<trulux> mdz: it's late here, I will repare the info. for you tomorrow
<trulux> mdz: is it OK?
<mdz> trulux: yes, thank you
<trulux> mdz: you're welcome
<trulux> nite
<mdz> trulux: http://www.ubuntulinux.org/wiki/SELinux
<trulux> mdz: that's ajmitch, yes, we started the page
<trulux> I will make it feeling more complete tomorrow
<tseng> nice, trulux 
<mxpxpod> thom: poing
<tseng> mxpxpod: ill upload the sources for you
<mxpxpod> tseng: thanks.. for tomboy?
<tseng> for muine
<mxpxpod> oh, ok
<trulux> ajmitch: objects ( files, devices ) <- change this on SELinux wiki page, add also sockets, as netlink classes provide fine-grained control over networking-related permissions and such
<trulux> ok folks, nite
<trulux> :)
* trulux turns off the speakers
<mdz> Mithrandir: ping?
<tseng> mxpxpod: http://getsweaaa.com/~tseng/muine/
<mxpxpod> tseng: thanks
<tseng> mxpxpod: oh, didnt upload sources for gtk-sharp2
<tseng> they are from:
<tseng> http://www.ilrt.bristol.ac.uk/people/cmdjb/2004/muine/devel/
<crimsun> tseng: did david mention reworking his packages to be parallel-installable with gtk# 1.0?
<tseng> crimsun: he already did it
<crimsun> ah, ok. thanks.
<tseng> np
<tseng> it installs to a different dir
<tseng> if anyone wants to have a look at that muine package, note that patch to muine.exe.config.in
<tseng> in 0.6.3 the value was @prefix@/blah/libmuine.so
<tseng> reverting to that no longer seems to expand @prefix@, ive hardcoded it for now
<tseng> not sure id want to upload it like that once the time comes
<jbailey_> dilinger: You here?
<mxpxpod> when I reboot my laptop, I get messages saying that the "none" filessytem is busy and that it can't unmount any fs's
<mxpxpod> does anyone else get this behavior?
<mxpxpod> lamont: ping
<mxpxpod> I'll have to talk to lamont about this tomorrow
<mxpxpod> see you guys later
<dilinger> jbailey_: yep
<jbailey_> dilinger: I've discovered that my acpi problems also mean that it doens't know I have fans.  I'm going to hunt down a 2.6,9 kernel and finish the setup for you.
<jbailey_> dilinger: Sorry about the lag.
<dilinger> np.  this is 2.6.10 you're having acpi problems w/?
<dilinger> or 2.6.8?
<jbailey> 2.6.10, ubuntu kernel. mjg59 and fabionne said that it's known suckage.
<bluefoxicy> dilinger:  i'm thinking, `make-kpkg --append-to-version -2 --revision hardened-generic` will build linux-image-2.6.10-2-hardened-generic.deb?
* bluefoxicy is still trying to generate a 2.6.10-2-amd64-generic kernel here with grsecurity added from linux-sources
<robertj> mdz: will you have 5 minutes anytime in the next hour to look over my patches?
<bluefoxicy> damnit!
<robertj> or anyone who knows what they are doing actually ;)
<crimsun> robertj: if no one's responding, please send to ubuntu-devel@
<crimsun> more eyes that way
<robertj> crimsun: well I think its actually ready to assign to a bug report
<robertj> if noone is handy I'm just going to tack it on, it's working fine here
<robertj> I'd give it a 50/50 chance of "noone does their patches that way, do this instead," but it's not the end of the world ;)
<ajmitch> afternoon
<mjg59> jbailey: Yeah, should be fixed in the next upload
* jbailey smothers mjg59 with affection
<juan> on warty I mounted my windows partition on /media/windows for access it on my Desktop :) but I upgraded to hoary and my /media/windows doesn't appear on my Desktop... How can I fix that? thanks :P
<crimsun> juan: this is a #ubuntu question, thanks.
<juan> I'm there now, I'm waiting...
<juan> and waitng... and sorry for stay here
<juan> bye
* daniels showers mjg59 in love.
<mjg59> Become a DD and give me your own hot love
<jdub> mjg59: you've put up a campaign site and/or pitch?
<mjg59> jdub: I believe someone else has already done that for me
<mjg59> 6 months ago
<jdub> heh
<bob2> jdub: angrydpl.com
<bob2> not affiliated with kinnison in any way
<daniels> mjg59: dude, I am
<daniels> mjg59: i just need to con elmo into unlocking my account by getting my new key signed
<jdub> oh man
<jdub> i thought there was fantastic new information
<daniels> jdub: no, but he nominated
<jdub> see that's the new information i'm looking for
<jdub> debian-devel?
<mjg59> debian-vote
<jdub> first nomination, eh
<jdub> oh, boring nomination
<jdub> debian has weird voting conventions
<jdub> haha, april 17th
<jdub> you become dpl on my wedding day ;)
<robertj> should I ubuntu-devel for a MOTU to take a look at the bug I uploaded a patch to or is there another procedure?
<mdz> robertj: ubuntu-devel is best
<dilinger> bluefoxicy: heh, no, the amd64 needs to be added to the --append-to
<bluefoxicy> ah
<dilinger> assuming you want 2.6.10-2-amd64
<bluefoxicy> gpg: WARNING: unsafe ownership on configuration file "/home/bluefox/.gnupg/gpg.conf"
<bluefoxicy> gpg: skipped `John Moser': secret key not available
<bluefoxicy> gpg: [stdin] : clearsign failed: secret key not available
<bluefoxicy> make: *** [stamp-buildpackage]  Error 2
<bluefoxicy> dilinger:  and the -2?
<bluefoxicy> and -hardened
<bluefoxicy> does not match expectations:
<bluefoxicy>                         "2.6.10-hardened-amd64"
<dilinger> i'm not sure what you're going for exactly, but if you want it to show up as the actual version (ie, /boot/vmlinuz-2.6.10-2-amd64-hardened), include it in the --append-to-version.  starting w/ -2
<bluefoxicy> ok
<bluefoxicy> this thing keeps crying to me about debian/changelog and I'm getting confused as to htf you people actually generate the -k7 -generic etc, it looks like you have to modify the changelog for each build????????
<crimsun> no, just use --append-to-version
<crimsun> take a look at the debian/rules script(s)
<bluefoxicy> root@icebox:/usr/src/linux-source-2.6.10# make-kpkg --append-to-version -hardened-amd64 clean 
<bluefoxicy> root@icebox:/usr/src/linux-source-2.6.10# make-kpkg --append-to-version -hardened-amd64 buildpackage
<bluefoxicy> oh wow it worked
<daniels> bluefoxicy: that means that in the changelog, you just put 'John Moser'
<bluefoxicy> daniels:  i'm pretty much making thes efor my own use anyway
<bluefoxicy> though it's a useful skill to be qualified to be a debian maintainer I guess
<bluefoxicy> my lan teacher is gonna teach us to packet sniff in useful ways
<bluefoxicy> i.e. to steal passwords and identify why the hell dhcp isn't working
<daniels> bluefoxicy: Try 'John Moser <email@add.ress>', where email@add.ress is the address of a key in your gpg secret ring
<bluefoxicy> daniels:  i'm doing this as root and sudo is broken, it makes root's home /home/bluefox
* bluefoxicy knows, don't do it as root
<crimsun> -rfakeroot ?
<daniels> bluefoxicy: sudo -H, dude
<bluefoxicy> ah
* bluefoxicy isn't much for sudo
<daniels> bluefoxicy: although why you need to do it as root at all is beyond me
<bluefoxicy> daniels:  because i'm not in the src group, i don't feel like loging out/in of gnome, and I can't figure out how to get newgrp to stfu about passwords
<daniels> bluefoxicy: i untar it to my homedir, and use make-kpkg --whatever build && fakeroot debian/rules kernel_image_deb, but to each his own
* bluefoxicy is very lazy :)  he's playing dragon warrior while doing this
<fabbione> morning
<crimsun> morning, fabbione.
* infinity remembers the good ol' days when Daniel was 14...
<fabbione> ehehhe
<dholbach> morning
<mdz> fabbione: morning
<fabbione> hey mdz
<mdz> amu: ping?
<dholbach> hi you two :-)
<fabbione> mdz: am I ok to upload a kernel with aBI change now?
<rubenv> mjg59: when waking up my laptop from sleep, my screen brightened up and almost nuked, is this normal?
<Treenaks> rubenv: your screen almost died? wow
<rubenv> Treenaks: i've not waited to see the effects
<rubenv> started going very very bright
<rubenv> didn't knew it was able to do that
<Treenaks> leet :)
<rubenv> not really, unless you want an expensive flashlight ;-)
<sivang> morning all
<Treenaks> hey siv
<sivang> Hey Treenaks  :)
<dholbach> hai sivang
<sivang> dholbach: hey daniel
<sivang> 'sup?
* sivang is going to get some breakfast soon
* dholbach is going to his exam in some minutes
* dholbach shudders slightly
<sivang> dholbach: good luck my freind!
<dholbach> i even dreamt, i'd fail and my brother (who does something completely different) would pass it :-)
<dholbach> thanks sivan :-)
<sivang> dholbach: don't shudder, just feel self confident enough and everything would be ok :)
<dholbach> sivang: it'll turn out ok, i guess :-)
<sivang> dholbach: I know you are.
* sivang would be back in 30 minutes.
<dholbach> sivang: bon apptit :-)
<Treenaks> hm, someone  broke a post/preinst somewhere
<Treenaks> I have a file named "1" in my /, with update-rc.d info about /etc/rc0.d/K76fileordering 
<Treenaks> (and rc6.d)
<pitti> Hi guys!
<fabbione> hey pitti
<mvo_> hi pitti, hi fabbione 
<fabbione> hey mvo
<pitti> guys, anything urgent? my main internet connection is broken except for http
<pitti> so I mainly work without irc
<fabbione> pitti: yes.. the kernel is broken.. wanna fix?
<fabbione> :P
<pitti> fabbione: yeah, wait, I quickly exchange the sources
<pitti> <klickerdiklackerdiklick>
<pitti> fabbione: fixed, now it's GNU/HURD :-)
<fabbione> hehehe
<Kamion> morning
<Kamion> fabbione: I don't think there's any reason not to upload a new kernel now, might as well get it over with
<fabbione> Kamion: i just had to be sure there was nothing pending/urgent from Array4
<Kamion> not that I'm aware of
<fabbione> cool
<Kamion> and at this stage it would seem unlikely :)
<fabbione> you may never know :P
<Kamion> Treenaks: amusingly, there's also a '1' in readahead's source package
<Treenaks> Kamion: hmmm...
<Kamion> Treenaks: see changelog for readahead 1.0.1-2, it's been fixed
<fabbione> lamont: are you still around?
<Kamion>   * Fix some redirections with '&'s in the wrong place
<Kamion>     Thanks, Daniel Robitaille
<Treenaks> Kamion: ok.. so it's safe to remove /1 ;)
<Kamion> Treenaks: is it dated before 24 Jan 2005?
<Treenaks> Kamion: yes, 17-01
<Kamion> Treenaks: yeah, can remove it
<pitti> yay, net is back
<opi> uh! Long time no see.
<Treenaks> wb opi
<opi> I have a problem, who is in charge of UTF-8 packages for Hoary?
<opi> I have UTF-8.pl keymap to put in Hoary before freeze
* Treenaks points at pitti 
<opi> pitti: ping? :)
<pitti> opi: pong
<opi> pitti: should I sent you it? :)
* pitti asks himself why he should be a particular keymap guru
<pitti> opi: for X or console?
* opi points Treenaks :)
<opi> pitti: the problem is, I don't know where to put it, and I wish it will not waste
<pitti> opi: is it an X keymap?
<opi> pitti: console
<opi> pl-utf.kmap
<opi> Maintainer: Alastair McKinstry <mckinstry@debian.org>
<opi> is an maintainer of console-tools
<opi> should I poke him, then?
<pitti> opi: you should poke him anyway, if it finds its way through debian to upstream, this is the best way
<pitti> opi: however, feel free to mail me the keymap, I can include it into Ubuntu as well
<opi> but it won't go in Ubuntu/Hoary
<opi> and that's my priority 
<opi> :-)
<Mithrandir> mdz: pong
<Kamion> opi: file a bug please and we'll figure out who's responsible
<Kamion> I've been dealing with a fair bit of console-tools stuff up to now, but I'm no exper
<opi> Kamion: ok, I'll attache it
<Kamion> +t
<opi> Kamion: thanks
<Hwolf> Is nautilus cd-burner unusabe?
<seb128> ?
<Hwolf> Trying to burn a disk, and it doesn't see the cd in the writer
<Treenaks> Hwolf: why wouldn't it be?
<Hwolf> I'm pressing burn, an empty disk is in the drive, and it doesn't burn.
<seb128> even if you retry ?
<Hwolf> Yup
<seb128> there is a bug about this but it works after retrying
<Hwolf> I've even checked that the cd is actually in the burner. Right side down even.
<Hwolf> It's there, I've retried 10 times.
<Treenaks> Hwolf: any error messages in ~/.xsession-errors?
<Treenaks> or where-ever gnome-session puts them
<seb128> Hwolf: wait for the next release so
<seb128> the bug is fixed upstream
<Hwolf> seb128: ok, it's gnome, so it'll still get in?
<Kamion> yes
<seb128> correct
<Hwolf> seb128: will that bug with the menu be ironed out? the size of the 'program tabs' in the window list?
<seb128> no idea
<Hwolf> seb128, could you untill that time adjust the default of the window list applet to set min-size to 700 or so?
<seb128> Hwolf: I'll ping upstreams about this, but that's not a big issue for a devel branch
<Hwolf> True
<seb128> elmo: libbonobo, libbonoboui sync please
<seb128> jdub: around ?
<jdub> yo
<seb128> jdub: could you run your magic to know what GNOME packages are outdated ?
<jdub> seb128: ok
<jdub> seb128: going to get dinner first tho :)
<seb128> no problem, there is no hurry 
<seb128> have a good dinner :)
* sivang is back
<Mithrandir> doko_: ping
<doko_> Mithrandir: pong
<Mithrandir> doko_: you saw my python2.4 upload?
<doko_> yes, this morning. is this necessary for the 2.4 branch as well?
<Mithrandir> uhm, it was the 2.4 branch.
<Mithrandir> it makes locale usable with python2.3 in a Norwegian locale.
<Mithrandir> without, it throws silly errors.
<doko_> you made a change in 2.4 so that locales are usable in 2.3?
<Mithrandir> no
<Mithrandir> I made a change in 2.4 so that locales are usable in 2.4
<Mithrandir> the same fix should be applied to 2.3 if one wants nb_NO to be usable as a locale there.
<doko_> Mithrandir: ok
<thom> anyone played with using a bluetooth headset with alsa?
<Treenaks> thom: is that possible?
<pitti> elmo: please sync pmount 0.7.1-1 from incoming
<thom> Treenaks: it seems that it is, but i'm just wary that i'll end up doing too much hacking to make it work
<doko_> hmm, is the temporary inconsistency? http://archive.ubuntu.com/ubuntu/dists/hoary/main/source/Sources.gz  MD5Sum mismatch
<elmo> yeah
<Hwolf> md5 mismatches suck. I was planning to install array-4, and after formatting I found out it was corrupt. Had to install from array-3 and update. :-S
<Kamion> Hwolf: must have been a download problem
<Kamion> (or a burn issue)
<Hwolf> Kamion: Yup, the one time I don't bother checking the md5 because I was so exited. :-)
* Hwolf is waiting for *another* 30 gig of data to move to another partition. :-S
<Kamion> elmo: oh, any chance of getting signed MD5SUMS of the {,daily-}installer-* trees in the archive?
<elmo> signed by who?
<Kamion> the archive key?
<elmo> Kamion: err, I guess
<Kamion> elmo: (it's so that you can do a secure netboot install; at the moment everything's signed apart from the kernel/initrd)
* sivang just found some of erinne's photos of debconf4, wooha
<helix> sivang: why wooha?
<sivang> helix: wooha = what a bunch of nice, high quality footage :)
<helix> oh ok. glad you like it.
<helix> my name is spelled 'erinn', btw :)
<fabbione> hey helix
<helix> hey :)
<jbailey> Erinn!
<helix> jeff, dear
* helix hugs
* jbailey hugs
<fabbione> elmo: i think i just ddosed rsync on archive.u.c
<fabbione> can you check if there are really 15 connections from different ip's?
<dholbach> re
<elmo> fabbione: there are a couple of folks on more than once, but not you AFAICS
<fabbione> elmo: ok thanks
<fabbione> 212.242.114.141
<fabbione> can we restrict to one session per source ip?
<elmo> hmm, damn I wish rsync had per ip connection limits
<fabbione> ah ok
<fabbione> because it's hours i can't rsync
<elmo> oh, I guess we can if I run rsync via xinetd
<fabbione> and sparc is lagging for that
<fabbione> yeah an empty slot!
<elmo> there's some guy using 5 connections slots up
<fabbione> ah nice...
<fabbione> ban him :P
<thom> aargh, more cdbs crack
<jbailey> thom: Mm?
<jbailey> thom: What'cha need?
<fabbione> hey jb :)
<jbailey> Fabio!
<thom> nah, i'm just doing my traditional whimpering
<elmo> is there a "Mid-East" to the US?
<jbailey> thom: Ah, a'ight.  If you actually need something fixed without the use of 'rm', lemme know. =)
<elmo> well, obviously there is, but is it as idiomatic "Mid-West US"?
<thom> jbailey: yeah, will do :-)
<thom> jbailey: fortunately, this was just the addition of files to install
<jbailey> elmo: No, the middle east is filled with brown skinned people and desert (And includes a large chunk of asia and india).  I think CNN tries not to confuse the public. =)
<elmo> hmm, well, what's a good way of breaking down US mirrors?
<elmo> geographically being the preferred choice - would most USians recognise states in a useful fashion?
<jbailey> elmo: Keep in mind that I'm not American, but the divisions I've heard seem to be East coast, new england, south, midwest, and west coast.  The groups seems to be about similar population densities.
<sabdfl> hi guys
<sivang> hey sabdfl 
<sabdfl> am having erros booting warty on an hp proliant dl140
<sabdfl> errors, not eros
<sabdfl> ;-)
<sabdfl> any idea what might cause this:
<fabbione> hey sabdfl 
<sabdfl> pivot_root: No such file or directory
<fabbione> where is the root located?
<sabdfl> it cannot find /dev/console apparently
<sabdfl> fabbione: the root is on a /dev/hda3
<fabbione> that sounds like a broken initrd
<jbailey> Definetly broken initrd.
<sabdfl> how do i recreate an initrd?
<jbailey> Usually means that the driver for the root filesystem isn't getting loaded for some reason.
<sabdfl> yes, thats it
<jbailey> sabdfl: Was this after a kernel upgrade or a fresh install?
<fabbione> sabdfl: reinstalling the kernel..
* thom wonders why "mtu" isn't honoured by the dhcp method in /etc/network/interfaces *gar*
<fabbione> sabdfl: boot via d-i and stop at the partitioner
<sabdfl> jbailey: it's after someone copied a root partition to a new machine :-)
<sabdfl> can i not just uninstall and reinstall a kernel?
<fabbione> go to the shell and mount the fs in /target
<fabbione> from there you can chroot
<sabdfl> i have a statically-compiled kernel that works
<jbailey> sabdfl: Yeah, sorry that current initrd's suck for that.  The new stuff for Hoary+1 should be better.
<jbailey> sabdfl: You can also just run mkinitrd
<sabdfl> which will be easier and faster, mkinitrd or fabbione's d-i hack?
<jbailey> mkinitrd -o /boot/initrd.img-${VERSION} ${VERSION}
<thom> if you have a static kernel that works, mkinitrd; fabio is working around an entirely non-booting machine
<elmo> sabdfl: err, is this normal warty or customized?
<jbailey> is all the kernel reinstall does, but you have to be able to get that far.
<elmo> 'cos I installed normal warty on our DL140's without problems
<sabdfl> elmo: warty, server install (base + selected packages)
<fabbione> sabdfl: if you can boot with another kernel, go for it.
<sabdfl> this was installed on another box, then the root was copied over (don't ask)
<sabdfl> i'mn trying to clean it up
<fabbione> sabdfl: i supposed you were installing from scratch
<sabdfl> ok
<sabdfl> jbailey: so mkinitrd figures out what it needs?
<jbailey> sabdfl: Yeah.  In the even that it's wrong, add modules to /etc/mkinitrd/modules
<jbailey> (IT's a text file, one per line)
<jbailey> But for the HP server series, I've never had a problem.
<sabdfl> and VERSION should be the version of the latest kernel?
<sabdfl> 2.6.8.1-3.686-smp?
<sabdfl> or somesuch?
<jbailey> sabdfl: Yes, whichever one you want to rebuild.
<sabdfl> superb
<sabdfl> thanks muchly guys
<fabbione> sabdfl: :-)
<jbailey> elmo: I took a look this weekend, and noticed that there were more pieces for nagios-plugins not in main than I had expected.  I'd like to nuke the nagios-radius-plugin that I made before and replaces: it all with nagios-plugins-extra
<jbailey> elmo: Any objections?
<elmo> jbailey: confused - what else is missing?
* fabbione fires up the "God Father" sound track
<jbailey> elmo: I hadn't realised from the bug report that all three of those things mentioned were in main.  I thought you were just doing a review and that forcing people to install all of that was insane (which it is...)
<jbailey> So radiusclient, qstat, and libsnmp-perl are all three needed.  So instead of making separate packages for each, I figured I may as well do a nagios-plugins-extra package and be done with it.
<jbailey> That way if others creep in (and they surely will) we can just stuff them in there.
<elmo> oic, so demote them to a separate package rather than a recommends/suggests.. fair enough
<sivang> fabbione: one of the best theme music I've heared, btw :)
<fabbione> sivang: i have the version redone by Axel Roses :-)
<seb128> elmo: gtkmm2.4 glibmm2.4 libglademm2.4 gconfmm2.6 (exp) and gnome-vfsmm2.6 libgnomecanvasmm2.6 libgnomemm2.6 libgnomeuimm2.6 (unst) syncs please
<jbailey> elmo: Yeah.  Satisfies all the build-dep issues, and means that there's no risk of someone getting false readings when the plugins don't safely cope with being run when pieces are missing.  (They appear to generate false-"I'm up" states)
<sivang> fabbione: amazingly enough, I also have it, and *is* the one I like best :) , Guns'N'Roses were ever working IMHO :)
<sivang> fabbione: I think Slash is doing the lead solo on that version right?
<elmo> jbailey: eww! (false-up)
<jdub> seb128: whoa, *mm central!
<seb128> :)
<lamont> fabbione: at 0230, I'm genarally asleep.. :-)
<fabbione> lamont: you may never know :-)
<fabbione> but i got from kyle what i was searching for
<lamont> yeah - saw that.
<lamont> you gonna upload my ia64 fix today?
* sivang heads for lunch, be back later
<fabbione> i did the ia64 fix in -14
<fabbione> or are you talking about something else?
<fabbione> last think i changed for ia64 was:
<fabbione> linux-source-2.6.10 (2.6.10-14) hoary; urgency=low
<fabbione> 
<fabbione>   * Add ext2 modules udeb for ia64.
<fabbione> 
<fabbione>   * Unset CONFIG_BLK_DEV_AMD74XX on ia64.
* fabbione waits patiently the last turtle to go trough drivers/char/drm
<zul> hey
<fabbione> hey zul
<zul> hey fabbione how is it going?
<fabbione> zul that libata stuff is crack imho
<fabbione> zul: getting ready to upload -15 today
<zul> the one in the bug?
<fabbione> yes that one
<fabbione> one patch is bogus
<fabbione> the it has some bits that conflicts with the other
<fabbione> (+ they are really useless there)
<zul> yeah i noticed i just pulled a copy out of bitkeeper
<fabbione> cool
<fabbione> did you test it?
<zul> well it applied i dont have ata to test it on
<fabbione> oh ok
<fabbione> does it build?
<zul> oh yes
<fabbione> ok.. send it over.. it's ready for warty
<zul> k
<zul> ill put it up on my webpage
<fabbione> or on the bug...
<fabbione> whatever is fine
<zul> yeah im at work right now
<zul> gimme a sec
<fabbione> all the time you need
<fabbione> i am waiting the turtle to check if it builds drm
<zul> heh
<fabbione> the new code introduced a regression...
<zul> done
<ogra> ladies and gentlemen, may i introduce you to the new lsb info data, soon available in a device manager near you: http://www.grawert.net/hal_lsb_info.png (yes, i know that the bios data is missing icons, i'm working on it)
* lamont plays taxi
<enrico> elmo: hello.  Want to close this repository migration stuff?
<fabbione> zul: is this patch on top of the libata updates that we already have?
<elmo> oh yeah, I was downloading the snapshot before my X server decided to die again
* dholbach congratulates to such an admirable replacement of the old hal-device-manager. :-)
<zul> fabbione: no you dont have to drop any of the patches for the ata we already have sorry i should have mentioned that
<fabbione> ok
* dholbach congratulates ogra....
<ogra> :)
<enrico> elmo: glub!  33Mb!  I see...
<zul> fabbione: when i was building the kernel i didnt reliazed it build all the images for 386 smp etc
<fabbione> zul: ahahha
<zul> fabbione: so saturday morning it was still building confused the hell out of me
<fabbione> zul: apt-get install ccache
<zul> yeah yeah 
<enrico> elmo: I'm trying to download them and put a compressed version online for you 
<elmo> enrico: don't worry
<elmo> enrico: the data centre has plenty of bandwidth :)
<elmo> I'm restoring it now
<elmo> (plenty == I just got 10M/s trans-atlantic to a mirror ;-)
<elmo> ok, restored, creating the user accounts now
<elmo> enrico: done you're new password; please check it out and see if it Works For You
<dholbach> bbl
<enrico> elmo: did you send me the new password via mail?
<elmo> enrico: I used the one you sent me?
<enrico> elmo: I'm silly
* enrico blesses that time he configured "also encrypt to self" in mutt
* sivang is back
<sivang> ogra: hi oliver, what's up? nice screenshot
* Kamion escapes from a twisty debconf maze
<enrico> elmo: relocated perfectly, commit works!
<enrico> elmo: I'm writing the announcement message
<ogra> sivang: yeah, i'm nearly done with my hal oatch, now we have /proc/cpuinfo, /proc/meminfo, the data o dmidecode and the data of lsb_release in hal .... so lshal will offeryou nearly everything now ;)
<Treenaks> ogra: nice!
<ogra> s/oatch/patch/
<enrico> elmo: have you created the other two accounts (Nick, Sean) as well?
<elmo> enrico: yes, just finished doing that; have mailed them their uname/pwords
<elmo> enrico: was there anyone else yet?
<sivang> enrico: can I have one also?
<ogra> i'm wondering if i should add some dynamic X info if $DISPLAY is set.....(xdpyinfo) 
<Treenaks> ogra: did you see the NMEA-compatible GPS detection code for HAL that I wrote in Mataro?a
<ogra> Treenaks: no, not yet....
<enrico> elmo: that's very cool.  There should me more people (sivang, for example, which I'll LART very soon; plovs; ChrisH; hornbeck), but they didn't send the data yet
<Treenaks> ogra: it's cool, but a bit hacky
<Treenaks> ogra: and only works on USB serial ports for now :(
* enrico larts sivang with 1000 copies of my announcements on ubuntu-doc :)
<zul> thats not nice
<enrico> sivang: of course you can have commit access.  Just read http://lists.ubuntu.com/archives/ubuntu-doc/2005-February/001146.html for instructions on how to do it
<ogra> gah
* Treenaks pokes ogra's isp
<Treenaks> ogra: I'll mail it to you..
<ogra> Treenaks: better poke my distribuor......that was a real odd hardlock of my keyboard....
<Treenaks> ogra: hmm.. weird
<ogra> i'm having xkb probs since i have this machine....will file a bug once i found out where to look....
<enrico> elmo: sent the announcement.  Did jdub create the -commits mailing list?
<enrico> sivang: seen the mail?  Sent the data?
<Treenaks> ogra: in your mailbox
<sivang> enrico: in a sec, I am on the phone :)
<elmo> doko_: ?
<elmo> bleh, nm
<elmo> enrico: err, I don't know sorry; he hasn't said anything to me at least
<jdub> yo
<jdub> enrico: i msged you on saturdayish
<elmo> enrico: but http://lists.ubuntu.com/mailman/listinfo/ubuntu-doc-commits seems to work ..
<jdub> hold on
<jdub> i'll reset the password
<sivang> yo jdub 
<elmo> enrico: so I've updated the mail-on-commit hooks to point there
<enrico> cool!
<enrico> jdub: msged me?  let me see
<jdub> elmo: what will the sender address be?
<ogra> Treenaks: you should clean up and send it to sjoerd for inclusion ;)
<doko_> elmo: pong
<Treenaks> ogra: I already sent it to Sjoerd... I also need to test it with recent HAL
<elmo>  - it should never be down ever again (or just be down less often)
<Treenaks> ogra: nice project for tonight :)
<ogra> ;)
<elmo> enrico: I'm glad you qualified that
<elmo> doko: sorry, nm, it's an ia64 specific problem, not a general problem
<elmo> jdub: err, From: or From or Sender?
<jdub> From:
<sivang> enrico: hrm, I would need james's key then :)
<jdub> enrico: the list will discard all other mails
<sivang> Treenaks: what does this code do martin?
<Treenaks> sivang: it detects if a newly added USB serial port is actually a (NMEA-compatible) GPS
<Treenaks> sivang: and it adds a capability if it is
<Treenaks> then I only need to write a gpsd which uses DBUS
* Mithrandir waits impatiently for Treenaks to finish
* fabbione hsa a gps
* Mithrandir too
<fabbione> but i use it to be stratum-1 ntp server
<ogra> Treenaks: then you will need a milloin of ppl collecting address data for an oss DB ;)
<Treenaks> ogra: GPS data on dbus is cool -- you can make a 'location' gnome panel applet  :)
<ogra> Treenaks: imagine that with the matching address ;)
<elmo> jdub: From: will be ubuntu-doc-commits@lists.ubuntu.com; From will be docteam@maitri.ubuntu.com probably
<elmo> From and Sender
<elmo> the first one then
<elmo> sivang: 0xAB2A91F5
<jdub> elmo: thanks
<sivang> elmo: thanks
<Treenaks> ogra: all we need is Free map data..
<ogra> Treenaks: maps are not enough....and you wont find free adress data in large amounts :(
<Treenaks> ogra: true
<Treenaks> ogra: but maps help
<fabbione> Mithrandir: your python2.4 upload is FTBFS
<fabbione> lamont: other than the new -pa patch and the ia64 changes.. is there anything else you need for there 2 arches?
<Mithrandir> fabbione: argh, you're right.
<fabbione> no i am not.. my sparc buildd is :-)
<enrico> elmo: I committed a couple of things, but there are not messages getting to the list: have the mails been sent?
<elmo> oh, meh
<elmo> enrico: sorry, the 'post-commit' hook got lost in the restore.. I've put it back
<zul> fabbione: everything ok with the patch?
<jdub> enrico: i've made it so discarded mails are sent to you
<jdub> enrico: turn it off when things are working ok :)
<fabbione> zul: yes. uploading -15 now
<lamont> fabbione: nothing comes to mind
<zul> sweet
<lamont> fabbione: woot!
<fabbione> with ABI change...
<fabbione> somebody will have to take care of l-r-m
<fabbione> and d-i
<Kamion> I'll do d-i as usual
<enrico> elmo: it works!
<elmo> enrico: excellent
<fabbione> Kamion: ok, mind to tell me what needs to be changed? at least i will know if you are not around
<fabbione> Kamion: btw do you think you can be around tomorrow for the kernel meeting?
<Kamion> fabbione: basically just grep -r for the old abiname (2.6.10-2 or whatever) in build/config/ and change all those
<Kamion> fabbione: guess so, what time?
<fabbione> Kamion: ok
<fabbione> 15:00 UTC
<enrico> jdub: any problems in advertising the list on lists.ubuntu.com?
<Kamion> should be easy to make
<zul> fabbione: hmm...maybe i should go to that meeting ;)
<jdub> enrico: no, it's just off by default until you're happy with it
<enrico> jdub: ok, turning it on
<sivang> fabbione: kernel meeting?
<jdub> enrico: FULL POWER!
<fabbione> sivang: yes.. see ubuntu-devel
<sivang> fabbione: k
<fabbione> zul: same as above ;)
<zul> fabbione, heh 
<Kamion> fabbione: oh, and the installer/casper seeds generally need a minor update, which should be obvious from looking at them
<fabbione> Kamion: right... so we have a few points.. kernel -> l-r-m -> d-i -> seeds
<fabbione> Uploading via ftp linux-source-2.6.10_2.6.10-15_source.changes: done.
<fabbione> there
<Kamion> no, (kernel and seeds) -> (l-r-m and d-i in either order)
<Kamion> d-i needs the updated udebs in the archive in order to build
<fabbione> right
<fabbione> ah.. and ping -f elmo-please-process-NEW
<doko> fabbione: if you make a new l-r-m upload, please could you update a license file?
<fabbione> doko: no i will not.. l-r-m is daniels territory
<fabbione> and i am almost off for the day
<fabbione> i know he has a bunch of pending changes in his tree
<doko> fabbione: ok, will ask him.
<fabbione> good boy :P
<zul> heh i should have my own tree
<Kamion> mdz: bleh, modifying hoary CDs is really painful now; while I'd tried to avoid checking Release.gpg when installing off a CD, any calls to apt-get that the installer makes after debootstrap has completed have gpg available in /target and so do signature checking
<Kamion> mdz: any thoughts on what the best way to stop them doing this is? I keep losing time to it
<jdub> dear fabbione, your new kernel rocks, love jdub
<fabbione> ahha
<fabbione> jdub: the inotify problem is not fixed yet
<fabbione> i am going to wait max after i am back from the honeymoon
<Kamion> I'm half-tempted to add support for installer/gpg-verify=false or something, but having to remember to specify that manually and only finding out that I forgot ten minutes into a test sucks
<fabbione> if it is fixed good, otherwise the default will switch to disabled
<fabbione> Kamion: what about temporary disable the check with the apt option?
<fabbione> we know that it works
<fabbione> we can just disable for sometime
<fabbione> or add a flag official/test release to the script
<fabbione> that will add or skip the apt.conf file for yu
<fabbione> you
<Kamion> fabbione: I'm doing that by hand, but I really don't want to disable it for all installs
<Kamion> fabbione: it's had a number of random breakages and I don't want to find out about one of them two weeks before release
<Kamion> fabbione: like the apt-cdrom thing, which I don't think could have been easily anticipated
<_mvo_> Kamion: apt-0.6.31 with apt-secure cdrom support was uploaded today btw (you probably noticed already)
<Kamion> _mvo_: yup, thanks
<_mvo_> update-manager can detect now if the runing distro is still the latest released one and if it is still supported. the question is what to do with this information? what do you think? should we offer a automatic or semi-automatic upgrade mode in that case?
<elmo> _mvo_: btw, in response to your mail, you know about the info in the top level Releases, right?
<tseng> that doesnt sound that sane, even though it should usually work...
<tseng> i would make it say "this distro is no longer support, and does not receive security updates. see this doc for info on upgrading"
<fabbione> zul: for the next release we need to look at USB
<_mvo_> elmo: yes, but they are not available in one place. I would like to get the stuff with only one http hit
<tseng> just my 0.02
<fabbione> zul: i have heard that Suse snapshot (2.6.11rc2-bk6 or higher) have the fix for all the USB mess with have now
<elmo> _mvo_: it's IMSed tho right?
<_mvo_> tseng: yes, I agree mostly. it really makes me nervous messing with the users sources.list
<_mvo_> elmo: *cough* not ... yet
<tseng> _mvo_: yeah, it should be totally doable.. question is, do we really want to do this?
<tseng> even if everything goes smooth, a dist change could be pretty instrusive
<elmo> _mvo_: dude, don't make me push one of our racks on top of you
* _mvo_ hides
<_mvo_> elmo: the code is not even released yet, don't worry
<zul> fabbione: ok do you want to look at it?
<fabbione> zul: if you have time can you start giving it a shot?
<zul> sure...just point me to the right bk
<fabbione> zul: i think linus one is ok
<zul> k
<fabbione> or check the linux-usb one
<zul> k ill put it on my todo list
<fabbione> thanks
<fabbione> if you can manage for tomorrow morning (my time) it will be great.
<fabbione> i will start looking into alsa
<zul> yep am at work duing that time but im at work right now :)
<fabbione> after that we should be pretty in a good shape
<fabbione> Kamion: is array5 scheduled in 2 weeks from now?
<elmo> Kamion: did you go ahead with that mirror masterlist stuff?
<zul> grrr
<sivang> seb128: what is the /wncklet source tree responsible in gnome?
<Treenaks> sivang: virtual desktop switcher I think?
<Treenaks> that's called "wnckapplet"
* fabbione is off
<Nafallo> should parport module loaded be considered a bug on a system without parport?
<sivang> Treenaks: that what I thought so, but I found there some code presumably for the show desktop button etc..
<sivang> Treenaks: so I am a bit confused
<sivang> I wonder if vincent untz is here..
<jdub> sivang: vincent untz == vuntz
<sivang> jdub: tnx :)
<elmo> Kamion: also any objection to me creating a trace/ dir on releases.u.c (and cdimage.u.c) I guess ?
* infinity wonders why you'd even need to ask.
<elmo> just politeness?  the contents of releases.u.c and cdimage.u.c are otherwise entirely controlled by kamion
<Kamion> elmo: go ahead
<Kamion> fabbione: array5> about 1.5 weeks
<Kamion> elmo: mirrors> not yet
<elmo> Kamion: okay, 'cos I'm doing a massively lagged update of them both; I'm also going to be adding some archive.$cc.u.c aliases too soon hopefully
<website> hi to all
<Kamion> elmo: ok, there's no massive hurry as far as I'm concerned
<elmo> Kamion: it doesn't need any code changes or anything else affected by freezes?
<Kamion> elmo: it needs choose-mirror and base-config uploads
<elmo> normal install won't prompt for this tho, I guess?
<Kamion> needs to beat preview freeze, but I think it can drift a little past feature freeze
<Kamion> no
<Kamion> not normal CD install anyway, dunno yet about netboot
<elmo> mmph
<elmo> maybe we should do a clamav type thing, where you pre-create archive.$cc.u.c. that points at archive.u.c unless there's a decent CC mirror
<pitti> elmo: squid sync please
<elmo> pitti: unstable?
<pitti> elmo: yes
<pitti> elmo: 2.5.7-8
<elmo> [NOT Updating - Modified]  squid_2.5.7-3ubuntu1 (vs 2.5.7-8)
<elmo> ok to overwrite ubuntu changes?
<pitti> elmo: yes, Ubuntu changes are only security fixes
<pitti> elmo: (which are now in Debian, too)
<elmo> k, done
<pitti> thanks
<pitti> elmo: btw, can you please sync pmount from incoming?
<elmo> pitti: in a bit
<elmo> my new mutli-sync stuff neglected to take incoming syncs into account; I need to re-add support for that
<elmo> ARGH
<elmo> is anyone else seening X randomly crash when switching virtual desktops?
<Mithrandir> no, but I haven't restarted X in a couple of weeks.
<Mithrandir> I should probably reboot to get my hda5 to appear so I can have suspend-to-disk working
<seb128> sivang: ?
<sivang> seb128: yes
<sivang> seb128: here
<seb128> you pinged me about wnck ?
<sivang> seb128: ah  right :) I managed, I have something else I'd like to know though :)
<low> hi there
<low> anyone for rais debugging of latest iso ?
<low> s/rais/raid
<sivang> seb128: any of the gnome-pilot things work in ubuntu? why can't I see those from the deskop->preferences?
<low> it keeps complaining it can't find any linux raid autodetect partition
<sivang> seb128: bascially, I am trying to find out on the desktop where I can see the stuff in gnome-pilot-conduits
<seb128> sivang: in evolution ?
<sivang> seb128: ah ok, checking.
<mako> http://trendwatcher.koan.net/node/94
<elmo> Kamion: you know the whole symlink into pool has an interesting side effect, namely that lftp can't see the .iso's in http:// :>
<sivang> mako: hrm, seems like most of the peope are using google? :)
<tseng> the M is as in millions?
<tseng> that doesnt seem right
<mako> tseng: yah
<Kamion> elmo: oddness :)
<Kamion> elmo: is that really due to the symlink? surely lftp shouldn't be able to tell the difference either way
<Kamion> elmo: and, er, it can see them when I try it here ...
<Kamion> elmo: it just lists them separately up at the top, probably due to the pretty HTML index thing
<elmo> oh, dear god, I'm so stupid
<elmo> Kamion: yeah, never mind, i managed to miss them at the top
<elmo> and it's not the pretty index, I don't think, I noticed this on mirrors
<elmo> oh, which they inheirt.. neat
<thom> elmo: ... we'd noticed
<elmo> amu: ?
<Alessio> hi
<Alessio> mu time in gnome panel
<Alessio> *my
<Alessio> ops
<Alessio> sorry
<amu> elmo: too late :)
<elmo> amu: why is clamav *.diff.gz empty?
<amu> elmo: lemme check
<amu> elmo: it should be something like 330k 
<amu> elmo: letme repack it 
<jdub> seb128: ping
<seb128> jdub: pong
<elmo> amu: thanks
<seb128> ??
<seb128> "<-- jdub has quit ("seb128")" ... what does that means ?
<jdub> i cannot believe i just typed /quit seb128
<seb128> loool
<jdub> that means i should have gone to bed hours ago :)
<seb128> ah ha
* seb128 kicks jdub 
<amu> seb128: today 21.00 CET #ubuntu-holiday
<seb128> elmo: intltool sync please
<seb128> amu: yeah, pitti already pinged me about this
<amu> seb128: cool
<thom> seb128 isn't allowed any holiday
<pitti> seb128: remember to break the panel before going to holiday, btw :-)
<pitti> seb128: we need something to bitch about while being in .au 
<jdub> oh man, and i had all these nice queries open with logs i wanted to keep
<jdub> yeeesh
<seb128> pitti: bah, not always the panel, lemme try with gtk this time :)
<pitti> ok, you're right
<tritium> I'm doing some discretionary access control tests to certify ubuntu for use in-house, and I'm wondering why messagebus UID is displayed rather than "messagebus" when using "ps -ef"
<Kamion> longer than eight characters, at a guess
<tritium> Kamion, ah, okay.  That seems reasonable.  Thanks.
<seb128> elmo: dasher sync too please
<Kamion> ps probably has options to control that, it has options for everything else :)
<thom> oh geez. firefox is built static in debian now
<dilinger> eh?
<dilinger> is that something new in -5?
<thom> in -3
<thom> +  * debian/rules: Enable static building. This will build firefox as one
<thom> +    large binary (mostly) 
<elmo> ugh
<thom> i think we'll avoid that one] 
<Kamion> uh, uh, uh ... WHAT?
<dilinger> thom:  ldd /usr/lib/mozilla-firefox/firefox-bin shows a bunch of stuff linked against
* thom installs into debian chroot to look
<Kamion> elmo: chmod g+w /home/warthogs/archives/ubuntu-devel@lists.ubuntu.com/seeds/seeds--hoary/seeds--hoary--0/patch-124 on chinstrap please, so that I can commit to that branch?
<jdub> seb128: syncing dasher is so much cheating :)
<seb128> jdub: :p
<pitti> Kamion: oh, I just tried to commit there as well
<elmo> meh
<pitti> Kamion: I wait until you committed, can you please ping me?
<elmo> the dir itself needs chmod g+w?
<Kamion> ok
<Kamion> elmo: I think so; all the other patch-* dirs have that
<pitti> elmo: yes, otherwise we can't remove the ++revision lock below it
<thom> dilinger: but yeah, agreed, it doesn't look like it's built statically, even tho the correct configure options have been passed
<elmo> I always just chmod'ed g+w the revision lock.. but ok
<thom> go mozilla, it's your... birthday
<elmo> done
<pitti> lifeless_: btw, regarding directory permissions, isn't there anything that can be done about this?
<pitti> lifeless_: like, specifying an umask on commit or on archive creation?
<Kamion> ok, that worked, thanks
<Kamion> pitti: ping
<Kamion> pitti: sftp's fiddly in this regard unfortunately
<pitti> Kamion: on alioth I set umask=002 in my ~/.bashrc
<pitti> Kamion: however, I don't want to do this on chinstrap
<Kamion> yes, it's a bit crap to require all users to do that though
<pitti> Kamion: okay, I updated your changes, now I commit mine
<pitti> oops
<zul> oops?
<fabbione> hmmm
<fabbione> -15 might oops under heavy inotify pressure
<fabbione> Robert reviewed the 'noinotify' patch and it can introduce a memory leak if noinotify is enabled :(
<fabbione> (tho it works fine here.. uptime 3 days)
<Mithrandir> mdz: ping
<mdz> Mithrandir: pong
<Mithrandir> mdz: 4892; I don't think it's needed to fix it for warty.  They aren't real passwords, they are sent in clear-text and should never have been named passwords.
<Mithrandir> mdz: if you think a security update is warranted, feel free, but personally, I don't see the need.
<sivang> elmo: can you please sync http://packages.debian.org/unstable/web/mozilla-firefox-locale-he , it's useful for the langpacks...
<elmo> sivang: are you an MOTU?
<sivang> elmo: hrm, no, does this pkg needs one?
<sivang> elmo: I talked with ogra about that package and he said it would be best instead of me attempting to upload one to ask you to sync it..
<thom> sivang: you'd nuke the langpack stuff if you sync it anyway
<elmo> sivang: I think sync requests need to come from or at least be acked by an MOTU or maintainer
<thom> wouldn't you?
<sivang> thom: oh, yeah the control file needs some love right..the 1.0 moz-firefix depends?
<thom> look at the firefox locales in hoary - they have changes for langpacks and dependencies
<sivang> thom: I think pitti has already noted me what needs be done, ok, I'll prepare a new package
<Kamion> oh, did I ask whether I could add (at least) English language packs to ship?
<dholbach> re
<elmo> Kamion: don't ask, just do it :P
<sivang> hrm, it's raining here so much I hope my windows wouldn't fall off...strange to see such weather over here..:-o
<elmo> only half-joking; that surely falls under Obvious?
<Kamion> elmo: I'm fairly sure somebody will want to work out exactly which language packs go on the CD, and I know it won't just be English
<ogra> elmo: could a MOTU trigger the sync of a main package ? that was the reson i pointed sivang here....
<Kamion> but yeah, I guess English falls under obvious
<pitti> Kamion: funny, I just thought the same half an hour ago
<pitti> Kamion: maybe the set of Desktop langpacks should be discussed in TB/CC?
<pitti> TB, probably
<Kamion> TB
<elmo> ogra: that pkg isn't in main ?
<pitti> Kamion: I remember sabdfl saying something about 10 to 15 langpacks which should be on the CD
<Kamion> well, I've moved English anyway
<Kamion> bored of having to download stuff during tests :)
<ogra> elmo: all the mozilla locale packages are in main i thought ?
<Mithrandir> mdz: any thoughts on it?
<elmo> ogra: mozilla-firefox-locale-he isn't in Ubuntu, period, right now
<pitti> ogra: just the firefox ones, not the ones from legacy mozilla
<elmo> ogra: if it was synced, it'd go into universe by default
<mdz> Mithrandir: in the middle of a few other conversations at the moment, I will take a look
<Mithrandir> mdz: ack
<ogra> elmo: oh, i had expected it would get lifted to main then :)
<mdz> getting crucified on #d-d at the moment
* sivang joineis
<thom> mdz: only by the crazies ;/
<zul> thom: say it aint so
<dilinger> zul: hey, ever get around to the config tool stuff?
<threshold> does anyone know if mISDN works in hoary yet? I know mISDN broke kernel 2.6.10, wondering if anyone knows of a fix yet?
<_mvo_> threshold: we have the binary avm stuff in linux-restricted-modules now
<_mvo_> it works pretty well on my test-machine
<threshold> a great
<dholbach> ogra: hehe: i read  MontyPython  instead of  MotuPython  on the wiki
<threshold> will have a look, thanks :)
<ogra> heh
<threshold> _mvo_: does it work with non avm cards, like say a winbond 6692 ?
<_mvo_> threshold: unlikely :(
<threshold> bleh...i've been trying to get hold of the mISDN authors about this, they seemed to have disappeared!? it worked fine in 2.6.9...don't know what happened
<_mvo_> threshold: I had the same problem with the mISDN avm drivers. worked fine in 2.6.9, exploded in 2.6.10 
<_mvo_> and no feedback from upstream
<sivang> hey _mvo_ 
<threshold> _mvo_: did it say that avmfritz.ko was missing at all? i had that problem with my w6692pic.ko
<_mvo_> threshold: no, it just OOPSed in the kernel and refused to work
<threshold> mm, strange
<pitti> elmo: uw-imapd sync, please
<Mithrandir> pitti: did I ask you about putting http://arch.err.no/index.cgi/tfheen@idi.ntnu.no--2005/pkg-glibc--multiarch--0--patch-2?cmd=cs_new&file=debian/patches/99_multiarch-ld.dpatch in our glibc?
<elmo> pitti: eh, source pkgs ples?
<sivang> does anybody know if gtk-gnutella ir v0rked? I installed in and the binary executabe line has "/usr/bin"
<zul> dilinger, no been working on patches to push to fabbione 
<mdz> doko: ping
<pitti> elmo: sorry, uw-imap
<elmo> pitti: ok to overwrite ubuntu changes?
<pitti> elmo: huh, wait; I don't see an Ubuntu version number
<elmo> meh, neither do I
<pitti> elmo: I see 7:2002edebian1-5, debian has a -6 with security fix
<pitti> ok :-)
<elmo> there clearly isn't enough caffiene in the world to make me non-stupid today
<dilinger> zul: alright, i'm going to start working on it, then.  if you have anything useful, please send; it'd be appreciate
<dilinger> d
<zul> dilinger: sure
* pitti hands elmo a biiig cup of black tea
<sivang> pitti: I should switch my caffeine with black tea sometime
<sivang> soo
<sivang> soon
<sivang> :)
<pitti> mdz: shall I file a bug about the live cd having no /etc/timezone?
<pitti> mdz: or do you already know/fix that?
<mdz> pitti: what should be in /etc/timezone on the live CD?
<pitti> mdz: the timezone that matches the region I chosed in the installer
<pitti> mdz: isn't that possible?
<mdz> pitti: no, not really
<mdz> pitti: in the US we have 4 time zones :-)
<mdz> more if you count alaska / hawaii
<sivang> hehe
<elmo> Kamion: so what location info do we get out of the hoary in the installer?  enough to map to a .$cc style TLD ?
<pitti> mdz: could it be done the same way as for normal installs?
<pitti> mdz: i. e. ask for the tz?
<mdz> pitti: for normal installs it asks a question
<mdz> I think that's unreasonable for a live CD
<mdz> for some reason, a lot of people have noticed this about the live CD
<mdz> and I find that very puzzling
<mdz> because every live CD on the planet must work this awy
<mdz> certainly the Warty live CD did
<pitti> mdz: yes, because it is confusing to have a wrong time
<mdz> but no one seemed to notice until the hoary live CD
<pitti> mdz: my local time differs to UTC only by 1 hour
<mdz> perhaps we should remove the panel clock
<Kamion> elmo: easily
<pitti> mdz: so the time displayed seems to be reasonable
<pitti> mdz: thus people tend to miss appointments :-)
<pitti> mdz: (this is what happened to me during the time when the tz was broken in hoary install)
<Kamion> elmo: I can do pretty much arbitrary stuff in choose-mirror; it uses a scary hack where it translates the default value of the debconf template from "GB" to "IL" or whatever
<Kamion> although it really should do something country-based instead, not sure if I can do country as well as language but I can certainly try
<Kamion> I guess Description-en_US: would work
<mdz> pitti: I don't think that is a major issue for the live CD, but the best we could do would be to remove the clock from the panel
<mdz> pitti: date(1) displays the time zone at least, but the panel clock is almost guaranteed wrong
<pitti> mdz: okay; actually I just wanted to check whether it's a bug or a "feature" :-)
<infinity> mdz : Display the timezone on the panel clock by default, then.
<infinity> (How does it get the right time?... ntpdate after the network is up, or something?)
<elmo> Kamion: hmm, confused?
<infinity> Cause if you're assuming a network, there are hordes of IP->location mapping databases out there you could use to get the TZ right for 99% of cases.
<Kamion> sigh. note to self, when doing a test build, wait to make sure that the build completed successfully before uploading
<Kamion> elmo: ?
<elmo> Kamion: I lost you when you started talking about Description-en_US :)
<Kamion> elmo: just thinking out loud really
<mdz> Kamion: need to talk with you and amu and haggai about Kubuntu
<mdz> Kamion: when would be a good time?
<Kamion> mdz: tomorrow morning your time?
<Kamion> after whatever meeting it is this week, maybe
<elmo> Kamion: ok, I've created *.archive.ubuntu.com - could you change the installer to use $cc.archive.ubuntu.com in place of plain archive.u.c?
<pitti> mdz: do you plan to install some language packs on the live cd?
<Kamion> elmo: ok, will have a look tomorrow
<elmo> Kamion: neat, tnx
<Kamion> (I'm more or less done for today I think)
<mdz> Kamion: this week we have a double-header
<sivang> does anybody know how we make colored table header in our zwiki?
<sivang> never mind
<mdz> Kamion: mind if I copy your graphical installer bullet points to the wiki?
<dholbach> sivang: maybe the guys in    #ubuntu-doc    know
<sivang> dholbach: I think I found it ;)
<mdz> gah, some spam just tried to subscribe me to the lvm2-cvs list
<dholbach> mdz: imagine you had a "i'm on vacation"-responder turned on... 
<elmo> Kamion: do you care where the trace file goes?
<pitti> thom: did you read about the homograph phishing attack?
<thom> pitti: yes
<thom> and i wept
<elmo> Kamion: for releases.u.c in particular 'trace' and/or 'project' are going to stand out
<pitti> thom: scary, right? :-)
<thom> pitti: scary; and the only "fix" is to turn off IDN entirely
<pitti> thom: yeah, that'd be a nice quickfix
<pitti> thom: the most embarrasing thing is that IE is not affected :-(
<thom> pitti: but that breaks more than it fixes
<pitti> thom: does it?
<thom> pitti: it's not affected because it doesn't support IDN at all
<pitti> thom: since IE does not support IDN, it basically does not yet exist
<pitti> thom: right, that's what I meant :-) security throught obsolescence
<thom> pitti: there are plugins, and i don't think shmoo reviewed them
<Kamion> mdz: not at all
<pitti> thom: however, a real solution is indeed hard, because it's not a real bug
<Kamion> elmo: make it a dotdir and then it won't stand out
<thom> pitti: anyway, i certainly can turn it off. i don't think i want to in this case
<thom> pitti: yeah
<elmo> hmm, true, and everything must mirror those anyways
<pitti> thom: no, please don't turn it off right now
<pitti> thom: I just found this quite interesting and challenging to think about :-)
<thom> yeah; it's a hard one - i wonder what opera does for them to say "we implement IDN right and don't intend to change it"
<pitti> thom: well, as a matter of fact ffox and opera _do_ implement it right 
<pitti> thom: that's the hard thing :-)
<pitti> thom: maybe, in the long run, the Unicode maps should be altered
<pitti> thom: no not allow the same glyphs with two different numbers; but that's even harder
<thom> pitti: a hack solution might be for registrars to check and disallow people from registering domains that provide this kind of uncertainty (or ensure that the original owner gets them)
<pitti> thom: sure; obviously that hasn't been done for p"a"ypal.com 
<thom> yeah
<thom> i guess big companies will start reflex registering that kinda stuff
<website> hi to all
<seb128> elmo: gazpacho intltool syncs please
<seb128> elmo: and any reason to not drop gstreamer/gst-plugins/.... from the archive ?
<elmo> gst-player too?
<Kamion> pitti: isn't the architecture relevant in #6270?
<elmo> seb128: and kgst?
<pitti> Kamion: okay, I add it
<elmo> gar, hot-backup.py is fairly retarded
<seb128> elmo: hum. Let me find the list again
<seb128> I was just wondering if that was not removed for a reason
<elmo> seb128: no reason beyond me being crap
<Kamion> pitti: thanks
<seb128> elmo: k, the list is: gstreamer gst-plugins gst-player kgst
<seb128> thanks
<elmo> done
<seb128> thanks!
<Mithrandir> lamont: did you get any reponse from the ia64 bushes?
<lamont> Mithrandir: nothing fell from the bushes except regrets.
<Mithrandir> lamont: ok, thanks for trying
<lamont> Mithrandir: I added you to the queue for castoffs.
<Mithrandir> lamont: thanks a lot
<lamont> thom: you around?
<thom> lamont: oui?
<lamont> thom: any plan for a firefox upload anytime soon?
<lamont> http://lists.parisc-linux.org/pipermail/parisc-linux/2004-December/025419.html
<lamont> mind you - I haven't actually tested that at all...
<AndyR> lo ppl
<thom> lamont: good god, i'll take your word for it
<thom> lamont: i'll look later in the week
<thom> the pqatch looks pretty unintrusive though
<_d4vid> apt-get install synaptic
<_d4vid> Reading Package Lists... Done
<_d4vid> Building Dependency Tree... Done
<_d4vid> Some packages could not be installed. This may mean that you have
<_d4vid> requested an impossible situation or if you are using the unstable
<_d4vid> distribution that some required packages have not yet been created
<_d4vid> or been moved out of Incoming.
<_d4vid> Since you only requested a single operation it is extremely likely that
<_d4vid> the package is simply not installable and a bug report against
<_d4vid> that package should be filed.
<_d4vid> The following information may help to resolve the situation:
<_d4vid> The following packages have unmet dependencies:
<_d4vid>   synaptic: Depends: libapt-pkg-libc6.3-5-3.3 but it is not installable
<_d4vid> E: Broken packages
<_d4vid> why ?
<dholbach> sudo apt-get update
<dholbach> and then try again
<zul> _d4vid: #ubuntu is the support channel
<_d4vid> i use hoary
<_mvo_> thnx dholbach 
<dholbach> _d4vid: it's irrelevant, you'll have to update your package list manually or install update-notifier / update-manager which will do that for you -- atm libapt-* was in a state of transition, so you'll maybe have to wait a bit, to hit the mirror you're using and 1) zul is right: #ubuntu is the support channel and 2) it should never be necessary to write 15 rows of text for a question like "synaptic is not installable due to libapt-pkg-l
<_d4vid> =)
<_d4vid> ok
<_d4vid> thnx maybe
<dholbach> _d4vid: ok, bye :-)
<dholbach> oh sorry.
<dholbach> i read "bye" somewhere :-)
<dholbach> didnt want to send you out 
<lamont> firecall
<_d4vid> :p
<trulux> ajmitch: ping
<elmo> boggle, does lftp really parse html to do 'ls' ?
<elmo> (for http)
<infinity> Yup!
<infinity> How else would it work?
* elmo sobs quietly in the corner
<thom> (without dav, there's no other way)
<infinity> Mindreading isn't an option.
<infinity> It's actually a pretty neat trick.
<elmo> infinity: I thought there might be something sane like a command in the http proto :P
<infinity> I like reading cnn.com with lftp.  Much more navigable, when you can cd to each story.
<elmo> it's really not a neat trick, 'cos it means I have to bloody well parse html to get a dir listing
<infinity> Oh, you're trying to emulate lftp's behaviour?
<_d4vid> atm libapt-* was in a state of transition, so you'll maybe have to wait a bit ? how long.. ?
<_d4vid> 2 weeks ? 
<elmo> infinity: I want some way to check for what files are in a http dir, yeah
<infinity> (And no, http knows nothing of directory listings, that's why all webservers have their own HTML-formatted directory listings... It's not just to look pretty)
<infinity> Just parse on hrefs.
<dholbach> _d4vid: lets move to #ubuntu
<dilinger> holy crap, that works
* dilinger reads cnn
* infinity laughs.
<zul> dilinger: getting support in #ubuntu? usuaally yes
<infinity> I long ago crowned lftp "the coolest command line app evar" for various reasons, but this is definitely one of them.
<dilinger> infinity: so how do you get it to spawn links to read the article? :)
<ajmitch> trulux: yes?
<trulux> ajmitch: can we set up the todo list for mdz?
<trulux> I've finished my kernel work
<trulux> I'm able to work out it
<ajmitch> trulux: just a minute, I just got up :)
<trulux> ajmitch: OK :)
<ajmitch> trulux: so what are you wanting to work on?
<trulux> ajmitch: a TODO list
<trulux> ajmitch: on Ubuntu Linux wiki
<trulux> we need to get this done together for mdz and the other folks
<trulux> or i will kick myself :)
<ajmitch> why will you kick yourself?
<ajmitch> it can't really be worked on in ubuntu until the kickoff meeting for hoary+1 :)
<zul> Trulux: are you going to present it at the cc tomorrow?
<ajmitch> work on the SELinux page in the wiki then?
<trulux> ajmitch: yep
<trulux> zul: cc?
* ajmitch logs in
<trulux> I missed all the stuff
<ajmitch> community council
<trulux> I was in this dark room working on a few kernel patches and messing some exec shield stuff
<trulux> I see
<trulux> when it will happen?
<infinity> dilinger : Well, with lynx, you could do "cat story.html | lynx -stdin"
<infinity> dilinger : I assume links can do something similar.
<ajmitch> trulux: remember, feature freeze is in a day or two
<zul> trulux: 1600utc for the cc
<trulux> zul: ok
<trulux> I will try to get in it
<trulux> ajmitch: yes, I'm near exams in school
* trulux wants to be another big guy, but 15 seems to be the age appearing on his identity doc.
<trulux> :)
<dilinger> infinity: sadly, links lacks a -stdin, and elinks' -stdin is broken 
<zul> later
<trulux> ajmitch: ok, http://pearls.tuxedo-es.org/patches/sys_chroot_lsm-hook-2.6.11-rc3.patch <- finished
<trulux> ket's work on the wiki page
<trulux> but first, shower
<trulux> I don't want to stink
<jbailey> jdub: Caught your blog a moment ago.  Do you want a quick fix for DSDT replacement on your laptop?
<ajmitch> that's a fairly simple looking patch
<ajmitch> hey jeff :)
<jbailey> Heya Andrew. =)
<sivang> hey jbailey 
<trulux> ajmitch: yep, it's pretty simple
<jbailey> Hi sivang 
* lamont goes to fetch kids - back in a while
<jdub> jbailey: we have DSDT-attached-to-initrd now
<jbailey> jdub: Yup.  I thought perhaps you didn't know that.
<jdub> jbailey: i was referring to the painful period that we didn't have it
<Hwolf> Guys; I can't get OO.o to run, and I can't get 00o2 to churn out nice .doc files that I can work on while at school. :-S
<jbailey> jdub: The next initrd-tools upload will have trivial support built in for it.  I'm beating my head against some FD logic in there, but I'm hoping that'll be finished tonight or tomorrow morning.
<jbailey> jdub: After that /etc/mkinitrd/DSDT will always get added on.
<jdub> tops
<jdub> was going to hack that up myself
<jdub> hooray for not having to write perl
<jbailey> Xu's shell scripting only looks like Perl.  It really is shell, though.
<jbailey> I'm just running into a funny problem where when I paste the code in, it overwrites the first part of the file.
<Hwolf> Is openoffice broken?
<elmo> jbailey: try his awk (apt-move)
<jdub> mdz: there?
<infinity> Better yet, don't!
<jbailey> elmo: I suspect the drug required for that are not yet legal here.  I'll look in a few months.
<jbailey> +s
<jdub> haha, mkinitrd is shell
<jdub> man
<mdz> jdub: yes, but need a typing break
<mdz> jdub: call?
<jdub> oh
<jdub> if you have lots to talk about
<dholbach> hmmm, how i can tell sbuild, not to look for non-free in hoary .... hmmm
<jdub> mdz: just wanted to quiz you about building alternative images with casper (ie. not isolinux images designed for cd)
<mdz> jdub: with debian-cd, you mean?
<jdub> mdz: or an alternative tool, if required
<jdub> mdz: example, i'd like to put a live image on my CF card
<jdub> or USB key
<jdub> etc.
<mdz> yeah, I'm not sure what that should look like yet
<mdz> I don't think we want to distribute fixed-size images like we do for CDs
<mdz> if not for the boot loader requirement, it could just be a tarball
<Kamion> mdz: hm, actually tomorrow might not be so good for the you/me/amu/haggai Kubuntu meeting; can we make it Wednesday instead?
<Kamion> mdz: see how d-i builds hd-media images
<sivang> jdub: do you have an idea why gucharmap doesn't have an Help->About dialog although it has one in the code? I think it has something to do with "..#if HAVE_GNOME" directive..:)
<jdub> it doesn't even have a help menu
<jdub> dunno, perhaps it's not built against gnome?
<jdub> it should be using GtkAbout now anyway
<sivang> jdub: oh well, it's using gnome-about.c according to my understanding of the code..
<jdub> should as in "it ought to be ported to"
<magnon> ok, scary. upgrading server tonight
<sivang> jdub: hrm I'm sorry, could you explain what you mean by "built against gnome" ? 0:-)
<mdz> Kamion: wednesday at a time which is not close to 2000 UTC
<jdub> sivang: it may have an optional libgnome depends
<jdub> mdz: oh, dude, also, i have good news
<sivang> jdub: ah!
<mdz> Kamion: how does d-i build hd-media images?
<sivang> jdub: tnx
<jdub> mdz: the polypaudio issue was entirely default configuration b0rk
<jdub> mdz: the alsa config lines were broken, but i hadn't used those previously
<jdub> it is working very well here
<Kamion> mdz: earlier than 2000 UTC is rather better for me anyway
<jdub> i watched a full DVD with synchronised sound
<jdub> there are some CPU utilisation issues, but i'm talking to lennart about those
<Kamion> mdz: more like 1730-1800 UTC
<neofeed> would I fill live cd request via Bugzilla too? I just figured the LiveCD's miss buffer :/
<Kamion> mdz: depends on the architecture; it builds a bootable filesystem of (some size), puts the kernel/initrd/bootloader/etc. on it, and leaves instructions for how to slot another file in
<jdub> Kamion: (btw, are both OEM and graphical doable in the hoary+1 timeframe?)
<Kamion> mdz: in d-i you'd slot in an .iso and use iso-scan to find it, but no reason it couldn't be a cloop if you can figure out how to make casper find the filesystem
<mdz> neofeed: I don't understand the question
<mdz> Kamion: let's say 1800 UTC
<Kamion> mdz: ok, that's fine
<sivang> jdub: totem has an audio latency problem over my system (when watching DVD), polyaudio would address this?
<neofeed> mdz, well when using LiveCD's for example to mirror HD's over the network or do other stuff. I usually use the tool 'buffer' but that's not on the LiveCD's so where would I complain about that? bugzilla too?
<jdub> sivang: yes
<Kamion> jdub: honestly haven't thought about it much, but probably yes if for no other reasons than (a) I'll go insane doing just graphical installer for six months and (b) I expect to have to draft other people in to help anyway
<mdz> neofeed: there is no need to ask us for it; you can simply install buffer on the live CD using synaptic, apt-get or aptitude
<sivang> jdub: yay
<Kamion> if he's amenable, I'd like to ask Mithrandir to help with the cdebconf extensions
<sivang> neofeed: follow the livecd customization howto, on the wiki
<jdub> Kamion: cool
<jdub> neofeed: apt-get install buffer :)
<jdub> neofeed: unless you really regularly need it ;)
<sivang> jdub: err, right sorry :)
<neofeed> jdub, well withought network that's not so easy :)
<jdub> that is problematic
<jdub> usb key + package?
<sivang> neofeed: if you want to make youserlf an iso of the livecd with buffer in it, then read the livecd docs
<mdz> neofeed: the live CD can't attempt to provide all of the packages that anyone could want; there are just too many
<mdz> neofeed: and in particular it is limited to officially supported software
<neofeed> dun have a usb key but got a set of koppix cd's with me so.. it worked out. but would just have been nice to see the livecd's come with this small package.
<jdub> that's what the LiveDVD is for ;-)
<mdz> neofeed: as sivang says, it is easy to create your own custom Ubuntu live CD with extra packages
<mdz> jdub: I had planned to put exactly the same cloop image on the DVD as the CD
<sivang> jdub: I thought the LiveDVD was about world domination no? :)
<jdub> mdz: yes, that is the live/install dvd
<jdub> mdz: at some stage, we should just go completely bonkers and make a LiveDVD :)
<mdz> jdub: I don't think it's even worth trying to install all of universe :-)
<mdz> jdub: just read the DeMuDi thing, rad!
<jdub> yeah, only a very light first step though
* sivang wonders what's DeMuDi
* mdz wonders if sivang also wonders what google is ;-)
<jdub> heh
<Kamion> jdub: what, install all of supported with all the daemons? ;)
<jdub> Kamion: we have a strict no-listening policy, but bugger that for the livedvd! :)
<mdz> why don't we just bind a root shell to port 23?
<magnon> awesome idea
<dilinger> if you want to attract users to ubuntu, that's the way to do it
<jdub> no one will suspect it on that cleverly hidden port
* dholbach giggles
<dilinger> i mean, they won't be the users who are supposed to be using the machine, but.. users are users, right?
<dholbach> gparted on the LiveCD would be nice
<dholbach> coming to that... who has the time to sponsor 2 uploads? :-)
<Kamion> is anyone sorting out l-r-m for the new kernel ABI? an installable CD tomorrow would be nice
<jdub> daniels most likely will today
<jdub> it is 1000
<jdub> Kamion: is the kickstart stuff testable?
<mdz> dholbach: I thought that the feedback (from you or ogra?) was that gparted was Not Ready Yet
<dholbach> mdz: it was my fault... i blamed umounting-vfat on gparted
<dholbach> mdz: when i clicked on umount vfat my system froze, but fabbione pointed me to a bug on b.u.c 
<robertj> mdz: I think I got that patch straightened out, mentioned it on debian-devel, and ... nothing seems to have happened, should I look for a MOTU to assign it to?
<mdz> robertj: bug #1849 is already assigned to Kamion, but he is very busy, please be patient
<mdz> robertj: I think the only blocking issue is deciding on the name of the group :-)
<robertj> ok, just wanted to make sure I had done my part ;)
#ubuntu-devel 2005-02-19
<mdz> yes, thanks for the patch
<mdz> things are a bit crazy just before feature freeze
<robertj> yeah, understood
<jdub> mdz: this accessd thing, is it sane?
<mdz> jdub: is that the thing that we talked about in Spain?
<mdz> I think so
<mdz> it sounded vaguely reasonable
<jdub> i would like to not run things like update-manager and synaptic as roon
<jdub> t
<jdub> but have them run little subprocesses to perform the operation
<mdz> things like update-manager and synaptic are going to be a lot of work to privilege-separate
<jdub> (same as g-s-t stuff)
<jdub> (though g-s-t will be easier)
<jdub> if synaptic is done, update-manager will just inherit that though, right?
<mdz> haggai: ping?
<pitti> night everybody
<dholbach> sleep tight, pitti
<dholbach> i better had not tried, if wesnoth-0.8.10 compiled ... now i'm left with it on my hard disk :-)
<mdz> jdub: can you weigh in on #6092?
<jdub> mdz: *shiver*
<mdz> jdub: there is so no reason to mess with that in the desktop
<netdur> hey, open Synaptic -> settings -> repositories -> try close the dialog by clicking the [x]  (and not cancel button), watch the bug!
<tseng> netdur: bugs typically go to bugzilla.ubuntu.com
<netdur> need to register right?
<tseng> yes.
<tseng> also, i dont see a bug
<jdub> BUT PERKY!!! THAT IS THE BUG!!
<netdur> you mean get normal window and not false-sensitive window?
<sivang> jdub: I see you joined mdz oppinion, well, I'll mask it out of the gui tommorow then? (change the interface file and the reference for that field in the code)
<sivang> jdub: (talking about 6092)
* sivang heads off for the night
<dholbach> re
<luis_> jdub: do you understand your panel packaging at all?
<luis_> (or anyone else, I guess ;)
* luis_ is trying to figure out where gconf key /apps/panel/default_setup/objects/ comes from
<lexhider> #ubuntu
<luis_> because it looks like in my hacked up livecd, the value is getting overridden
<jdub> luis_: yes, it is
<jdub> luis_: the schema is installed when the package is configured
<jdub> luis_: it is a hacky way to get a default panel layout appropriate for laptops or desktops
<jdub> luis_: have a look at /var/lib/dpkg/info/gnome-panel-data.postinst
* lamont gets email from Wietse telling him that aside from the bloat issue, there's no benefit to shipping a TLS-disabled postfix.
<luis_> jdub: so the package is getting reconfigured at install time, even on the liveCD?
<jdub> luis_: it's being reconfigured by casper during boot
<luis_> ah, cool
<luis_> thanks for the pointer
* luis_ will go and fixificate
<jdub> luis_: we do that so the livecd has the same smarts
<luis_> yeah
<luis_> makes sense
<luis_> just surprising
<jdub> yeah ;)
<luis_> would something similar be rewriting my /usr/share/applications/defaults.list at boot time?
<jdub> hmm, dunno about defaults.list, but it sounds plausible
* luis_ needs to test that one a little more thoroughly
<luis_> I think maybe there is something funky going on there with links and mounts and loopback stuff
<mjg59> BLUETOOTH IS MAKING ME CRY
<jdub> ladies and gentlemen
<jdub> would you please put your hands together
<dholbach> mjg59: what are you doing?
<jdub> for mister matthew "www.angrydpl.com" garrett
* HrdwrBoB applauds
* helix golf claps
<mjg59> dholbach: I have a PDA that runs Linux. I have a headless Linux box with a bluetooth dongle.
<jdub> (especially anyone who loves their working acpi love in hoary)
* infinity can't wait for Matt to win.
<mjg59> I want to get the PDA to do networking via the headless box.
<mjg59> Which I think means I need to pair the two devices.
<dilinger> mjg59: i found bugging edd dumbill to be a decent way to deal w/ bluetooth problems.  especially where "problems" are a lack of documentation
<mjg59> Haha
<helix> maybe mjg59 will revolutionize bluetooth on linux as a result of his frustration
<mjg59> Everything I can find on pairing seems to assume that I'm running X
<mjg59> WHERE THE FUCK'S MY FUCKING TRAIN?
<dholbach> mjg59: erm the bluez-utils and bluez-hcidump are not assuming you're running X, are they?
<mjg59> dholbach: bluez-pin is linked against X libraries
<infinity> dilinger : Your new and improved patch is now in incoming.
<dholbach> mjg59: oh sorry... i didnt know :-/
<dilinger> infinity: i should be afraid, eh?
* dilinger saw the php4 pcre bug that just got closed
<infinity> Yeah, I've been cross-closing all day.
<infinity> php4 bugs with apache, apache bugs with php4.
<dholbach> i don't know if this should make me either laugh or cry: "Any leftovers will be placed at the Bookmakers on whether     Longhorn or Sarge release first."
<mjg59> Ah. If I turn off authentication and encryption, they can at least ping each other
<dilinger> yea, i had to turn of encryption for hidd
<dilinger> s/of/off/
<mjg59> Less than ideal, but better than nothing...
<mjg59> Rock
<dholbach> i'm off to bed
<dholbach> good night
<magnon> there we go. server on ubuntu
<luis_> jdub: ah-ha
<luis_> jdub: turns out that since usr/share/applications/defaults.list is a symlink to _/_etc/gnome/defaults.list, what i was doing when i was editing the file on the livecd was actually editing my machine's defaults, and never touching the livecd.
<mdz> wow, today is live CD bug day
<thully> speaking of live CD bug.. I filed a pretty large one about a week ago which makes things tough when you try to use the live CD on a system w/a wi-fi card but not in range of a network - have you seen this one yet?
<thully> Bug #5981
<mdz> daniels: ping?
<luis_> mdz: I'm trying to arrange one for gnome for LWE, which means I'm running out of time :0
<luis_> :), I mean
<luis_> fucking broken shift key
<mdz> luis_: yeah, jdub mentioned, sounds very cool
<luis_> yeah
<luis_> I think the 2.10 one will be a learning experience, mostly
<luis_> I expect the 2.12 one will rock
<luis_> and hopefully it will get the artists heavily involved too :)
<mjg59> Oh man
<mjg59> Bluetooth is love
<elmo> 00:35 < mjg59> BLUETOOTH IS MAKING ME CRY
<elmo> 01:19 < mjg59> Bluetooth is love
<luis_> dude
<luis_> schizophrenia is love
<dilinger> elmo: s/angrydpl.com/bipolardpl.com/
<mjg59> It turned out that it was gpe that was making me cry
<mdz> gpe does that
<mjg59> Now gpe is making me cry again
<mjg59> It's broken dbus
<mjg59> Waah my dbus session bus has vanished
<mdz> elmo: what happened to your "fist-sized blurry icons" bug?  #6268 is a duplicate of it, but I can't find it
<mdz> I think it was you, anyway
<elmo> mdz: I never reported it as a bug, I just whined about it on IRC and got the (err, confused) impression it was a feature 
<mdz> ah
<elmo> you may remember it 'cos it's on the quotes page
<mdz> probably
<luis_> Rock on.
* luis_ has an epiphany-defaulting liveCD now
<luis_> thanks, all
<lamont> mdz: I think shtoom-in-universe was waiting for the official debs
<lamont> as evidenced by the 'you may need to remove it manually before installing the official deb' comment... :-)
* lamont screams at 'stars'
<mjg59> Bluetooth is worse than paedophiles
* ajmitch spots the linux australia agm log
<lamont> firecal
<mdz> lamont: who is making the official debs?
<lamont> thom ITP'ed it
<dilinger> mjg59: certainly would be nice if ubuntu made dealing w/ bluetooth easier
<mdz> dilinger: if it weren't two days before feature freeze, I would agree
<mdz> daniels: ping?
<mjg59> Phew. Bluetooth love once more.
<zul> hey
<daniels> mdz: pong
<mdz> daniels: morning
<mdz> daniels: you have a xorg -1ubuntu16 upload planned for pre-feature-freeze, right?
<daniels> mdz: yeah
<mdz> daniels: I thought you said you fixed LiveCDCustomizationHowTo?
<mdz> do you have some notes from when you went through it?
<daniels> mdz: i haven't fixed it, no, but I can
<mdz> please do; people are tripping over it
<mdz> luis_: did you use the  LiveCDCustomizationHowTo?
<mdz> luis_: ah, you made many corrections already, thanks
<daniels> mdz: ok
<luis_> mdz: yeah, it is great
<luis_> mdz: had some issues, but I polished it as much as I could
<luis_> mdz: I'll add a gnome customization section at some point?
<luis_> (if you guys want that)
<mdz> luis_: what sort of gnome customization?
<mdz> luis_: as part of the same howto, or a separate one?
<mdz> the sources.list stuff doesn't make much sense
<luis_> mdz: I was thinking mostly of gconf
<luis_> the more obscure stuff (like the sources.list stuff) should probably just get linked to the gnoppix page
<mdz> luis_: I think specific customizations should probably go in separate howtos, linked from this one
<luis_> I was thinking gconf is non-specific enough, but judgment call for you guys
<mdz> luis_: if you can find a way to organize it which preserves the simple, linear process, then sure, I've no problem with it
<mdz> but that seems tricky
<mdz> ideally it should be separated into the completely generic bits, and actual examples of customization
<mdz> "installing custom packages (skip this section if you aren't doing that)"
<mdz> "customizing gconf (skip this section if you aren't doing that)"
<mdz> something like that?
<luis_> makes sense
<mdz> so that the less generic bits can be easily excluded and the next step is pretty obvious
<mdz> daniels: I installed Hoary on a machine with a voodoo card yesterday
<mdz> daniels: is it at all reasonable to expect that to work properly?
<mdz> daniels: (it gave me 640x480)
<daniels> mdz: utterly reasonable to expect it properly; if ddcprobe succeeds but doesn't shoot you back a sync range, it's one of the bugs fixed in ubuntu16
<daniels> which, given it's now tuesday, might well be 6.8.2-1
* jamesh hates how gksu grabs the keyboard/mouse
<mdz> daniels: whichever way it goes, please make sure it's in before featurefreeze
<mdz> jamesh: do you know a better way?
<daniels> mdz: yah
<jamesh> mdz: I don't think it provides any added security.
<jamesh> mdz: if I can connect to your X server, I could just as easily present a window that looked like gksu
<daniels> mdz: things that fuck the installer up royally: having your date set to 2003; the gpg keys are all invalid because they have been created after that
<mdz> jamesh: I consider it a safety feature more than a security feature, per se
<mdz> jamesh: it avoids the "oops, typed my password into the (gaim|xchat|etc.) window which just grabbed focus"
<jamesh> mdz: well, it sometimes grabs the keyboard when it isn't focused by the window manager, which is just as bad
<jamesh> which can happen with metacity's focus stealing prevention feature
<jamesh> eg. run gksu and then run another application that opens its window before gksu
<daniels> mdz: is there any way to disable that specific horkage in gpg?
<mdz> daniels: which specific horkage?
<mdz> jamesh: that focus stealing prevention feature seems to also prevent me getting focus when I want it
<daniels> mdz: see 'things that fuck the installer up royally'
<jamesh> mdz: the idea is that if you start an application, then do something else before it loads, you probably don't want that application to grab focus
<jamesh> which is correct in 99% of situations
<mdz> daniels: oh, interesting
<mdz> daniels: gpg --ignore-my-clock
<mdz> jamesh: I have had a _lot_ of gaim windows, notification dialogs and such appearing behind another window
<mdz> and so I never see ther
<daniels> ah, --ignore-valid-from
<mdz> them
<mdz> anyway, have to run
<daniels> mdz: can we get --ignore-valid-from for validation?
<mdz> daniels: I will be in the vicinity of that voodoo box shortly; I may come back and nag you about it
<mdz> daniels: probably, talk to Kamion when he wakes up
<daniels> mdz: ok, thanks
<daniels> Kamion: ping
<jamesh> mdz: if an app is popping up a new window it should be setting _NET_WM_USER_TIME to the timestamp of the event that triggered it
<jamesh> mdz: if gaim set that prop on its popups to the last known event timestamp when you received a message, then they should get focus.
<jamesh> (or get the current time from the server)
<helix> doh, missed jbailey
<pvh> Can anyone suggest why I might not be able to call up the man page for fork()?
<daniels> sudo apt-get install manpages-dev
<pvh> Phew, thanks.
<QQMelo> hi
<QQMelo> can i ask ?
<daniels> oh my god.  this s3 card really is horrid.  it doesn't even do ddc.
<fabbione> morning
<fabbione> wtf...
<fabbione> it's impossible to rsync from archive.u.c
<fabbione> mdz: ping
<fabbione> daniels: you around?
<pitti> Good morning Ladies, Gentlemen, Aliens, etc.!
* fabbione shows his greenish skin to pitti
* pitti offers fabbione his third hand to help
<ajmitch> hello pitti, fabbione 
<pitti> hi ajmitch 
* fabbione waves with his 7 fingers
<fabbione> dpkg-source: building linux-source-2.6.11 using existing linux-source-2.6.11_2.6.11.orig.tar.gz
<fabbione> let's add some extra crack
<Treenaks> 2.6.11-final?
<fabbione> no
<fabbione> i said CRACK
<Treenaks> ah ok
<fabbione> it's a bk snapshot
<lamont> well, that was a cluster
<fabbione> lamont: ?
<lamont> the last 5 hours... at least 9 accidents on the interstate
<fabbione> ah
<lamont> the real pisser was having _MY_ENGINE_ rear ended
* fabbione tries to picture that
<HrdwrBoB> your engine?
<HrdwrBoB> it was sitting on the road?
<lamont> yep.  parked about 2/3 of the way into the outside lane of the interstate, protecting us while we dealt with a patient who had just rear-ended a lory
<lamont> and along comes this puny little toyota and trashed itself on my bumper.
<fabbione> fuck...
<fabbione> that sucks
<lamont> fire engine didn't move positions at all.  rocked around abit/.
<lamont> fabbione: it'll need a new bumper, and we'll have a challenge or two getting a couple of things out in the meantime, but it's still in service.
<HrdwrBoB> that's crazy
<lamont> but I expect to get an "award" for it next year.
<lamont> sheet of ice - very slick... been a crazy evening
<HrdwrBoB> crazy
<lamont> starting just short of 6 hours ago
<HrdwrBoB> we had floods last week
<lamont> oh  -  and all those accidents were in a 1 mile stretch of highway
<lamont> parking is getting a little congested. :-)
<HrdwrBoB> heh
<mdz> fabbione: pong
<fabbione> mdz: i am preparing 2.6.11 (from bk snapshots), but last time we talked about it you had some comments about the orig and the patches...
<fabbione> mdz: i just can't remember exactly about what...
<fabbione> the idea was to have a 2.6.11.orig.tar.gz based on 2.6.10
<fabbione> and add the rest as patches..
<lamont> did anyone get my mail to ubuntu-devel wrt "MTA in ubuntu desktop"?
<fabbione> lamont: not yet
<lamont> Feb  7 19:04:42 mmjgroup postfix/smtp[24196] : A517516EAE: to=<ubuntu-devel@lists
<lamont> .ubuntu.com>, relay=lists.ubuntu.com[209.61.182.217] , delay=1, status=sent (250
<lamont> OK id=1CyKk6-0007O0-EN)
<lamont> hrmpf.
<fabbione> aren't the ml moderated?
<lamont> could be.
<lamont> and if I guessed the wrong email on my submission...
<lamont> where's our moderater, eh?
<fabbione> iirc your address has to be subscribed or approved by Jeff
<lamont> hrm.. should be his midday... jdub???
<mdz> fabbione: whatever works best for you
<fabbione> mdz: ok. i am going to the 2.6.10 orig + patches
<fabbione> mdz: it is easier to track
<fabbione> because there will one stolen-from-head or update2-2.6.XX patch on top
<fabbione> and the other afterwards
<mdz> lamont: moderated
<fabbione> also because after the first orig patching, all the others will still have to live in debian/patches
<mdz> jdub: ping
<fabbione> lamont: mail just arrived
<mdz> fabbione: I moderated it
<lamont> mdz: tahnks
<fabbione> oh nice... 
<fabbione> only 16 patches to review for 2.6.11
<lamont> mdz: wondering if stars belongs in multiverse, or yale belongs in universe...
<lamont> (stars build-deps yale, but yale is multiverse)
<mdz> lamont: weird, how did that happen?
<Kamion> daniels: I can fix the installer's invocations of gpgv, but somebody will need to add --ignore-time-conflict to apt's invocation of gpgv
<lamont> maybe stars is contrib?
<mdz> Kamion: if there isn't already an apt config option to pass arbitrary parameters to gpgv, there should be
<mdz> lamont: ah, maybe
<daniels> Kamion: cool
<mdz> lamont: if stars came from contrib, it should move into multiverse
* lamont looks
<Kamion> mdz: there isn't
<mdz> Kamion: please file a bug, assign to mvo
<lamont> mdz: stars is main in sarge contrib in sid
<lamont> gah
<lamont> main in sarge, contrib in sid
<lamont> so yeah, it should move to multiverse
<mvo_> Kamion: sorry, missed the first bit. what is the problem?
<Kamion> mvo_: daniels reported that installs fail due to his clock being set to 2003, which means that gpgv reports the signatures as invalid due to being from the future
<lamont> mdz email sent, cc you et al
<Kamion> mvo_: I'd like to make the installer always use gpgv --ignore-time-conflict to fix this; it's probably not a problem outside the installer because ntpdate gets run etc.
<mdz> mvo_: basically, we need a new config parameter in apt to pass options to gpgv
* lamont sleeps
<mdz> Acquire::gpgv::options
<Kamion> mdz: bug #6283 filed with excerpt from this conversation
<mvo_> Kamion,mdz: right, thanks
<jdub> mdz: pong
<mdz> jdub: good meeting with cliff tonight, can we do a conference call in ~20 hours?
<Kamion> daniels: debootstrap and net-retriever fixed, anyway
<daniels> Kamion: thanks dude
<fabbione> daniels: l-r-m?
<jdub> mdz: hrm
<jdub> mdz: sounds handwavingly okay
<mdz> jdub: if you need a different time, reply to cliff's mail
<jdub> mdz: so not 4pm thursday?
<daniels> fabbione: yeah, am doing that now
<Kamion> I'll roll new CDs when new l-r-m appears
<Kamion> I expect to be blocking on it today though
<fabbione> Kamion: i think we also need a new linux-meta
<daniels> fabbione: just had to go to the shop and buy a new video card, because I was stuck with heaps of crappy PCI cards (only have PCI and PCIE, got a new card on order)
<daniels> fabbione: the ones I had were all 4MB and didn't do DDC
<mdz> jdub: oh, right
<fabbione> daniels: that's becasue -au hw sucks :P
<mdz> jdub: I have no idea what day it is
<Kamion> fabbione: yes
<mdz> jdub: anyway, I got him all set up so that he can do artwork development
<Kamion> fabbione: (I can do that if nobody beats me to it)
<jdub> mdz: cliff suggested a different time ;)
<daniels> fabbione: don't speak too soon, kid -- i have the best video card on the planet on order
<mdz> jdub: I thought today was tomorrow
<mdz> jdub: ignore me
* mvo_ chuckles
<haggai> mdz: pong
<haggai> mdz: finally nailed an OOo bug and will get to mail backlog today
<mdz> haggai: hey, you're alive :-)
<haggai> mdz: just :)  both of us came down with a bug from my wife's new workplace
<mdz> haggai: need to talk with you/Kamion/amu about Kubuntu very soon, today if possible
<jdub> morning Keybuk 
<Keybuk> morning
<mdz> Keybuk: any objections to moving the tech board meeting time?
<haggai> mdz: ok, I'm going to be out for much of the evening (UK), I guess you need a time sometime then?
<Keybuk> mdz: no major ones
<mdz> haggai: when can you be available?  should be less than an hour
<mdz> Keybuk: ok, I'll announce it then
<Kamion> mdz: I would like it to finish before 19:00 UTC, because I want to be elsewhere at 19:40; is the tech board meeting slot now free?
<mdz> haggai: we'll be straightening out what needs to get done in order to start producing Kubuntu CD images
<mdz> Kamion: tech board meeting slot is now free, but that's a week from now
* haggai would be able to be there until 19:00 UTC too
<fabbione> Kamion: up to you, but i would wait l-r-m first
<mdz> we can meet at 1800 UTC
<mdz> amu: does that work for you?
<amu> mdz: yes, it's fine for me
<haggai> ok 1800 then
<ajmitch> hello haggai, haven't seen you round much lately
<fabbione> hey haggai
<fabbione> haggai: OO2 failed on sparc.. do you want the buildlogs?
<haggai> hi ajmitch, yes I've not been around for a few days and now I have a large backlog :(
<ajmitch> haggai: I had worked on some packages for universe that ogra started reviewing
<ajmitch> but then I became a DD & got busy uploading my packages to sid
<haggai> fabbione: uh, I guess so :)
<haggai> ajmitch: ah, that's cool
<Kamion> mdz: oh, d'oh
<sivang> morning all
<ajmitch> hi sivang 
<fabbione> haggai: to what email address?
<Kamion> fabbione: I intend to
<haggai> fabbione: chris.halls@credativ.co.uk
<Kamion> linux-meta's Maintainer: field is Herbert Xu, which should be changed. Who wants to volunteer?
<sivang> hey ajmitch 
<fabbione> Kamion: mdz :P
<Kamion> or I can just make it "Ubuntu Kernel Team <ubuntu-devel@lists.ubuntu.com>" or something
<dholbach> morning
<fabbione> Kamion: nah let's wait after this afternoon meeting
<Kamion> ok
<mdz> kernel team, certainly
<fabbione> haggai: mail on the way
<haggai> fabbione: kthx
<sivang> morning dholbach 
<dholbach> hello sivang!
<fabbione> elmo: we definetely need more rsync slots or to limit to one connection per ip
<fabbione> in the last 15 hours i couldn't connect once
<pitti> elmo: regarding #6206, it is required to remove various (but not all) mozilla-firefox-locale-* packages from Hoary and to replace it by mozilla-firefox-locale-all
<pitti> elmo: AFAICS it is required to do the removal before the new upload, right?
<daniels> Kamion: sorry, my i386 (with all my sources, and my gpg key) has given up the ghost now and is flat-out refusing to boot.  might be a couple of hours before l-r-m wings its way up from me.
<daniels> Kamion: (getting all the sources on to my laptop now, but it's taking a while)
<troll_god> there is a bug in the mplayer meta pkg, failed dependency libavcodeccvs has a ver number that is too great to be satisfied 
<pitti> Hi seb128 
<seb128> hey
<ogra> morning guys
<ogra> (and girls )
<pitti> Hi ogra 
<pitti> sivang: don't bother with moz-ffox-locale-he-il
<pitti> sivang: I'm already handling that now
<ogra> pitti: we will have to do some work together this week http://www.grawert.net/hal_lsb_info.png
<pitti> it'll be my pleasure :-)
<ogra> i got everything in, but i dont trust my c-fu, so you will probably need to correct my stuff...
<pitti> looks good
<pitti> ogra: just send me a debdiff against the current hoary version
<ogra> lol...yp, i know how to make my screenshots look good ;) even if the code is crap
<pitti> ogra: "Auen hui, innen pfui"?
<pitti> :-)
<ogra> pitti: mal sehn  ;) 
<pitti> ogra: is this one big patch or did you split it up?
<ogra> pitti: i wanted zto make one big one... but if you like it in piecmeal i'll d that as well
<pitti> ogra: if it makes sense to split it up, then it will certainly be better (also for upstream inclusion)
<pitti> ogra: e. g. one patch for a general /proc support and several patches for reading info out of it
<pitti> ogra: but if it does not make sense, just keep a monolithic patch
<ogra> pitti: i dont think we can convince upstream to use the dmi data....
<dholbach> hi ogra, hi seb128
<mdz> night all
<pitti> Night mdz
<ogra> pitti: the key values seem not no be standarized, so i wont be able to spec them....which will avoid inclusion by upstream :(
<mvo_> night mdz 
<dholbach> bye mdz
<ogra> night mdz
<Simira> helix :)
<Simira> night mdz
<helix> shh
<ogra> pitti: but lsb_reease, cpuinfo and meminfo should go upstream
* daniels screams.
<pitti> ogra: sure, then it will make sense to split that out
<daniels> my laptop's wireless is now in ARE-WE-THERE-YET? mode, where it flatly refuses to hold an association for more than two seconds
<pitti> daniels: saw a ghost?
<pitti> daniels: then you need to learn to work really fast :-)
<Simira> :D
<daniels> heh
<daniels> technology hates me today
* daniels waits for the amd64 to catch on fire.
* helix gives daniels civilized things like central heat and air
<pitti> daniels: /var/backups/pencil'n'paper?
<Simira> daniels: want my new, broken webcam as well?
<Treenaks> helix: "No pleasure, no rapture, no exquisite sin greater... than central air. " - Dogma ;)
<helix> that is SO untrue
<helix> the sin part, anyway
<Treenaks> helix: watch the movie, you'll understand ;)
<helix> yessir
<Kinnison> Hi
<Kinnison> seb128: ping?
<seb128> pong
<daniels> oh dear.
<Kinnison> Evo's threading has gone all shitty, is that a known issue?
<daniels> right, I think the northbridge on my i386 has died.
<Kinnison> daniels: ergh. New mobo time
<seb128> yep, known issue here and upstream
<Treenaks> Kinnison: I've heard other people complain about that..
<Kinnison> seb128: okay cool
* ogra hands over a soldering iron to daniels
<daniels> Kinnison: yeah
<daniels> Kinnison: but, otoh, I did just get this shiny amd64 up and going today ...
<Kinnison> Also, imap subscriptions appear to be a touch screwwy
<Kinnison> daniels: Mmmm amd64 shinyness :-)
<seb128> Kinnison: http://bugzilla.ximian.com/show_bug.cgi?id=72058
<Kinnison> seb128: thanks dude, you're a star
<seb128> np :)
<seb128> a guy is asking if we have a list of hardware configurations supported by ubuntu ?
<Treenaks> seb128: uh, I think I saw something like that on the wiki
<ogra> seb128: single devices and laptops are on the wiki.... no complete desktop systems though
<seb128> I know about the wiki, but that's not really an official list, that's feedback from users
<ogra> seb128: i'm working on the hwdb.... but the client is only a skeleton yet.... hoary+1 will have a nice hwdb.... promised ;)
<HrdwrBoB> heh ogra
<ogra> hey HrdwrBoB, i ve seen your wiki page... nice to meet you ;)
<Treenaks> ogra: I think he means something like "If you buy a Foocorp MegaDesktop, Ubuntu will be supported."
<seb128> yep
<ogra> Treenaks: yep... thats what the hwdb will do for us ;)
<Treenaks> ogra: (supported like "main" is supported, and "universe" is not)
<ajmitch> hi ogra 
<ogra> ajmitch: hi, i heard you are a DD now ?
<ajmitch> ogra: yes, that is right
<ogra> ajmitch: so some second MOTU/CC/TB should approve you right away now, i dont think that additional package review is necessary
<ajmitch> ogra: ok
<ajmitch> that sounds good to me :)
<ogra> ajmitch: to me too....but i already approved your ;) 
<ogra> so lets find some second one ....
<ajmitch> ok..
<ajmitch> hmm, haggai was around earlier
<HrdwrBoB> ogra: :)
<HrdwrBoB> ogra: cool :)
<ajmitch> I think it's a quiet time of day
<ogra> ajmitch: haggai is in uk..... its 10am there.....
<ajmitch> it's still quiet :)
<ogra> HrdwrBoB: already picked a package you like ?
<ajmitch> ogra: btw what's been organised so far for MOTUTeams?
<HrdwrBoB> not really, all the stuff I'm really interested in is mostly in main :)
<HrdwrBoB> so I'll grab random stuff
<Treenaks> ogra: I like the phpgroupware ones :)
<ajmitch> Treenaks: heh, I can help with phpgw :)
<Treenaks> ogra: I have to support them for a few small companies anyway.
<Treenaks> ajmitch: great :)
<ogra> HrdwrBoB: heh, same as i did....
<ajmitch> Treenaks: partly because I'm involved in phpgw upstream
<ogra> Treenaks: pick what you like ;) 
<ajmitch> tv has uploaded 0.9.16.005 to sid in the last couple of days
<Treenaks> ajmitch: does it include an apache2 config option?
<ajmitch> Treenaks: not that I'm aware of currently
<HrdwrBoB> ogra: I was going to do serpentine if that's not already covered
<ajmitch> but I haven't looked at the debs too much
<Treenaks> ajmitch: using the apache1 config file in apache2 works, but it's a bit hackish :)
<Treenaks> ajmitch: it shouldn't be too hard
<ajmitch> I'm too used to running from CVS
<ogra> HrdwrBoB:nope, not as far as i know....take it....(and add a hint to UniverseCandidates if you do)
* HrdwrBoB does so
<sivang> pitti: ok, cool, thanks alot!
<ajmitch> ogra: btw I'd like to get involved with the python & zope teams since I use them a bit - plone & zope cmf packages need synced to sid versions to be installable
<ogra> ajmitch: i would very much appreciate if we had a zope team...even if its only one guy currently....
<ajmitch> well I'll hunt around for another CC/TB/MOTU person who could approve me :)
<ajmitch> but I don't think I'll have much luck tonight
<ajmitch> I notice that a few of the python packages have been fixed up for py 2.4
<ogra> ajmitch: doko is our python god here.....
<ajmitch> ogra: yep
<daniels> thom: ping
<ajmitch> he's also the gcc wizard
<daniels> thom: actually, unping
<ajmitch> ogra: the python transition just needs to be managed nicely, there are a few uploaded now that I worked on last week :)
<ogra> ajmitch: sorry, that was my fault, i wanted to make a wiki page with a list of assigned packages with doko but ran out of time with the hwdb ....could you talk to him
<ogra> ?
<ajmitch> ogra: sure, but I don't know who the uploader is :)
<ogra> ajmitch: pretty sure doko....
* ajmitch looks for the email address
<ajmitch> charles majola
<ajmitch> he's been doing most of the universe python packages so far
<ogra> ajmitch: he (doko) probably only signed the upload....
<ajmitch> I'm just looking on the changes list
<ajmitch> via gmane
<thom> daniels: <ping cancelled>
<daniels> thom: was going to ask you about 4343, but I can do it on my machine now
<daniels> thom: (looked at the r300 programming guide, worked out what the bug almost certainly was)
<ajmitch> hello Kamion 
<daniels> Kamion: can you please do l-r-m?  i'm putting the disks from my i386 into the amd64 (it is completely, totally, utterly dead) now, so it might be a while
<Kamion> daniels: ok, will do
<Kamion> daniels: just a matter of a rebuild, or is there anything more complicated>?
<daniels> Kamion: cheers
<haggai> ajmitch: just done some more research and I'm happy to approve you for MOTU
<daniels> Kamion: should just be a rebuild.  fglrx will be busted (not ftbfs, just won't work when you run it), but that's nothing new.
<ajmitch> haggai: thanks
<thom> daniels: ah
<ogra> haggai: what about a zope team lead ;)
<ogra> haggai: since zope/plone needs urgently some love
<elmo> Kamion: don't forget the "haha, GOT YOU" version number crap
<ogra> elmo
<fabbione> and the ABI change!
<daniels> nvidia_minor, ati_minor, avm_minor, and whatever it was that I added the other week
<ogra> read the above ? ajmitch will send you a key i guess
<ajmitch> mako has a signed CoC from me
<ajmitch> fwiw
<ogra> ajmitch: ah, great
<elmo> ogra: eh?
<ogra> elmo: <haggai> ajmitch: just done some more research and I'm happy to approve you for MOTU
<ogra> elmo: i already approved him at the last meeting ;)
<ajmitch> sigh, apt-get working at 2K/sec
<elmo> ajmitch: send  your keyid and a copyof the signed CoC to upload@ubuntu.com.  (I know you sent the later to mako, but unless you want to wait for him to wake up...)
<Kamion> elmo: I should probably manage to get that right third time round or whatever :P
<ajmitch> elmo: alright
<ogra> so ladies and gentleman.... please welcome OUR NEW MOTU ajmitch
<ogra> ajmitch: please add yourself to the MOTU page ;)
<amu> ubuntu-holiday: phoned Eduard, he confirmed the reservation, got the last 4 seats, mail follows
* haggai hands the microphone to ajmitch to thank all his relatives and manager
<ogra> lol
<thom> ajmitch: just try not to get all tearful
<doko> ogra: zope2.7 should be ready tonight, working currently on plone
* ajmitch bows, thanks all
<thom> we hate that, mopping up takes ages
<ajmitch> doko: excellent!
<doko> ajmitch: are you currently working on python universe updates?
<ogra> doko: i think you can coordinate with ajmitch now....
<ajmitch> doko: trying to
<ajmitch> are you working with zope 2.7.4?
<fabbione> elmo: did you switch to use xinetd for rsync?
<doko> ajmitch: are there some common questions for the transitions? (zope: yes)
<elmo> fabbione: no
<fabbione> ok :(
<ajmitch> doko: common questions would be which python versions are being supported (2.2-2.4)?
<sivang> pheee, that is creepy http://www.google-watch.org/gmail.html :-/
<doko> ajmitch: 2.3 and 2.4 are supported in main, universe has 2.1 and 2.2. it depends on you what you want to support
<ajmitch> alright, what work needs done with plone & zope packages?
<haggai> ogra: looks like we have a volunteer for the lead then :)  What needs doing?
<ogra> haggai: probably an announcement will be enough... i still have no idea how this teams thing shall work if there are more then one person....will we vote for a leader ? will the team elect ?
<Kamion> daniels: ok, uploaded, will see what the buildds make of it
<haggai> ogra: let the people interested decide for themselves (unless there is a conflict of interest)?
<ogra> haggai: i want to keep the flames at a low level, so we will have to find a system for it....i'm not the person to assign teamleaders beyond the start i think..
<haggai> ogra: from among the MOTU
<sivang> mvo_: morning
<haggai> that is maybe the closest to the system for Ubuntu
<sivang> mvo_: you're making update-notifier right? :)
<ogra> haggai: first one goes first ?
<mvo_> sivang: yes
<mvo_> sivang: morning btw
<ogra> btw, as i wrote on MOTUTeams, i dont think a teamleader has to be a MOTU, it should be enough to be member to lead a team... since not everything done by the team will be technical
<mvo_> :)
<sivang> mvo_: what would you say about adding an about dialog from the main program dialog, that uses GtkAboutDialog? :)
<haggai> ogra: yes.  I think we're more likely to be needed to find people to work on something at all, than to stop too many people from working on something :)
<haggai> (given the number of packages in universe)
<sivang> mvo_: or is it part of synaptic ? (which already has one)
<ogra> haggai: i have a list wit about 10 ppl frm here (IRC) i will ask.... and every new MOTU is encouraged to recruit new ones indeed , eh, ajmitch ?
<mvo_> sivang: it makes heavy use of synaptic, but it is not part of it. a about dialog? yeah. would be nice
<ajmitch> ogra: of course, it's like a pyramid scheme :)
<haggai> ajmitch: oh, I forgot to tell you about the fee for the scheme.. :)
<ogra> snowball i thought... but pyramid is also a good picture ;)
<Treenaks> a snowball rolling down from a pyramid!
<ogra> yay
* ogra wonders if there are pyramids in countrys with snow anwhere.....
<haggai> ogra: it helps for a team leader to have upload rights; I think I would give prio to MOTU to lead
<ogra> haggai: ok, but i'd like to discuss this later if there is a non MOTU who wants to tke a team lead :)
<haggai> ogra: most of the jobs that you have outlined on motuteams need MOTU to complete, and the team leader is in the best decision to decide when a new version is ready
<haggai> ogra: sure, if there's no MOTU interested then its not such a good plan :)
<haggai> ogra: but I think such a person should be wanting to become MOTU anyway
<ajmitch> haggai: then you need to encourage the team leader to be a MOTU
<haggai> exactly
<ogra> yup :)
<haggai> and saying they need to be MOTU is a good form of encouragement :)
<daniels> Kamion: thanks mate
<YokoZar> haggai: hey, can we talk?
<YokoZar> Oh cool ogra's here too
<YokoZar> I added the Wine MOTU team to the Wiki, although for now it's going to be largely a team of one (me) until I demonstrate how to port a Windows app to Ubuntu universe with Winelib.  That is, if I become an MOTU - I need your endorsements and signatures to my key :)
<Treenaks> YokoZar: where are you?
<Treenaks> YokoZar: it should be easy to get signatures in most parts of the world
<YokoZar> Treenaks: How exactly does geographic locality matter here?
<ajmitch> YokoZar: you get signatures when you meet people in person who verify your identity
<Treenaks> YokoZar: well, people with gpg keys aren't distributed evenly across the planet
<ajmitch> conferences are great for that
<YokoZar> Ah I figured I could just verify it over the phone.  Hrmph...  I'm in Northern California
<Treenaks> YokoZar: there are /lots/ of people with gpg keys in CA :)
<ajmitch> no, it's usually done with photo ID
<ajmitch> eg I used my passport & student ID with photo
<doko> elmo: please sync perl from unstable (to address #4638)
<elmo> doko: ok to override ubuntu changes?
<YokoZar> ajmitch: and then scanned them in and emailed em?
<haggai> YokoZar: you're on my list of reviews to do; you had a lot of changes for wine which I wanted to look at more closely
<elmo> [NOT Updating - Modified]  perl_5.8.4-5ubuntu1 (vs 5.8.4-6)
<doko> elmo: there's only one (pitti's security update, which is included in -6 as well)
<ajmitch> YokoZar: no, I met with people in person who then could sign my GPG key
<elmo> doko: ok.  [I have to ask these days; people kept losing ubuntu changes by mistake :)] 
<ogra> YokoZar: dont you have a lug near you ?
<YokoZar> haggai: Ahh, ok.  I've got some more changes coming in too, though they're mostly improvements (such as integrating the user guide into the help menus)
<YokoZar> ogra: Yeah I was the guest speaker at the LUG last time I was there, heh.  I'll check the email list.
<ogra> YokoZar: i'm sure anyone there could sign your key....
<ogra> YokoZar: if you cant find someone, there is an additional way that tseng is just going through....
<YokoZar> ?
<ogra> it requires a notarial approved signed paper copy of the CoC
<ogra> which you send by snailmail....
<ogra> ask tseng for details, since he already did it this way
<YokoZar> I think I'll just head to our small 25 person user's group and hope to get lucky, heh
<ogra> heh, ok
<YokoZar> In the meantime someone like you can upload my packages for me, heh
<YokoZar> haggai: Did you mean changes to the Debian wine packages or just changes in general?  I made the packages from scratch
<ogra> YokoZar: i think haggai will do it, if he came to your packages on his TODO list 
<YokoZar> Most excellent
<YokoZar> Everything is going according to the master plan.
<sivang> bonjour seb128_ :)
<seb128_> morning
<ajmitch> YokoZar: well the small LUG here has about 5 debian developers :)
<shlomil> sivang: hello
<sivang> shlomil: hi
<ajmitch> night all
<dholbach> night ajmitch
<sivang> night ajmitch 
<haggai> YokoZar: I meant in general
<YokoZar> haggai: ahh, ok
<Keybuk> so, my attempt to upgrade warty -> hoary went *very* badly wrong
<thom> ARGH
<Keybuk> dpkg: dependency problems prevent configuration of libecal1.2-dev:
<Keybuk>  libecal1.2-dev depends on libecal1.2-1 (= 1.1.4.2-0ubuntu1); however:
<Keybuk>   Package libecal1.2-1 is not configured yet.
<Keybuk> (lots of problems)
<Keybuk> descent scott# aptitude dist-upgrade
<Keybuk> aptitude: error while loading shared libraries: libapt-pkg-libc6.3-5.so.3.9: cannot open shared object file: No such file or directory
<Keybuk> aiiiiieeeee
<daniels> whoohoo!
<pitti> elmo: I just uploaded language-support-ast, which is in NEW. I seeded it now, so it can be processed
<Kamion> Keybuk: apt-get dist-upgrade?
<Kamion> apt-get will work even if aptitude isn't, considering that it's in the same package as libapt-pkg
<Kamion> s/isn't/doesn't/
<Keybuk> Kamion: yeah, that needed a -f, but it's running again at the moment
<Kamion> or even just apt-get install aptitude I guess
<elmo> Kamion: is the 'backup' user safe to use for my own nefarious purposes?
<Kamion> base-passwd/users-and-groups doesn't know, so I don't either :-)
<Kamion> backup
<Kamion>     Presumably so backup/restore responsibilities can be locally delegated to
<Kamion>     someone without full root permissions?
<Kamion>     HELP: Is that right? Amanda reportedly uses this, details?
<jdub> Kamion, mdz: do you have a machine with both a CD drive and CD burner?
<Kamion> elmo: I think so, though
<Kamion> jdub: as in separate devices? no
<sivang> jdub: I have
<pitti> jdub: I have, too
<sivang> jdub: well, DVD and a CDRW
<elmo> Kamion: k, tnx
<jdub> sivang, pitti: can you test cd burning from the livecd?
<pitti> jdub: sure
<sivang> jdub: yes, sure, latest build?
<jdub> but of course
<Treenaks> elmo: could you sync phpgroupware from sid?
<elmo> enrico?
<elmo> meh
<sivang> jdub: aye aye captain! (/me searches for the torrents)
<sivang> hmm no torrents yet?
<elmo> Treenaks: what email would you be using for packages?
<Treenaks> elmo: uh, martijn@foodfight.org I guess
<elmo> there's a UTF-8 for 'ij' ?
<elmo> like, uh, why?
<Treenaks> uh yes, but not in that email address :)
<fabbione> Siemens ID USB Mouse Fingerprint sensor support (USB_IDMOUSE) [N/m/?]  (NEW) 
<fabbione> impressive
<elmo> Treenaks: I was just olooking at ubuntu-devel
<Treenaks> elmo: historical stuff.. see "Dutch Y" in Wikipedia
<Kamion> elmo: ligature
<elmo> yeah, I just don't remember it being distinguished from normal letters in signs etc.
<Kamion> elmo: when it's in title case, both I and J get capitalised, IIRC
<Treenaks> yes, IJsselmeer, not Ijsselmeer etc.
<pitti> elmo: please remove the following source packages entirely: mozilla-firefox-locale-{da,fr,sv,tr}
<pitti> elmo: they will be replaced by the new mozilla-firefox-locale-all (which I will upload after the removal)
<thom> seb128: how easy is it to add actions to flexiserver conditionally?
<seb128> should be easy, why ?
<thom> cool
<thom> for hibernate and suspend actions on the logout menu
<seb128> yeah, I've a bug open about this
<thom> yes
<thom> i'm working on the code to let you do it ;-)
<thom> (the backend code)
<seb128> k, cool
<dholbach> dumbledore.hbd.com - nice :-)
<dholbach> hi sabdfl 
<elmo> pitti: why is their removal necessary first?
<pitti> elmo: hmm, right, the package names differ
<elmo> pitti: generally removal should be done afterwards to ensure version numbers really are >> etc.
<elmo> Treenaks: done
<pitti> ok
<Treenaks> elmo: thanks
<pitti> elmo: uploaded
<Hwolf> who is the openoffice maintainer?
<Treenaks> haggai, I think?
<sabdfl> hi dholbach
<Kamion> jdub: (question from much earlier) kickstart isn't quite testable yet; most of the infrastructure is there but it doesn't understand all the commands in kickstart files yet, which I'm still working on
<fabbione> hey sabdfl 
<jdub> Kamion: ah, ok
<jdub> Kamion: i have a willing guinea pig as soon as it's ready to test
<Kamion> jdub: cool, I'll ping you
<Kamion> jdub: does this guinea pig have existing kickstart files?
<jdub> yes, and generation infrastructure, etc.
<jdub> red hat shop, debian fans
<Kamion> jdub: if possible, I'd like a sample kickstart file so that I know what I need to prioritise
<jdub> Kamion: ok, i'll ask
<Kamion> thanks
<Mithrandir> Kamion: I can see if I can get you the ones which are/was used at our uni?
<Kamion> Mithrandir: that would be great
<Kamion> I'm lacking real-life examples, mainly
<Mithrandir> yeah, request sent
<Kamion> basically the current state of kickstart is that I've written all (?) the infrastructure and implemented all (?) the commands that can easily be done without changes to the installer
<Kamion> I'm now going through and souping up bits of the installer to support the previously-unimplementable kickstart commands
<Kamion> i.e. adding extra debconf questions that can be preseeded
<Mithrandir> first answer I got was "Our kickstart scripts are _ugly_"; I just replied that I'd like to have a copy nevertheless
<Kamion> some of them I have precious little idea how to do in a d-i context, like 'skipx' (don't configure X)
<Kamion> er, in an Ubuntu context, for that matter
<Mithrandir> don't install X?
<Kamion> it's not clear from the documentation, but I get the impression that Anaconda installs X but doesn't configure it if you use skipx
<Mithrandir> uhm
<Mithrandir> that sounds just weird.
<Kamion> well, it doesn't configure X in its postinst equivalent, remember; the installer has a UI for it
<Mithrandir> true
<Kamion> TBH I'm inclined to just ignore it and hope that X never asks a question
<daniels> Kamion: we could always have xserver-xorg/do_configure = false
<Kamion> daniels: I think its real semantics are "don't show me the X configuration UI, and don't start X"
<Kamion> don't start the display manager
<Mithrandir> Kamion: quoting; "You are aware that it is full of ed scripts, a couple of sed inlines and at least one perl inline script"
<Kamion> Mithrandir: good
<Kamion> Mithrandir: the uglier the better; I want to see worst cases
<Kamion> Mithrandir: (the perl bit won't work, of course, unless it's a %post script)
<Mithrandir> 'course
<Kamion> actually nor will the ed stuff, no ed in busybox; that'll be a laugh
<elmo> ajmitch: ?
<Kamion> but I don't mind if the result doesn't work, I just want to see what people are actually trying to do
<daniels> Kamion: right
<ajmitch> elmo: yes? 
* ajmitch hasn't quite gone to sleep yet
<ajmitch> elmo: did I forget to send something?
<elmo> ajmitch: what email address you using for uploads?
<ajmitch> usually ajmitch@gnu.org
<elmo> usually? :)
<elmo> I need to whitelist it
<ajmitch> that's what's on all my debian packages :)
<ajmitch> so yes, that address
<pitti> sivang: mozilla-firefox-locale-all (which includes -he-il) is in
<pitti> elmo: thanks
<lypanov> umm
<lypanov> is archive slow?
<lypanov> are there mirrors?
* lypanov waves to daniels 
<Kamion> lypanov: http://www.ubuntulinux.org/wiki/Archive
* lypanov wonders who the multiple people he was chatting to about ruby pkgs were last week
<daniels> lypanov: yo
<Kamion> hm, so kickstart has a 'firewall' command
<lypanov> daniels: how goes? :)
<Kamion> what should we do with it? :)
<fabbione> *cough*killit*couhg*
<Kamion> fabbione: can't.
<lypanov> wow. ubuntulinux.org is also slow as heck here
<fabbione> Kamion: what are the parameter for 'firewall'?
<Kamion> it lets you: (a) specify a "security level", which I don't know the details of; (b) allow all traffic from listed interfaces; (c) allow specified services (dhcp, ssh, telnet, smtp, http, ftp); (d) allow specified ports
<daniels> lypanov: not too bad, just battling stupid nvidia motherboards
<fabbione> oh i remember
<lypanov> daniels: ugh. m/b's or gfx crds?
<Hwolf> Did anything change in gnome-system-monitor since yesterday?
<fabbione> Kamion: b/c/d can easily be done via iptables
<daniels> lypanov: motherboards; trying to get optical out (spdif)
<Kamion> our "no services listening by default" policy is not relevant here, because kickstart installs are not default
<Kamion> fabbione: erm, I need this to be debconf-preseedable, ideally
<Kamion> I *can* fake it up as a %post script or something if need be
<daniels> (oh, and the acx100 driver doesn't work on amd64.  whoohoo!!)
<fabbione> Kamion: that's kinda complex.. because iirc the fc installer allows you to manually edit the ports
<sivang> pitti: thanks!
<Kamion> daniels: acx100 wasn't endian-clean last I checked, I see no reason why it should be 64-bit-clean :P
<fabbione> Kamion: you can preseed a multiselect from 1 to 65536?
<Kamion> fabbione: for preseeding it could just be a space-separated string; that's not a problem
<fabbione> and tcp/udp/icmp combination
<Kamion> well, iptables is in base, at least
<Kamion> maybe I can write out an init script
<Mitario> hi everyone
<fabbione> but can debconf manange 65K entries in ${choise}?
<Kamion> it doesn't need to, because this would not be presented to the user
<daniels> ah, actually
<daniels> Kamion: the developers claim it works on amd64
<Kamion> as it happens it can, but all the same :)
<Kamion> although any presentation would be total crap
<Mithrandir> Kamion: acx100 works on amd64; I know it since I use it every day.
<daniels> can we please gat that into the stock kernel images, then?
<fabbione> what+
<fabbione> ?
<daniels> fabbione: acx100
<daniels> fabbione: for amd64
<Kamion> Mithrandir: maybe they've fixed it; it used to be bust on powerpc
<fabbione> amd64/amd64-generic:CONFIG_ACX100=m
<fabbione> amd64/amd64-k8:CONFIG_ACX100=m
<fabbione> amd64/amd64-xeon:CONFIG_ACX100=m
<fabbione> amd64/amd64-k8-smp:CONFIG_ACX100=m
<Mithrandir> daniels: it's there; at least in l-r-m
<fabbione> dude are you on some kind of crack?=
<Mithrandir> been since a bit after warty released.
<Mithrandir> Kamion: no idea about PPC, since I don't use my acx100 in a ppc
<fabbione> powerpc/power4-smp:CONFIG_ACX100=m
<fabbione> and it is compiled also on ppc..
<daniels> Mithrandir: ah, bong
<Mithrandir> fabbione: that doesn't mean it works
<fabbione> tho we have no idea if it works
<Mithrandir> daniels: it's bonged on warty, tho.
<fabbione> Mithrandir: exactly..
<fabbione> somebody sends me a PPC
<fabbione> and i will happily test the driver
<Kamion> haha, the "security levels" other than disabled in kickstart firewall configuration are all just aliases to "enabled"
<fabbione> perhaps thom
<daniels> Mithrandir: *shrug*, this is hoary
<fabbione> perhaps thom's ipod
<Hwolf> fabbione: get a mac mini. :-D
<Hwolf> ;-)
<thom> ipod isn't ppc afaik, so you can piss off :P
<daniels> sudo rmmod e1000 && sudo modprobe e1000
<daniels> guh
<fabbione> thom: the big one :P
<thom> fabbione: oh, go steal it from L3 then
<fabbione> eheh
<thom> i'm not carrying one of them any more
<fabbione> thom: are you too fragile for them? ;)
<thom> too lazy for them, yes
<amu> seb128: ping 
<seb128> amu: pong
<amu> seb128: the flights are fine for y? 
<seb128> which ones ? the one from yesterday ? yep
<seb128> oh
<seb128> just reading my mails
<amu> ^^ 
<seb128> yep, that's fine
<daniels> kamion	
<daniels> '(for a start: our driver now supports AMD64, PowerPC, MIPS and of course x86
<daniels> -- now please try to do that with NDIS loader "solutions", ok?)'
<amu> seb128: also those from luxembourg to frankfurt and back?   
<Kamion> daniels: fair enough
<seb128> amu: yep, I'm replying to the mail
<daniels> hm.  to complete my day of technology hate, I just stepped on a double adaptor and put a rather sizeable hole in my heel.
<lypanov> ouch
<lypanov> daniels: ask them how longer it took them to support x86 in comparison to adding one function to getting the comparable ndis loader working :P
<lypanov> s/how /&much /
<amu> seb128: thx
<daniels> lypanov: heh
<daniels> frig!  normal audio works fine, but it appears SPDIF on nForce4 just doesn't exist in Linux right now.
<Kamion> ndis is still a ghastly wrong hack though
<Kamion> very useful (if you happen to have a computer that can use it), but still ghastly :)
<daniels> heh
<jdub> daniels: you're using the correct subdevice for it?
<daniels> jdub: yeah
<daniels> card 0, device 2
<daniels> tried a hojillion combinations of that sort of stuff, dmix, everything
<daniels> it certainly seems to be at least *present*, because if you throw 8kHz at it, it screams about only wanting 48kHz
<jdub> daniels: bummer, 'cos nforce2 works ok
<daniels> jdub: aye.  oh well, it'll probably improve (maybe around the same time i actually get a device that pciutils knows about)
<zul> hey
<daniels> oh no, I lie -- it knows about the acx111 (wifi), the sata controller, the firewire controller, and the marvell eth controller
<daniels> the other 21 are unknown ;)
<tseng> i was pretty suprised to find out last night that my acx111 card just works in the installer
<zul> is that the 2.6.10-15 kernel?
<fabbione> nah
<fabbione> i fixed that a while ago
<zul> dang..:)
<fabbione> zul: i am "bootstrapping" 2.6.11
<fabbione> based on bk snapshots
<zul> and?
<fabbione> and just that you know...
<zul> cool
<sivang> hmm I Still have to manually pumount the burner before being able to use it to burn
<zul> fabbione: how is the usb stuff in it
<fabbione> zul: dunno.. fixing the few FTBFS problems on i386 now
<fabbione> they changed the API in DVB support
<fabbione> without fixing the drivers (yet)
<zul> yeah i heard that
* fabbione wonders why everybody say that they have heard, but they never have a fucking fix
<zul> because i dont have a fucking fix :)
<thom> we leave it for our illustrious kernel maintainer
<lamont> fabbione: I may wind up being a few minutes late to the meeting - 8AM is a bad time for me
<daniels> thom: hm, working on that principle -- firefox leaks ram like a bitch
<daniels> thom: can you please fix it?
<daniels> thom: i think it would be really good if you did
<daniels> thom: ARE WE THERE YET??
<fabbione> lamont: ok
<thom> daniels: certainly. just type "killall -9 firefox-bin" as many times as you feel necessary. et voila, no more memory leaked
<daniels> thom: make sure never to report any firefox bugs.  ever.  or you know how they'll end up.
<daniels> s/firefox/xorg/
<sivang> thom: nice, we should automate it
<fabbione> thom: why don't you crontab it?
<sivang> :)
<fabbione> killall -9 firefox
<jbailey> Yar.  hotplug fails to patch all it's files correctly with LANG=fr_CA.utf-8.  Works fine with LANG=C
<sivang> fabbione: lol
* lamont takes kids to school
<jbailey> I wonder if debuild should scrub LANG as well?
<Treenaks> jbailey: no, it should just set LC_ALL
<Treenaks> jbailey: which overrides /everything/ else
<elmo> jbailey: dpkg-buildpackage should
<elmo> if anything - not debuild
<jbailey> Treenaks: Would it just be LC_ALL=C then?
<Treenaks> jbailey: I think so, yes
* jbailey does a test.
<thom> jbailey: or just LC_SORT for hotplug
<thom> LC_COLLATE, even
<zul> fabbione: i did some of the usb merging last night
<fabbione> zul: good
<zul> its not pretty though
<fabbione> i am off for a long break
<fabbione> cya at the meeting
<zul> k
<daniels> have fun, fabbione
<justdave> who has access to change code on bugzilla.ubuntu.com these days?
<elmo> justdave: I can
<justdave> amu needs the address changed that the liveCD bugs go to, and because of the hack we did with keywords for that, it's hardcoded in one of the templates
<justdave> template/en/default/bug/create/create.html.tmpl:59:        if (document.getElementById("keywords").value == 'livecd') { owner = 'amu@tr.debian.net' }
<justdave> have to ask him what address to change it to
<justdave> I think that's under /var/www/warty-bugs IIRC
<amu> justdave: elmo: amu@ubuntu.com 
<elmo> justdave:  data/template/[...]  or template/[..]  ?
<justdave> template/
<justdave> data/template is just a cache, it'll get rebuilt if template/ changes
<elmo> ok, changed
<elmo> justdave: thanks
<justdave> np
<daniels> things that are not quick include: copying 200GB of data off an ATA100 drive.
<jdub> daniels: rm -rf ~/.ccache ;-)
<daniels> jdub: it's just ~/mirror and ~/music at this stage
<daniels> jdub: given that together they're >100GB, ~/.ccache is the least of my worries
<daniels> jdub: are we getting mono/amd64 for hoary?
<fabbione> daniels: mono isn't really portable
<fabbione> it doesn't even build where it is supposed to
<daniels> oh?  i thought it was working on amd64 these days
<daniels> heh
<fabbione> it claims to work on sparc.. the fact is that it doesn't even build
<fabbione> mono -> Trashcan
<jdub> daniels: if we got 1.1, yes, but no one has done that yet
<jdub> fabbione: 1.1 will
<daniels> jdub: ah
<jdub> seb128: ping
<fabbione> http://www.theaustralian.news.com.au/common/story_page/0,5744,12194177%255E2702,00.html
<fabbione> CUUUTE
<seb128> jdub: pong
<jdub> dpkg: error processing /var/cache/apt/archives/gnome-icon-theme_2.9.91-0ubuntu1_all.deb (--unpack):
<jdub>  trying to overwrite `/usr/share/icons/hicolor/48x48/apps/gnome-run.png', which is also in package gnome-panel-data
<jdub> 
<jdub> seb128: then it upgrades on second invocation of dist-upgrade
<seb128> grumpf
<thom> fabbione: yes, cell is cool
<thom> http://tinyurl.com/4rrb8 just for Keybuk 
<seb128> jdub: I've probably put the conflict/replace on gnome-panel instead of gnome-panel-data
* seb128 checks
<seb128> grrr
<jdub> yeah
<seb128> yep, 
<seb128> jdub: thanks for noticing :)
<lypanov> k. gtg
<lypanov> bbl
<dholbach> thom: this is supposed to be a joke, isnt it?
<lypanov> ciao daniels :)
<pitti> seb128: I just upgraded my laptop
<pitti> seb128: there is a file conflict
<pitti> seb128: /usr/share/icons/hicolor/48x48/apps/gnome-run.png is both in gnome-panel-data and gnome-icon-theme
* seb128 slaps pitti
<pitti> ouch
<seb128> read the 10 lines before yours
<pitti> seb128: argh, sorry
<seb128> np :)
<seb128> already uploaded a fixed version
<pitti> seb128: I only see the last 8 lines of xchat, the others are covered by consoles :-)
<pitti> seb128: thanks
<seb128> np :)
<thom> dholbach: i rather suspect not
<dholbach> thom: ouch.... OUCH!
<Keybuk> thom: and people claimed the Welsh didn't have the balls to play Rugby
<jdub> hrm
<jdub> who had the warty dance video?
<thom> Keybuk: and now they're right
* Kamion ponders sticking the netboot initrd on the live CD as an option
<Keybuk> heard about that this morning on Virgin, gave me a giggle
<fabbione> Kamion: that would be nice
<daniels> jdub: it's in carlos's thingy from Photos on the wiki, IIRC
<jdub> ta
<carlos> jdub: http://carlos.pemas.net/gallery
<carlos> don't remember the exact URL
<jdub> thanks!
<doko> jbailey: gcc-4.0 packaging is finished
<jbailey> doko: /me happy dances
<amu> jdub: keyword Luis ;) i told your guys, i'll help, than all disapper 
<jdub> amu: lu|reading has been here :)
<lu|reading> amu!
<amu> oh my god :) he's alive 
<lu|reading> haha
<lu|reading> I am
<lu|reading> I've been playing a lot at home
<jdub> TMI
<thom> got to fill those long, unemployed days, i guess
<amu> jdub: FBI
<lu|reading> amu: http://tieguy.org/blog/ has several posts on what I've been playing with
<lu|reading> still no good art
<amu> lu|reading: letme check ...  
* Kamion briefly gets confused between lu and, er, other lu
<daniels> heh
<daniels> Kamion: lu != lulu
<Hwolf> seb128?
<Mitario> hey guys
<jdub> Kamion: lu is now a man, living in boston.
<jdub> Kamion: well. kind of man.
<daniels> jdub: what was he before that?
<jdub> daniels: she was our project manager
<daniels> jdub: woah
<amu> lu|reading: i'm sorry, i dont like them :) should i ask my personal designer? hehe did fanstatic work at gnoppix      
<daniels> jdub: so who was managing the monkeys?
<daniels> or was lu just multi-talented?
<sivang> jdub: just read your blog posts about aborigni college, and also found about http://craige.mcwhirter.com.au/2005/ubuntu-ldap-client.html , rock :)
<fabbione> kernel meeting in 5 minutes on #u-m
<seb128> Hwolf: what ?
<lu|reading> amu: like I said, I don't like them either :) the important thing mostly is that I have an iso with epiphany, abiword, gnumeric, etc., as defaults. You're certainly welcome to solicit more art yourself.
* lu|reading is clearly already begging for more :)
<amu> lu|reading: nope, with just a iso, you can make people afraid using gnome, it needs MAGIC :)   
<lu|reading> heh
<lu|reading> :)
<amu> usability, simplicity .... 
<amu> technic is not all 
<Mithrandir> pitti: ping?
<pitti> Mithrandir: pong
<amu> ex. with a ~/Documents ~/Music ~/Photos you make 90% of the possible users so happy 
<fabbione> meeting is starting now
<Mithrandir> pitti: did you see my question about applying http://arch.err.no/index.cgi/tfheen@idi.ntnu.no--2005/pkg-glibc--multiarch--0--patch-2?cmd=cs_new&file=debian/patches/99_multiarch-ld.dpatch to glibc for hoary?
<Mithrandir> pitti: it'll be in sarge, it seems.
<lu|reading> amu: I've done some of that (well, i've put it all in ~/Desktop/ so that it is more user-visible at first)
<elmo> Mithrandir: come agan?
<lu|reading> amu: after I eat and shower I will hopefully do some more
<jdub> lu|reading: perhaps in Documents would be better
<Mithrandir> elmo: about sarge?  it's just support for it in the loader.
<jbailey> elmo: vorlon has approved it.
<jbailey> elmo: I just haven't uploaded it for Sarge yet.
<Mithrandir> elmo: it's not "split glibc and make people go crackcrackcrack"
<Mithrandir> elmo: it's a makefile change only, fwiw.
<jbailey> Mithrandir: In fairness, it's a makefile that changes a define, but not in a hideous way.
<pitti> Mithrandir: the additional library paths? Yes, I remember
<Mithrandir> jbailey: true, but as you say
<Mithrandir> pitti: It would be nice to have it in hoary as well, I think.
<pitti> Mithrandir: I agree. Does mdz agree?
<Mithrandir> pitti: IIRC, he asked me to ask you.
<jbailey> pitti: The justification for Sarge is basically that it'll ease multilib backporting work.
<Mithrandir> let me look it up in the logs.
<pitti> Mithrandir: I have to upload a new glibc soon anyway, so this would be a good opportunity
<pitti> Mithrandir: personally I'm fine with the patch
<jbailey> pitti: I should dig through the ubuntu package and figure out which pieces ought to be tossed into Sarge, too.
<jbailey> Maybe tomorrow night.  I've had a houseguest, so no time for non-work hacking lately.
<pitti> jbailey: the only real upstream patch is language support (which I'm fixing right now)
<pitti> jbailey: but that probably doesn't fit into Sarge
<Mithrandir> pitti: I thought I talked with mdz about it, but evidently not (as I can't find the IRC logs stating it); I can talk to him when he wakes up in a couple of hours.
<pitti> ok
<pitti> Mithrandir: he should be here by 1600 UTC (meeting)
<Mithrandir> yup
<Mithrandir> will be fun, considering he went to bad late.
<amu> lu|reading: people are strange, i added another wallpager and changed the theme, put some icons on the desktop, now people say the gnoppix is the better one :)  
<lu|reading> :)
<Mithrandir> Kamion: seems like the university has a big investement of time in those kickstart files, so we'll have to get approval; I'll send a mail and Cc you
<Kamion> Mithrandir: ok, if it's going to be a real problem don't push it, I'll get samples elsewhere
<dholbach> i'm off... bye
<Mithrandir> ok
<elmo> fabbione: ?
<fabbione> elmo: i am in the meeting
<elmo> *shrug* k
<fabbione> anything really important?
<elmo> no
<sivang> elmo: did you fix up the answers for the .il domains eventually? I recall sending you some msg about it in irc, not sure if you got it
<sivang> elmo: (from canonical's ns, smurfix's are fine)
<trulux> back
<trulux> mdz: i will finish the page today, ok?
<Kamion> elmo: could you bump the priority of pciutils-udeb and usbutils-udeb to standard, please?
<Hwolf> I'm confused. I added a bookmark in the dialog that openoffice uses to open files, and now it appears in places, but my nautilus bookmarks do not. What's the logic behind that?
<Kamion> elmo: they need to get installed by default
<elmo> Kamion: done
<Kamion> thanks
<ogra> haggai: i'll leave my desk now to go home, i may be late for the meeting, but i would like to see dholbach approved today, who will be missing too, but he has a (carpenters) hand full of packages already in (amu sponsored bluefish and gparted, i did timer-applet) and he is very much wanting to fix universe bugs....
<Kamion> elmo: any idea what's up with http://cdimage.ubuntu.com/weekly-dvd/20050205/hoary-install-i386.iso giving a 403?
<Kamion> elmo: hm, actually, the images seem to just be missing
<elmo> Kamion: there's still an ongoing sync
<Kamion> from three days ago?
<elmo> no
<elmo> if it's missing from there, err, I have no idea?  it's just a rsync off whatever's on little?
<Kamion> yeah, little looks fine though
<Kamion> could you check the permissions for me? it's giving 403 not 404
<Kamion> -rw-rw-r--    1 cjwatson cdimage  2333243392 Feb  5 12:33 hoary-install-i386.iso
<fabbione> elmo: i will be back in 4 minutes
* fabbione needs a fast break
<elmo> -rw-rw-r--    1 archvsync archvsync 2333243392 2005-02-05 12:33 hoary-install-i386.iso
<elmo> our apache apparently has LFS issues
<Simira> fabbione: the opposite of breakfast?
* thom falls off his chair laughing
<elmo> [Tue Feb 08 15:47:02 2005]  [error]  [client 81.153.126.219]  (75)Value too large for defined data type: access to /weekly-dvd/20050205/hoary-install-i386.iso failed
<sivang> cc meeting is on in about 5 minutes?
<Simira> yep
<sivang> oh hi Simira !
<Simira> hi there :)
<sivang> Simira: whassup?
<sivang> thom: what made you laugh so abruptely?
<dilinger> elmo: ask infinity to fix it.  he loves LFS.
<thom> i still have the patch
<Simira> sivang: not much. Got a mentor to teach me to do documentations. Starting a translation-team. :)
<thom> there's no reason we can't do it on the archive machines, actually
<thom> elmo: lfs64 blows the abi of apache2 to hell and back
<thom> it's not pretty for external modules
<elmo> sigh
<thom> (and it's fixed in 2.1/2.2)
<sivang> Simira: cool
<thom> elmo: but for us, with no external modules, it's not a problem
<elmo> what's the schedule (if there is one) for 2.1/2.2 ?
<thom> 2.1 is alpha at the moment, should go beta in a few weeks
<thom> elmo: it's stable for the core stuff; svn.apache.org runs it
<mako> elmo: CC meeting?
<mako> sabdfl: ^^^
<fabbione> elmo: re
<elmo> fabbione: did you do what kamion asked about ext-module on itanium in -15?  i.e. not Provide it in mumblekernel-imagemumble ?
<Kamion> yes, he did
<fabbione> elmo: yes
<elmo> well germinate's screwed then
<elmo> or something, bah
<Kamion> let me see ...
<fabbione> hem
<fabbione> Provides: ext2-modules, rtc-modules
<fabbione> no
<fabbione> wtf..
<fabbione> i am sure i did it
<Kamion> debian/d-i/ia64/package-list still has the provides
<sabdfl> mako, mdz: did we not move to 20h00 UTC?
* fabbione sighs
<fabbione> sorry i was 100% sure i did it
<mako> sabdfl: not according to the agenda
<mako> sabdfl: maybe that was tb meeting
<Kamion> that was TB, indeed
<elmo> fabbione: even tho you don't deserve it ;-), I ip-limited rsync on auckland
<fabbione> elmo: cool! thanks
<fabbione> elmo: the sparc buildd was suffering from it
<elmo> I also need some "too long, bzzt, you lose" facisim
<fabbione> i don't care too much about my local mirror
<elmo> there was one slot still running since Feb 4
<fabbione> from me?
<elmo> no idea who
<elmo> they lost out in the switch to xinetd anyway
<fabbione> ok
<trulux> ajmitch: ping
<sivang> hey trulux 
<trulux> sivang: hi :)
<trulux> anyone here with latex knowledge?
<zul> ick...
<zul> i rather use microsoft word
<tritium> trulux, I use it a lot, but I'm not a guru, exactly.  What's up?
<pitti_> trulux: I'm quite good at it
<pitti_> zul: hey, LaTeX rocks :-)
<trulux> tritium: I'm preparing a paper on proactive security, treating projects and current technologies, and also giving explanations on how some of technologies can be defeated, I'm using a modified IEEETran from Usenix, but I would like to know how to divide the sections like in http://www.nsa.gov/selinux/papers/freenix01/freenix01.html
<trulux> when exporting to html
<trulux> hey pitti_!!
<zul> pitti_, nope it doesnt
<trulux> long time no chat
<trulux> pitti_: how's your life :)!?
<tritium> trulux, okay, I use IEEEtran all the time
<pitti_> trulux: busy, but fine 
<tritium> let me check the link
<trulux> tritium: OK, thanks in advance
<trulux> pitti_: we worked out the libssp thingy
<trulux> pitti: I ecnourage you to check our wiki, we have moved things and *well* documented *everything*
<trulux> pappy- did it
<pitti> nice
<trulux> so
<trulux> we are ready to create the gcc pkgs
<trulux> we got some fast machines and so on
<trulux> from adobbie's college
<tritium> trulux, I don't see anything special about the section divisions.  Just use \section{} and \subsection{}
<trulux> tritium: i mean when exporting
<tritium> trulux, what are you using to export?
<trulux> latex2html -no_subdir -split 0 -show_section_numbers $$i
<trulux> from LyX
<trulux> -split 0 seems to be the thing, right?
<tritium> trulux, I've never exported to html.  I've only prepared .ps or .pdf for publication.
<trulux> haha, me too
<tritium> pitti, how about you?
<trulux> but often users want the click-nd-up thingy
<trulux> :)
<tritium> I understand.
<pitti> tritium: I usually export to PDF with hyperlinks
<tritium> trulux, sorry...
<trulux> np
<trulux> no worries
<trulux> let them getting a dvi reader
<trulux> :D
<tritium> trulux, pdf with hyperlinks is a pretty good option, imho
<trulux> ok
<trulux> thanks
<tritium> trulux, well, I didn't really help, but sure. ;)
<jdub> is there a faster (performance) way of listing files in debs?
<Treenaks> jdub: ar somemagic | tar someothermagic ?
<elmo> dpkg -c is slow?
<seb128> raaaaahhh, 
<seb128> Uploading via ftp evolution_2.1.5.orig.tar.gz: Error '(32, 'Broken pipe')' during ftp transfer of evolution_2.1.5.orig.tar.gz
<seb128> need to scp it again, grrr
<sivang> seb128: firewall problems?
<elmo> no
<elmo> the upload server is broken and can't handle long-running uploads - it's a bug that's being looked at
<sivang> elmo: eh
<seb128> hate hate hate hate hate hate evolution
<sivang> seb128: hehe, well, you're not the only one :)
<seb128> every single release is so fucked
<seb128> this one has just forgetten all the mails in the spam box
<seb128> so I've hundred of spams in my boxes again
<sivang> grrrrrrrrrrr
<fabbione> who has bugzilla admin rights?
<sivang> seb128: why don't you use mutt? (shhh, I hope jdub doesn't hear me) 
<crimsun> fabbione: still looking for someone to look at ALSA for kernel?
<lamont_r> fabbione: mdz, jdub, dunno who ele
<lamont_r> else
<seb128> fabbione: elmo and jdub I think
<seb128> mdz too
<fabbione> crimsun: there was a kernel team meeting.. it is in the todo list
<fabbione> jdub: ping?
<crimsun> fabbione: yes, I saw (after) - I was in a meeting at that time.
<fabbione> crimsun: just add yourself as subsystem maintainer
<doko> elmo: any chance to add the following packages as build dependencies for gcc-4.0 to main: libmpfr-dev, autogen, typehandling
<crimsun> fabbione: ok, just needed to check first.
<fabbione> crimsun: irclogs are here: http://people.ubuntulinux.org/~fabbione/irclogs/ubuntu-meeting-current.html
<crimsun> fabbione: thanks.
<elmo> doko: gcc-4.0 isn't in main?
<zul> fabbione: ill be around later need to have lunch
<fabbione> i need to leave soon 
<doko> not yet ... it's a toy for jbailey doing java stuff
<zul> k i should be back in half hour
<lamont_r> fabbione: so I'll be around for a while...
<fabbione> zul: can you manage to stay around for only 10 minutes?
<fabbione> so i can end the day?
<zul> yeah i cant do that :)
<mvo_> doko: typehandling? can't find it here?
<fabbione> zul: ok.. i guess we will wait for you than
<elmo> doko: well, I can tell you now type-handling has been vetoed for main before
<zul> fabbione: im having lunch at my desk go ahead
<azeem> mvo_: type-handling
<fabbione> zul: ah ok
<elmo> doko: but if you want changes to main at this stage, you'll need to mail mdz, jdub and cc me
<fabbione> zul, lamont_r: #u-m?
<zul> k
<mvo_> azeem: thnx
<doko> elmo: was there a technical reason for the veto?
<elmo> doko: we think type-handling is crack?
<jbailey> Debian arch naming for non-Linux arch's in general is crack.  type-handling doesn't add much to the pile. =)  I can see it being crack for Ubuntu, though.
<infinity> It's absolutely crack, but it more or less works for now.
<Kamion> type-handling's functionality should be merged into dpkg-dev
<doko> elmo: hmm, it's even slow crack, but there's not anything better.
<thom> http://people.redhat.com/davidz/pwr-mgmt-user.png
<doko> Kamion: yes, that would be nice
<elmo> doko: *shrug* at the end of the day, I'm not the dude(s) you need to convince
<thom> yay someone doing my work for me!
<jbailey> Kamion: Sure, but past experience shows that features don't exactl sprint into dpkg. =)
<Keybuk> seb128: Secure SMTP is broken again in latest evo
<Kamion> jbailey: beat up Keybuk
<Keybuk> see, now I'd enjoy that and that'd delay any new features even longer <g>
<jbailey> Kamion: In a fair fight, I'm not sure I'd win.
<elmo> what kind of idiot fights fair?
<elmo> ;-)
<jbailey> elmo: That's what my mom told me, too. =)
<Keybuk> actually, on that subject Millan was proposing a not-too-bad implementation that got a bit Goswin'd
<seb128> Keybuk: ? I'm scping it, it's not uploaded yet ... ??
<Keybuk> seb128: ok, not-so-latest evo then
<seb128> what's broken ?
* infinity reads scrollback.
<Keybuk> with Secure SMTP set to Always, it takes a *very* long time to deliver mail or nearly always times out
<Keybuk> even clicking "Check supported types" does that same
<Keybuk> but at Never of When Possible it works immediately
<seb128> k
<infinity> elmo : All apaches has LFS issues.  I could fix it for Ubuntu, but at the cost of becoming gratuitously ABI-incompatible with everyone else, including Debian.
<infinity> elmo : Or, we wait for 2.1 :/
<seb128> let me know if that happens too with 2.1.5 when it's available
<infinity> elmo : For Debian, after attempting the former, we opted for the latter.
<jbailey> seb128: Is that due out soon?
<seb128> jbailey: I've just dput it
* jbailey happy dances.
<elmo> infinity: yeah, don't worry, thanks - I sorted it with Thom
<elmo> infinity: we're going to go crack-tastic on the bleeding edge
<infinity> elmo : Just running back through nick hilights. :)
<doko> kamion: can you remember a time frame for the discussion?
<sivang> Keybuk: here also
<infinity> elmo : Ahh, I didn't read enough context.  If it's just an internal project machine, you can blow up apache2 in whatever ways you want, I guess.
<thom> 2.1 is more fun tho
<Kamion> doko: which discussion?
<doko> kamion: "actually, on that subject Millan was proposing a not-too-bad implementation ..."
<elmo> infinity: internal?  what fun would that be?  I'm talking about multi-TB a day archive/cdimage/releases.u.c!!
<Keybuk> doko: that was me that said that
<infinity> elmo : Yes, but that's internal.
<infinity> elmo : ie: Not packaged for the archive.
<elmo> infinity: oh, right, yeah
<elmo> I think uploading apache2.1 to hoary would be fun too, but slightly P45 inducing
<infinity> I don't like that kind of fun.
<infinity> Tracking upstream SVN commits like a hawk to catch all the security vulns that aren't announced (because no one uses 2.1 in production, right?...) would not be fun at all.
<Kamion> nah, just run a daily build! kthxbye
<elmo> infinity: that's where having upstream on your admin teams comes in handy
<thom> *g*
<doko> keybuk: ok, anyway, could you give me pointer to that discussion?
<Keybuk> would "http://bugs.debian.org/" be considered too vague a pointer? :p
<Kamion> wasn't that on -policy?
<Keybuk> #291939
<Mithrandir> mdz: I don't remember if I talked with you about multiarch-ed ld-linux.so for hoary, but I couldn't find it in my irc logs.  Would you be against putting http://arch.err.no/index.cgi/tfheen@idi.ntnu.no--2005/pkg-glibc--multiarch--0--patch-2?cmd=cs_new&file=debian/patches/99_multiarch-ld.dpatch in hoary?
<Mithrandir> mdz: it's ok with pitti, it'll go into sarge.
<sivang> does anybody know if the rosetta mega import tool place already?
<sivang> (was said to happen sometime this week)
<pitti> mvo_: 
<pitti> mvo_: ping
<mvo_> pitti: pong
<pitti> mvo_: there seems to be a bug in your automatic changelog generation
<pitti> mvo_: rookery: /home/mvo/public_html/changelogs/pool/universe/f/fireflier/fireflier_1.1.4-3/changelog -> ../changelog
<pitti> mvo_: however, ../changelog does not exist
<infinity> Moving is teh suck.
<infinity> -EWIN
<mvo_> pitti: thanks, I'll have a look
<pitti> mvo_: in addition, are the changelogs cleaned up from time to time?
<mvo_> not yet
<pitti> mvo_: there are lots of changelogs which don't have a corresponding source package any more
* pitti pats http://people.ubuntu.com/~pitti/ubuntu-cve.html
<pitti> mvo_: I abuse your changelog collection to produce ^
<pitti> mdz: ^ this could interest you as well, I automatically generate an overview over all fixed CANs in Ubuntu
<pitti> mdz: it's still very rough and needs some work, but it will be helpful for doing reviews
<mdz> morning
<pitti> Morning mdz
<mvo_> pitti: I'll move the changelog generation to changelogs.ubuntu.com in the next few days and I'll have a look at the cleaning then
<mvo_> I'll ping you
<pitti> mvo_: cool
<mvo_> morning mdz
<mvo_> pitti: packages.d.o does not clean the changelogs too. the synaptic changelogs directory is amazingly long :)
<pitti> mvo_: I will work around this anyway, I think
<pitti> mvo_: I will look which version is in each release and directly try to grab the respective version
<pitti> mvo_: above page is only the very first try :-)
<mdz> Kamion, haggai, amu: #ubuntu-meeting?
<thom> daniels: AAAAAAARGH
<pitti> mvo_: when does the cronjob run?
<thom> firefox xkb bug
<thom> daniels: #6301
<mvo_> pitti: once per night. it would be cooler if it could be integrated into the archive processing scripts so that the changelog becomes available at once. but I don't thing it's easy to do (might be when the integration into launchpad gets better)
<pitti> mvo_: I'd like to eventually set this up as a cronjob, too
<mvo_> we can ask elmo if we can run the script two times a day
<pitti> mvo_: however, it should run shortly after yours
<pitti> mvo_: that's why I'm asking for the exact time
<mvo_> I can write out a stamp file that you can check on if you want
<pitti> hmm, that's probably too complicated
<mvo_> pitti: 04:30 right now
<pitti> mvo_: okay, then I just run mine at 06:00
<mvo_> ok
<kent> is there problems with X/gnome/keyboard/mouse in recent Hoary? My mouse dont respond after a few seconds, and neither the keyboard, sort of (i can change to virtual terminals..). Since my computer is crazy, im having problems looking at bugzilla. i just got xchat working, and i can atleast type in this window since it got fucus on startup.
* thom begs for Make-foo
<thom> ifeq ($*,foo) is *always* false; why? :/
<pitti> thom: isn't $* a list?
<sivang> seb128: is gnome-control-center has it's menubar/about dialog disabled due to libgnomeui::gnome-about dependency? or was it to integrate with the ubuntu desktop?
<pitti> thom: oh, this is Makefile syntax?
<sivang> seb128: (I see code for an about dialog, but can't find it when exploring the gui)
<thom> pitti: yes, make
<jordi> speaking of mako
<jordi> mako: did the bastards give you the money?
<seb128> sivang: I don't get the question, what menubar ?
<sivang> seb128: well, sorry, maybe it doesn't have a menu bar, but how can I open it's about dialog (it's in control-center.c) ?
* sivang advancly aplogizes for seb128 for he current and future vaugeness :)
<seb128> there is no about box in the capplets
<seb128> if that's the question
<sivang> seb128: right, but I mean for the main one which lists them, the control center itself
<seb128> there is no about box
<ogra> sivang: control center has no app win....has it ? i thought thats nautilus.....
<sivang> ogra: it is?
<seb128> no, nautilus or shell during 2.8
<seb128> now it uses only the shell
<seb128> (the vfolder code is a 2.8 stuff)
<ogra> ah, k
<sivang> seb128: ah ok, thanks , that explain stuff
<sivang> seb128: then that code should probably be removed sometime in the future, if it's not used at all. (control-center-2.9.4/control-center)
<seb128> patches are welcome 
<sivang> seb128: sure , as always :)
<seb128> yeah, I don't know this part of the code
<seb128> but if you think that there is some ugly part of code upstream please send a patch
<lamont_r> are the mailing lists archived anywhere web-accessible>
<lamont_r> ?
<sivang> seb128: sure, I'll have to figure out un doubtfully which parts are redundent, if I do , I'll offer a patch.
<seb128> thanks
<seb128> lamont_r: http://lists.ubuntu.com/archives/ ?
<thully> hi - I wondered if anyone has loooked into bug #5981 - a fairly major bug with the live CD
<lamont_r> seb128: doh
<thully> on my laptop, it gives me trouble if I'm not in range of wi-fi (by continuously prompting me for an ESSID and forcing me to back out to the installer main menu, which leaves no loopback configured
<thully> (the no loopback configured is a separate bug I've reported, #2835)
<zenwhen> can a question about hoary be answered her. No one in #ubuntu will answer me.
<zenwhen> here*
<seb128> lamont_r: not what you are looking for ?
<zenwhen> Is there a method of editing the gnome menu in hoary?
<lamont_r> seb128: exactly what I was looking for
<seb128> lamont_r: k
<Mithrandir> zenwhen: no
<zenwhen> Oh
<zenwhen> Back to warty
<Mithrandir> zenwhen: or, you have to edit the .desktop files
<lamont_r> T-Gone: ubuntu pop-con uses HTTP post
<sivang> crimsun: ping
<zenwhen> is gnome-panel-screenshot broken?
<seb128> no
<zenwhen> oh
<zenwhen> well it stoppe working for me when I upgraded to hoary
<seb128> so that's not a question ?
<zenwhen> what
<seb128> define "stoppe working" ?
<zenwhen> There was an error running "gnome-panel-screenshot":
<zenwhen> Failed to execute child process "gnome-panel-screenshot" (No such file or directory).
<ogra> doesnt look broken....missing rather....
<seb128> is gnome-utils installed ?
<zenwhen> As in, it is not there.
<zenwhen> yes
<zenwhen> but apparently it didnt get upgraded
<seb128> should not
<seb128> dpkg -l gnome-utils
<seb128> dpkg -L gnome-utils | grep screenshot
<ogra> zenwhen: do you have all necessary meta packages installed before the upgrade ?
<ogra> i.e. ubuntu-desktop
<ogra> seb128: you took 5870 ? 
<Mithrandir> hmm; why have we aggregated all of linux-restricted-modules again?
<zenwhen> ogra, yes I had ubuntu-desktop installed
<ogra> seb128: feel free to drop test packages at me.....amd64 here
<zenwhen> it appaears that some gnome packages were just not upgraded
<zenwhen> I can upgade them
<Kamion> thully: no, I have not yet had time to look into that, because I am busy doing all the things I need to have done before feature freeze; bug fixes come later
<seb128> ogra: I run a i386 distro
<seb128> ogra: ping Mithrandir about amd64 issues
<seb128> zenwhen: 
<zenwhen> Also gnome-desktop-environment is not installed
<seb128> <seb128> dpkg -l gnome-utils
<seb128> <seb128> dpkg -L gnome-utils | grep screenshot
<ogra> seb128:  #5870: AssignedTo|debzilla@ubuntu.com         |seb128@ubuntu.com 
* Mithrandir waves to ogra 
* ogra waves back
<zenwhen> Desired=Unknown/Install/Remove/Purge/Hold
<zenwhen> | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
<zenwhen> |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
<zenwhen> ||/ Name           Version        Description
<zenwhen> +++-==============-==============-============================================
<zenwhen> ii  gnome-utils    2.8.1-0ubuntu1 GNOME desktop utilities
<zenwhen> from the first
<Mithrandir> ogra: I guess you want to force me to fix evo on amd64 now?
<zenwhen> and the second gives no resonse
<seb128> zenwhen: oh, update it
<seb128> ogra: tristan.tarrant@dataforte.net  	2005-02-08 16:57 UTC  	AssignedTo  	debzilla@ubuntu.com  	seb128@ubuntu.com
<ogra> Mithrandir: nah, i wont force anyone
<zenwhen> gnome-desktop-environment is not installed
<seb128> ogra: dunno why this guy changed the bug
<zenwhen> could that be my issue?
<zenwhen> it also refuses to be installed
<ogra> seb128: ah, k, blind me....
<Mithrandir> ogra: I started to look into it,  but got diverted, actually
<seb128> zenwhen: the screenshoot stuff has move from panel to utils
<zenwhen> oh
<seb128> zenwhen: you need to upgrade gnome-utils
<zenwhen> what is gnome-desktop-envoronment?
<seb128> a meta package
<zenwhen> is it some metapackage?
<seb128> don't bother with it in ubuntu
<ogra> Mithrandir: i was just a little confused because the bug seemed assigned to seb128 now....and since i know he has no amd64 i wanted to offer my testing machine ;)
<seb128> it's not updated
<zenwhen> oh ok
<zenwhen> It was freaking me out
<Mithrandir> ogra: let me dist-upgrade my amd64 box and I'll see if I can track it down easily.
<seb128> Mithrandir: you said that's due to a mutex issue with libdb, isn't it ?
<zenwhen> thanks for the help seb128. 
<seb128> np
<Mithrandir> seb128: yes, but once I fixed that, it started falling over with some other error
<seb128> oh, ok :/
<mdz> NO
<mdz> someone reformatted GraphicalInstaller back to reFux0redText
<ogra> mdz: doesnt just switching it back help ? helps mostly for me...
<Kamion> mdz: however the formatting actually works now ;) it was broken when I looked at it yesterday
<mdz> ogra: switching the radio button does not reformat the text
<mdz> Kamion: really? what was wrong?
<mdz> it looked fine to me
<ogra> mdz: you mean the guy really chaned the content ? ouch....
<Kamion> mdz: the *-prefixed paragraphs were all screwed; the second and subsequent lines looked like a separate paragraph and were indented by a tab
<dholbach> hai
<mdz> Kamion: oh, that.  I was going to fix that; it was ugly but I wouldn't call it broken
<mdz> he could have deleted the whitespace instead of reformatting the entire document
<Kamion> heh
* lamont_r wonders how long he should wait before moving postfix and friends to ship seed
<zenwhen> raise da roof
<zenwhen> oops
<zenwhen> also is the gnome panel volume applet just a small line for anyone else?
<seb128> no
<zenwhen> well thats because I am a huge dummy
<zenwhen> thanks
<zenwhen> :)
<zenwhen> it was another thing that didnt get upgraded
<zenwhen> I should do a clean install sometime. I really f'd this up.
<zul> later
<zul> T-Bone: did you have a look at the logs for #u-m?
<T-Bone> zul: went back too late
<zul> okies..
<T-Bone> zul: i guess you guys talked while i wasn't online
<zul> T-Bone: people.ubuntu.com/~fabbione/irclogs
<zul> later
<lamont_r> Kamion: did you need me to look at a package or something?
<Kamion> lamont_r: dholbach's coaster package ... review for whether it's enough for Ubuntu membership
<Kamion> (note: not maintainership - not asking you to sponsor it in or anything either, just let me know if it's sane or not :))
<zenwhen> oh
<T-Bone> lamont_r: ok got in sync with what was said. Anything special I should be aware of? I've looked at the kernel package, it's significantly different from the Debian one, but that's something i can deal with, afaict ;)
<zenwhen> I upgraded gnome volume manager on accident and now I cant mount my mp3 player autmatically. Hoary isnt going too well for me.
<zenwhen> L(
<dholbach> Kamion: the coaster package will still need some love :-(
<Kamion> dholbach: yeah, that's fine
<Kamion> I just didn't have time to review it so sabdfl asked me to get someone I trusted on the distro team to have a look
<dholbach> Kamion: you'd better review one of the other packages - timer-applet, gparted and bluefish already are in ubuntu
<Kamion> lamont_r: if you don't have time, no problem, I'll ask somebody else
<ogra> Kamion: gparted would be a better candidate, since it is already in a releasable state
<dholbach> hi ogra
<thom> fabbione: if you can nail down why kacpid spins on hp laptops, that'd be sweet ;-)
<ogra> and its a missing thing for gnome as well 
<Kamion> lamont_r: ^-
<T-Bone> i have to figure out what's wrong with d-i on ia64 too, but I'll need help. Something has been changed that fucked up everything ;-/
<zenwhen> newest volume manager/hal/dbus doesnt mount my mp3 player anymore.
<zenwhen> lol
<lamont_r> Kamion: I should be able to do it
<Kamion> thanks, much appreciated
<dholbach> lamont_r: you can find it on    deb-src http://ubuntu.gplan.info hoary main
<dholbach> lamont_r: it's the one, i would let someone else upload :-)
<dholbach> lamont_r: there's another bug that got fixed in upstream's cvs, which i'll package (right after dinner :-))
* lamont_r ponders the missing battery status info in his panel...guess I should really do a complete upgrade, not the partial one I did earlier
<Mithrandir> hmm, could I have a quick poll; how many files do you have in ~?  (If you're the only user, df -hi /home is probably the quickest way to check.)
* Mithrandir has almost 500k, which means the utf8 migration tool takes a lot of time to scan his ~
<lamont_r>  dev/hda9               7.5M    636K    6.9M    9% /home
<ogra> /dev/hda3               7,9M     86K    7,8M    2% /home
<lamont_r> dholbach: 403
<lamont_r> what's the package name?
<ogra> gparted
<zenwhen> ogra, would it be worthwhile to file a big report about the fact that my muvo 2 doesnt automount or even appear in fdisk after upgrading hal?
<dholbach> lamont_r: yes.. it's a *very* silly webserver, but my router has a slow upload only
<dholbach> lamont_r: apt-get source gparted    should work nicely though
<ogra> zenwhen: did you look if there probably already is one ?
<Mithrandir> hm, ok, I guess we should have some sort of "please wait while we scan your home directory.  This might take some time"
<zenwhen> oh
<zenwhen> ok
<zenwhen> I currently hate my computer. lol
<zenwhen> I havent been this annoyed since my first week running slackware.
<rubenv> eh wtf
<rubenv> df -hi renders me this:
<rubenv>  /dev/hda3                  0       0       0    -  /
<lamont_r> Mithrandir: mind you, those of us here are probably not a representative sample...
<Mithrandir> lamont_r: nah, but it's not ok for something to hang for > 5 seconds without any kind of feedback, imho.
<Mithrandir> lamont_r: and scanning a 4-5-600k file ~ might take minutes on a laptop drive.
<Mithrandir> mdz: did you see my question wrt ld-linux multiarch patching?
<mdz> Mithrandir: no, I haven't read scrollback yet this morning
<lamont_r> Mithrandir: speaking of which... if I have a utf-8 encoded file, how to I convert that to iso-8859-1?  or windoze cp1252 or some other thing?
<mdz> jdub: yes, I have a machine with both an (ATA) DVD-ROM and a (USB) DVD writer
<Mithrandir> mdz: there's a patch which adds the /lib/$DEB_BUILD_ARCH and /usr/lib/$DEB_BUILD_ARCH paths to the default search paths for ld-linux.  Would it be ok with you to add it to hoary?
<Mithrandir> lamont_r: convert the contents?  iconv -f utf8 -t iso-8859-1 < file > file.iso8859-1 should work
<mdz> trulux: we are very close to the deadline; the sooner I have that list, the better the chances we can implement most of it
<zenwhen> is the gnome volume applet is gnome-applets
<zenwhen> in*
<lamont_r> Mithrandir: cool - was more after the command name so i could hit man, but that's even better.  tahnks
<mdz> fabbione: what do you need in bugzilla?
<Mithrandir> lamont_r: recode is another tool which does the same.
<mdz> Mithrandir: looking at the patch
<trulux> mdz: I need to get ajmitch online
<Mithrandir> mdz: fwiw, pitti is fine with it, it's going into sarge (approved by vorlon; jbailey will upload once he gets around to it)
<mdz> Mithrandir: fine with me, on condition that it's in before feature freeze
<Mithrandir> mdz: I'll see to that.
<Mithrandir> mdz: thanks a lot.
<Mithrandir> what TZ is feature freeze in?  hawaii?
<lamont_r> jdub about?
<lamont_r> Mithrandir:  shouldbe the same TZ as we release in...
<lamont_r> dholbach: cdbs and autocrap... DENIED.:-)
<mdz> Mithrandir: UTC
<lamont_r> although cdbs is better than dbs...
<mdz> Mithrandir: though we haven't specified what time of day it begins :-)
* dholbach cries desperately... :-)
<lamont_r> dholbach: heh
<Mithrandir> mdz: heh, ok.  I'll talk to pitti when he gets online tomorrow and get him to get it in then.  He had an upload pending already
<dholbach> lamont_r: but i share your view on abusing auto*
<lamont_r> I don't mind autocrap, it just frustrates me
<lamont_r> in debian/rules, did you grab that version assignment from somewhere, or is it your own creation?
<dholbach> lamont_r: it frustrates me when auto* does stuff, {pre,post}{inst,rm} should be doing, that's why coaster needs a bit 
<dholbach> lamont_r: to be honest... i nicked it
<lamont_r> yeah
<dholbach> of seb128 :-)
<lamont_r> well, it is a gnome package... :-)
<lamont_r> what led to the cdbs decision?
<dholbach> lamont_r: i found them to be a lot more readable
<lamont_r> I find them to be terse in the extreme - but then I haven't bothered to dig into cdbs much at all
<dholbach> lamont_r: and they included lots of defaults regarding gconf, mime-stuff, ...
<dholbach> lamont_r: from what i saw,   debian/rules  with cdbs seemed to be more maintainable to me
<dholbach> maybe not in all cases
<lamont_r> it probably is.
<dholbach> lamont_r: if i have a "general point of view" on this, i'll let you know ;-)
<lamont_r> Kamion: is there anything that would vary in the daily build that would make debian-installer-manual differ from the prior daily build?
* lamont_r wanders back home for a bit.
<ajmitch> morning
<ajmitch> trulux: around?
<trulux> ajmitch: sure!!
<marcin_ant> hello - any Eclipse user here?
<trulux> ajmitch: todo list work now, right?
<ajmitch> trulux: ok, I just crawled out of bed again, so let's get to work
<trulux> ajmitch: great, we want mdz smiling at us :)
<trulux> we promised it!
<ajmitch> mdz: what info do you want?
<trulux> ajmitch: we need first to get the status of the package ans their versions in hoary
<trulux> ajmitch: and then write what needs each one of them
<ajmitch> well that's easy enough :)
<marcin_ant> I have a problem with Eclipse SWT browser in Ubuntu - could anyone help me with this?
<ajmitch> that can be divided into selinux tools & policy, and ubuntu packages such as coreutils
<trulux> I was preparing all the afternoon a paper on these things, so, soon I will make it available and those who want to know further on Hardened Debian scould read it (it's more a general paper, but has *many* info. on the things we are trying to deply in Debian and Ubuntu)
<trulux> ajmitch: right
<trulux> ajmitch: we need latest libselinux
<trulux> and fixed policy package
<trulux> write that in the page, I dunno on how to make tables in that wiki
<ajmitch> 'fixed' policy is our job, once we get a recent debian policy
<trulux> yeah
<trulux> and
<trulux> we need to get the PAM patched and updated
<trulux> add that too
* trulux diging in archives and Manoj's packages
<ajmitch> pam, dpkg, sysvinit, coreutils
<mdz> ajmitch: what we need is a list of changes that would be needed in Hoary to support selinux
<ajmitch> ssh currently doesn't need it
<mdz> ajmitch: it is unlikely that we will be able to implement all of them, but if we can make your efforts easier by getting some of the patches into hoary, we will
<mdz> but it must be before feature freeze (tomorrow)
<ajmitch> mdz: alright
<ajmitch> ah
<ajmitch> mdz: if the main packages are in hoary, I'll still be able to upload fixed poolicy to universe for awhile?
<trulux> ajmitch: don't bother with policy now
<trulux> go ahead with core packages
<trulux> we need first to have selinux supported
<trulux> after we can work the policy
<trulux> ok?
<Kyaneos> hi
<mdz> ajmitch: yes, certainly
<sivang> mdz: regarding 6092, the decision is to move it out of the gui right? (just to make sure)
<mdz> we're pretty flexible about universe with regard to the release process
<mdz> sivang: yes
<sivang> mdz: cool, then I will do it.
<mdz> thanks
<sivang> mdz: my pleasure, we need this done before the clock hits tommorow UTC? (ff) or can we be more relaxed with realtively minor code change like this?
<trulux> ajmitch: so, what do you want to do today?
<trulux> I think i can't handle the package building today
<ajmitch> trulux: I'm adding stuff in the wiki
<ajmitch> trulux: do you have URL for coreutils patch? rjc's sysvinit patch works fine
<trulux> ajmitch: yes, lemme dig
<ajmitch> ah found it
<trulux> ajmitch: ok
<trulux> a guy from debian did a 5.2.1 pkg
<trulux> with se support
<ajmitch> trulux: yes, http://people.debian.org/~adric/selinux/coreutils/
<ajmitch> he put the URL in README.Debian
<ajmitch> mdz: you don't want to change the pam version in ubuntu, correct?
<bob2> haha
<ajmitch> trulux: have you lookde at applying the pam patch against the hoary version?
<trulux> ajmitch: it didn't apply
<trulux> ajmitch: I just grabbed Russell's PAM
<ajmitch> that's a pain
<trulux> yes
<ajmitch> I'll give it a go
<trulux> ok
<trulux> about the policy
<trulux> we should use the standard debian config. for packages
<trulux> and make a selectable list of programs
<trulux> so
<trulux> it will be more like pressing [intro]  than answering that large amount of annoying questions
<ajmitch> I've got some ideas for reworking policy
<Mithrandir> yay, it's now possible to change the suggested renaming in utf8migrationtool
<ajmitch> ok, only 2 rejects in the pam code
<trulux> ajmitch: what ones?
<ajmitch> pam_unix/Makefile & pam_unix/support.c
<ajmitch> seeing what I can fix now
<trulux> ok
<trulux> Makefile one should be easy
<trulux> support.c one could be not, how it looks?
<ajmitch> easy enough
<trulux> ok
<sivang> mdz: never mind, I'm working on it now
<zenwhen> wow
<zenwhen> I got my mp3 player to autmount again. Congrats on making it so that one can unmount a usb hard drive without closing out nautilus.
<zenwhen> :)
<jbailey> lamont-away: Bah, are you anbother cdbs hater? =)
<lamont-away> jbailey: I like to actually look at a makefile and see what it's doing...
<lamont-away> but that's just me...
<doko> elmo: please could you install automake1.9 autogen libmpfr-dev chrpath on davis/hoary?
<lamont-away> but tell me that cdbs is not just dbs re-done in C...  please...
<jbailey> lamont-away: No, at the moment it's done in make.  Just follow the includes.
<jbailey> lamont-away: cdbs2 is glued onto shell to make it easier for people to read / add modules.
<lamont-away> jbailey: but it has no relation to dbs other than the last 3 characters, true?
<jbailey> lamont-away: Sadly the finer points of GNU Make are lost on most people.
<Mithrandir> lamont-away: true
<lamont-away> jbailey: including me - it's on my list of things to actually read up on.
<mdz> ajmitch: if we are to update pam, it would require review
<jbailey> lamont-away: More or less.  dbs is Doogie's Build System.  cdbs is Common Debian Build System.  There is a 'tarball.mk' module in cdbs to provide dbs-type functionality.
<lamont-away> I learned make back in the boat anchor days, when a vax 11/750 was considered a resonable size machine, and your net-worth was determined by how few !'s you had in your email address....
<ajmitch> mdz: the patch on rjc's page applies with only a couple of simple rejections, I'm just building it now
<mdz> ajmitch: great, thanks
<lamont-away> jbailey: dbs is crackful.  cdbs got lumped in with that in my mind some time ago, and I'm still trying to overcome that
<jbailey> lamont-away: I hear you.  Anyhow, that's why cdbs2 is being done in shell.  The only truly awful parts are a couple of the shell functions and the 10 lines of make->shell glue.
<elmo> doko: done
<doko> elmo: thanks
<jbailey> The rest of it should be understandable by the average monkey.
<jbailey> lamont-away: If you have any cdbs questions, just lemme know.  I have a nick highlight on it, so I usually see it. =)
<sivang> jbailey: what more features are in cdbs2 ? will it have proper documentation? :)
<trulux> ajmitch: good job
<jbailey> sivang: Yes.  The important one is the ability to do 'debian/rules help' and get a sane list of what's going on.
<jbailey> sivang: The other major thing is that internally it's a set of hooks and dependancies.  Right now there are some cases where the includes have to be done in a certain order to get the right functionality.  That's all solved.
<ajmitch> jbailey: how functional is cdbs2 at the moment?
<lamont-away> jbailey: cool!
<jbailey> ajmitch: Not self-hosting.
<jbailey> ajmitch: I've written a good chunk of shell helper functions, which I'm thinking of refactoring off to a separate package.
<ajmitch> fun
<jbailey> Because noone should ever have to implement associative arrays in pure posh-compliant posix shell again. =)
<elmo> jbailey: err, cdbs2 is starting to sound more and more like dbs.. no offence :p
<sivang> jbailey: wow that's cool
<elmo> if it's that complex maybe you should just make the jump to a real scripting language
<ajmitch> jbailey: it sounds like you've been dabbling in evil again
<jbailey> elmo: I've wished for it a few times, but the advantage of pure posix shell is that I know it's on the system, and it's not perl.
* lamont-away lunches, goes back to retrieve his abandoned-but-busy-downloading laptop.
<infinity> jbailey : What, you didn't write it in shoop?
<trulux> tritium: ping
<tritium> trulux, yes?
<trulux> tritium: Package longtable Error: longtable not in 1-column mode.
<trulux>  \begin{longtable}
<trulux>                        {|c|c|}
<trulux> Try typing  <return>  to proceed.
<trulux> If that doesn't work, type  X <return>  to quit.
<trulux> :(
<trulux> with LyX
<tritium> trulux, eww, lyx ;)
<trulux> haha
<trulux> tritium: any hint?
<tritium> trulux, /msg me
<AndyR> lo all
<trulux> tritium: ok
<Mithrandir> does anybody have an idea why my (pygtk) scrolledwindow refuses to expand vertically?
<mvo_> Mithrandir: do you have the code somewhere to checkout/look? is it glade based?
<Mithrandir> yes, glade based.
<mvo_> what widget to you embedd in the scrolled window?
<Mithrandir> mvo_: a treeview
* mvo_ wgets
<Mithrandir> it's my first pygtk project, so don't laugh at me doing silly stuff. :P
<mvo_> no worry :) 
<mvo_> what file is it?
<Mithrandir> just run python utf8migrationtool and then click "next two times".
<Mithrandir> uhm "next" two times.
<Mithrandir> it won't change anything yet.
<Mithrandir> make sure you have some files in ~/Desktop with non-ascii, non-utf8 chars in them so you get some entries in the list
<Mithrandir> mvo_: any ideas?
<mvo_> no really good one yet, it looks like a expand is missing somewhere
<Mithrandir> the glade file looks right to me, and I can't get anywhere by prodding expand_children in the code.
<zenwhen> has anyone else been having connection problems to MSN?
<mvo_> yes, the glade file looks fine
<trulux> ajmitch: how is it going?
* trulux checks wiki page
<Mithrandir> zenwhen: yes, they are having problems, use jabber
<zenwhen> oh
<zenwhen> no one uses jabber
<ajmitch> hah
<zenwhen> I can't vonvince my friends to switch a chat network that none of their friends use.
<zenwhen> lol
<zenwhen> con*
<jbailey> zenwhen: Most geeks I know use jabber, most others use msn.
<Mithrandir> zenwhen: please, we're not interested in whether MSN has problems or not; it's not related to ubuntu development, so offtopic here.
<zenwhen> most of my friends use aim, but most GIRLS i know use MSN, and this is causing me to be very sad. :'(
<zenwhen> Mithrandir, what?
<zenwhen> It just started when I upgraded gaim
<sivang> zenwhen: yes, we should drop our account nad use jabber
<zenwhen> to the newest version in hoary
<sivang> zenwhen: it's probably b0rked in some way...
<Mithrandir> gaim in hoary works fine
<Mithrandir> it's the servers that are b0rked now; down.
<zenwhen> ok
<sivang> Mithrandir: I thought so  , but didn't dare to say, it's almost always their server which are down :)
<mvo_> Mithrandir: sorry, I played a bit with it and my idea is vague at best. it looks like your wizard_convertfiles glade stuff that you embedd into the main wizards window does not get more space from the main application window 
<Mithrandir> mvo_: any idea how to fix that?
<Mithrandir> mvo_: nevermind, I fixed it
<mvo_> how?
<mvo_> ^^--- Mithrandir 
<crimsun> sivang: pong (sorry, meetings)
<Nafallo> hi all. something loading early use drm, so fglrx can't load. I'll consider this a bug, but I don't know what I should sign the bug against. anyone else seeing this?
<Nafallo> amd64 btw
<thom> Mithrandir: WHY IS DEFAULT MAIL IN CHUNDERBIRD HTML?
<bob2> fix it
<bob2> thom: it = ubuntu
<infinity> thom : Please fix it, yes.  HTML mail is vile.
<thom> nothing to do with me
<jbailey> We have a package called 'nagios-plugins' in main.  What's a better name for its companion in universe: 'nagios-plugins-extra' or 'nagios-extra-plugins'.  The first seems more obvious, the second more grammatically correct.
<thom> Mithrandir maintains t-bird
<infinity> thom : Well, make him fix it, then. :)
<sivang> crimsun: ah no it's ok, did you notice gtk-gnutella is broken? it's missing it's /usr/bin/whatever
<sivang> crimsun: I installed the pkg and saw it didn't have the binary
<dholbach> jbailey: i vote for the first one - who these day look grammar after? ;-)
<jdub> mdz: ping
<jbailey> dholbach: Mmm.  The truth you speak, young skywalker.
<crimsun> sivang: I did, and I will work on it this evening after classes
<dholbach> jbailey: LOL 
<sivang> crimsun: ok cool :) 
<crimsun> sivang: a patch is attached to 5799, so I'll confirm it and send it to MOTU for approval
<sivang> crimsun: great! (I missed it since it got b0rked)
<sivang> mdz: from going over the users-admin gui again (as per 6092) I see that this option is also available when adding a new user (automatically inceremneted per each new user) should I remove it comletely? even when adding a new user? or maybe just make this field unchangable? (and leave it when modifying a user)
<trulux> mdz: ping
<Kamion> lamont-away: I made some changes to the manual recently; I expect it's that
<zul> hey
<trulux> hey zul
<trulux> zul zul zul
<trulux> :)
<ajmitch> hello zul 
<zul> hey trulux/ajmitch
<jbailey> What is the bug state of 'remind' used for?  The docs don't seem to mention it.  I have some stuff that I need to put together and send off to Debian, but it can wait a day or two.  'remind' sounds like the type of thing I might want.
<zul> jbailey: kind of like i cant work on it on now by remind me later
<trulux> ajmitch: I'm trying to make a table with organized heck of pkgs and such in the SELinux page
<ajmitch> trulux: good
<jbailey> zul: Tx.
<jbailey> sivang: Mmm, something annoying that I'm hacking on just reminded me of the other thing that cdbs2 does different:  Integrated multbuild.  Basically you define how many pases over the source code you want to make, and it does those.  Then for the packaging phase, it iterates of the package list.
<jbailey> sivang: Right now doing the build stuff by the package list doesn't make any sense, and it's hard to make sure that something happens at the right time with the arch and indep targets done the way they are.
<jdub> seb128, Mithrandir: should we get the new gaim in hoary?
<jdub> seb128, Mithrandir: lots of fixes
<seb128> I think so
<seb128> jdub: are you going to update the new gtk-engines ?
<jbailey> sivang: You'll still be able to hook on arch and indep, but it generally won't be the right thing to do.
<jdub> seb128: if you want me to :)
<sivang> jbailey: so basically you do multibuilds by hand?
<seb128> go for it since you updated the previous one, thanks :)
<sivang> jdub: regarding 6092, I'm thinking just to disable the option when modifying a current user, becasue when adding a new one it's still makes some sense, and there's even a checkup to see the uid entered meets some sane conditions int the code, what do you say?
<jbailey> sivang: No - it provides infrastrcutre that the various modules can use.  Like for nano, you might set udeb_build_dir := udeb  main_build_dir := main, and then do udeb_autoconf_options := --enable-nothing main_autoconf_options := --enable-everything.
<jdub> sivang: sure
<jbailey> sivang: In nano's case it happens to map well to the packages.  For something like abiword where you have multipass (Gtk build and gnome build), but three packages, gtk, gnome and plugins is where this becomes truly useful without really annoying overhead.
<sivang> jdub: ok cool, that way we don't differ too much from upstream, just add a couple lines of code that would widget.enabled = FALSE;  and we're set :)
<sivang> jbailey: very nice, so basically you are half way into making the multibuild work, as some infra. is already there for multiple targets ..do I get you right? ;-)
<jbailey> sivang: Yes.  And my last hack broke it incredibly and I haven't had a chance to sit down and think about it.
<seb128> time to sleep, 'night
<jbailey> sivang: I'm hoping to have more time to look at it in a month or so.  Right now my non-work hack time is quite limited.
<jbailey> g'n sb!
<sivang> seb128: night!
<sivang> seb128: how do you say good night in french?
<jbailey> sivang: Bonne nuit
<sivang> jbailey: :)
<trulux> ajmitch, zul, mdz: folks, check https://www.ubuntulinux.org/wiki/SELinux and tell me your opinion
<jbailey> Although I have a habit of saying Beau rves
<trulux> ajmitch: at least the 20/30% of that issues must be solved tonight
<sivang> jbailey: ah right, canadian knew french right?
<jbailey> sivang: Not all, but many.
<sivang> jbailey: it's the second official language no?
<jbailey> sivang: Yes.
<dilinger> also, hoary could really benefit from some hostap love :/
<dilinger> stupid POS wireless nics
<trulux> ajmitch: ping
#ubuntu-devel 2005-02-20
<ajmitch> yes?
<trulux> ajmitch: check the package again
<ajmitch> package?
<trulux> ajmitch: err, page
<trulux> :)
<ajmitch> yes, I saw the updates
<ajmitch> I'm just trying to see why this makefile is broken
<trulux> ajmitch: what's done right now?
<trulux> anything changed?
<ajmitch> working on pam
<Mithrandir> thom: because thunderbird is broken.  I'm going to fix it, I just haven't gotten around to it yet.
<trulux> ajmitch: ok
<dholbach> brb
<dholbach> re
<trulux> good night
<dholbach> sleep tight, trulux
<ajmitch> night trulux 
<amu> just joking :)
<amu> g8 all
<dholbach> sleep tight amu :-)
<dholbach> i'm off to bed, too *yawn widely*
<dholbach> *wave*
<sivang> me too
<sivang> night all!
<dholbach> bye sivang
<mdz> jdub: pong
* Kamion looks at some of kickstart's auth options, and wonders if the right answer might be to automatically enable universe and drag in packages from there
<Kamion> like nis or whatever
<jdub> Kamion: hopefully next release we go with libuser :)
<jdub> i don't think pulling universe packages is good
<Kamion> jdub: these are people with preexisting setups
<jdub> perhaps just break nicely if those can't be satisfied?
<jdub> yeah, but they're porting them to ubuntu
<Kamion> saying "but look, we have this better option!" is precisely no good at all
<jdub> there is no better option
<Kamion> they're porting one piece to Ubuntu, if we won't work with the rest of their machines they may well just say "oh well, screw 'em" and ditch us
<jdub> we don't support some of those things
<jdub> (nis is in main though)
<Kamion> hm, true
<jdub> the right fix is to support those things
* sivang says good night.
<jdub> night sivan
<Kamion> hm, ok
<Kamion> kind of screws them over for explicitly selected packages still, but that's not so much of a problem
<Kamion> I think I'd like to have a way to automatically enable universe in kickstart
<Kamion> although I am not quite sure what the syntax should look like
<zenwhen> hey Kamion is K3B currently broken?
<Kamion> how should I know? :)
<sivang> night jdub, I'll have the patch ready first thing morning. (too tired for it now)
<zenwhen> Oh I thought you were the resident KDE guy
<zenwhen> lol
<Kamion> zenwhen: not even slightly or remotely
<zenwhen> lol
<Kamion> I used KDE once in 1999
<Riddell> zenwhen: hello
<Kamion> or thereabouts
<zenwhen> It crashes when I drop in some mp3s
<zenwhen> figured I would see if anyone had noticed.
<Riddell> zenwhen: possibly restricted format issues
<Riddell> although it shouldn't crash
<zenwhen> Well it worked fine before I upgraded to hoary
<jdub> Kamion: yeah, explicitly enabling it would be very useful
<Kamion> jdub: kind of annoying that the format is owned by Anaconda; I'm not sure how to extend it correctly
<jdub> <x-element> ;-) ;-)
<Kamion> I guess I'll just add a 'components' directive or something so you can say 'components main restricted universe multiverse'
<Kamion> or something like that
<Kamion> kickstart != xml ;)
<jdub> components files are tho
<jdub> hrm, are you handling those?
<Kamion> no
<Kamion> well, not particularly
<Kamion> I will have to provide some kind of crappy shim for system-config-kickstart
<jdub> how painful was porting the system-config-kickstart app itself (not so much the rh->debian kickstart assumptions)?
<Kamion> jdub: in answer to your previous question, yes, it's easy to break nicely on unsupported stuff, already doing that
<Kamion> jdub: mostly just irritating, it's not a very well-written application and has an awful lot of RH/Fedora assumptions besides
<jdub> i wonder how sane it would be to use a bunch of the rh system config thingies
<Kamion> I had a look - it didn't really help
<Kamion> the only one I'm currently wondering about is the stuff in system-config-securelevel, for firewall configuration
<Kamion> but I think really that sort of stuff ought to go in base-config and do more Ubuntuish things
<Kamion> for the moment I've implemented only 'firewall --disabled' :)
<jdub> heh
<bob2> erk, icky i810 audio ickiness
<daniels> heh :)
<Kamion> jdub: oh, by RH assumptions, I mean more stuff like the rhpl libraries
<daniels> bob2: you don't have to hack the ALSA driver to get it working on your chipset :\
<jdub> Kamion: ah, yeah
<jdub> Kamion: mostly localised to those?
<jdub> nice doesn't have a huge effect on IO load, does it?
<bob2> daniels: it's got weird distortion after like 20 sleep/resume cycles
<Kamion> rhpl stuff was primarily gettext plus a couple of hardware detection pieces
<Kamion> I did the gettext stuff differently (and cheesily), and stubbed out the hardware detection for now
<daniels> bob	bong
<bob2> otoh, I'm happy sleep Just Works all the time now
<bob2> except I'm not game to try suspend-to-disk again so I can swap batteries
<Kamion> jdub: any idea what /usr/bin/htmlview might do, and what it should be replaced by?
<Kamion> /usr/bin/x-www-browser maybe?
<jdub> isn't htmlview like html2text?
<Kamion> jdub: doesn't look like it from the code, it's connected to Help -> Contents
<mdz> jbailey: what is the word on the initrd features you were working on?
<mdz> jbailey: will they make it in time for the freeze?
<jbailey> mdz: The DSDT stuff was uploaded earlier today (as well as fixes for most of the bugs I have assigned)
<jbailey> mdz: The NFSRoot initramfs is iffy.  I either need to update linux-kernel-headers (ugly) or find a better solution (we've talked about linux-libc-headers in #debian-glibc) for klibc.
<jbailey> mdz: I'm planning on hacking on the NFSRoot stuff a bit tonight to see if I can quickly compile something sane or if I should just punt it.  It's doing NFSBoot stuff fine for me, though.  integrated hotplug/busybox/tie into the kernel build isn't for Hoary.
* Kamion uses x-www-browser for now
<jdub> Kamion: hrm, i don't have htmlview
<jdub> oh
<jdub> oh
<jdub> sorry
<Kamion> I think it's an RHism
<jdub> yes, that's a red hat wrapper for the browser
<jdub> i'd suggest using gnome-open
<Kamion> what does that provide over x-www-browser? a GNOME dependency? :)
<Kamion> ew, /usr/bin/gnome-open is provided by a library package
<Kamion> so wrong
<Kamion> next time libgnome's soname changes that will cause upgrade hell
<lamont> jdub: thoughts on the postfix->shipseed mail?>
<mdz> jbailey: how would linux-libc-headers differ from linux-kernel-headers (apart from eliminating a lot of confusion...)
<jdub> lamont: i read it and cried
<jdub> Kamion: iz gtk boog :)
<lamont> jdub: it's a good thing - it lets postfix be functional at install.
<Kamion> jdub: what would the correct way of depending on gnome-open be? kickstart does not currently depend on anything GNOME, and I don't want to add an explicit dependency on libgnome2-0 because that's asking for trouble
<lamont> but I wanted to let you have a good cry before I did ti...
<jdub> Kamion: isn't this for s-c-k?
<Kamion> jdub: sorry, yeah, s-c-k. it only depends on gtk and glade at the moment.
<jdub> lamont: the thing that worried me the most was removing everything that may need an mta, like mutt
<Kamion> removing mutt kind of concerned me
<lamont> understandable
<lamont> but it's still on the CD...
<jdub> Kamion: perhaps we should chat to seb about gnome-open
<jbailey> mdz: linux-kernel-headers is the package that gotom, doko, and I put together to try and solve thge problem, but haven't really had time to keep up to date.  Most distro's have their own magic mess of the kernel headers tuned to userspace.  linux-libc-headers (http://ep09.pld-linux.org/~mmazur/linux-libc-headers/) is someone else's effort to do the same thing.  He seems to be doing things well, has been keep
<jbailey> ing it up to date, and has been doing it for a year so far.
<Kamion> jdub: ok, I'll file a bug if I remember, I'll use x-www-browser for now
<jdub> ok
<jdub> Kamion: perhaps you could suck it out of gconf via gconftool-2? :)
<jbailey> mdz: My thought for now was to package l-l-h to go into /usr/include/l-l-h.  Tell klibc to use it for now.  That would give me exposure to the package and make it easier to propose replacing l-k-h
<jdub> etc/X11/sysconfig/synaptic.desktop <- wtf?
<jbailey> mdz: (Either here or in upstream Debian.  I still don't know my relationship to glibc in Ubuntu. *g*)
<Kamion> jdub: I'll refrain for killing you because you're useful ;)
<Kamion> er, refrain *from*. my English good, I learn him from a book.
<jdub> heh
<jdub> from a booo-ook
<Nafallo> daniels: ping?
<daniels> http://itax.sourceforge.net/itax3.png <- notice http://ubuntu/itax/
<daniels> Nafallo: pong?
<Nafallo> daniels: #5925. Is my last comment something to investigate?
<daniels> Nafallo: well, that the drm changes in -11 broke stuff has always been known
<elmo> Kamion: can you update little to also trigger syowa.ubuntu.com pls?
<elmo> preferably first
<elmo> err
<elmo> sorry, synxprocy.ubuntu.com
<Nafallo> daniels: and are there any solutions in sight or should I try to compile the kernel with CONFIG_DRM=m?
<Kamion> elmo: syncproxy?
<elmo> Kamion: yah, it's what mirrors are going to sync off of
<elmo> well are
<Kamion> elmo: I was checking the typo correction :)
<elmo> oh, duh, right
<daniels> Nafallo: well, I have other things to do today (mainly, upload xorg), but it's on my todo list to look at.  if you can beat me to a solution, sweet deal
<jdub> daniels: dude
<jdub> daniels: rock!
<daniels> jdub: ?
<jdub> daniels: itax
<daniels> oh, right
<Nafallo> daniels: oki. as written I have to study, but I'll look into it this weekend if you haven't practiced magic and solved it :-).
<daniels> I thought you were stoked about itax being on my TODO
<daniels> cool, thanks
<Kamion> elmo: done
<lamont> jdub: I suppose we _could_ have mutt Recommend MTA, but that just feels wrong.. :-)
<jdub> daniels: itax is on your todo?
* Nafallo goes back to study :-/
<elmo> Kamion: tnx
<daniels> jdub: s/itax/fglrx/
<Kamion> oh, crap
<Kamion> mdz,jdub: can I put system-config-kickstart in supported?
<Kamion> part of the kickstart feature goal, I'd forgotten it was still in universe
<lamont> jdub/mdz: permission to make the seed changes for the mta moving?>
<lamont> or do we  need to discuss it more?
<lamont> I think that the recommendation is consistant with the decision in the tech board.
<elmo> Kamion: fyi, we now have a kick ass us.archive.u.c, if you want a real world use case for the installer changes ;)
<lamont> elmo: will we also have a them.archive.u.c? :-)
<Kamion> elmo: oh damn, didn't get round to doing that today ..
<elmo> lamont: we.have.whatever.you.god.damn.want.archive.u.c
<lamont> lol
<elmo> see now, I have to go update my sources.list to use that
<jdub> Kamion: yes
<elmo> hmm, woops, helps if apache knows about the wildcard
<Kamion> jdub: done, thanks
<jdub> lamont: feels a bit early, given lack of feedback
<lamont> jdub: is ok post-feature freeze, then?
<lamont> assuming feedback goes that way, of course.
<jdub> lamont: i think so, it is a change we've planned for
<jdub> and not really a feature
<jdub> it's a defeature if anything ;)
<lamont> well, one could argue that point either direction, but OK.
<lamont> well, having postfix uncrippled would be a nice bugfix/feature
<jdub> heh
<mdz> Kamion: yes
<lamont> Kamion: the liveCD's from this morning have the -15 kernel in them, yes?
<mdz> lamont: it's after 1700 and I haven't made it to ubuntu-devel (~3rd in mailbox order:)
<Kamion> argh, complicated parsing bug in kickseed
<lamont> Kamion: that's what you get for parsing complicated things, no? :-)
<Kamion> lamont: -15> yes
<elmo> mdz: slacker
<Kamion> well, kickstart files use shell-style quoting, so I was running them through eval as a cheap way to dequote them
<mdz> thom: gtimelog?
<Kamion> but now I discover that they have unquoted metacharacters (specifically pre-crypted md5 root passwords start with $1$ ...)
<lamont> mdz/jdub: but it's ok to go change 'exim4 | mail-transport-agent' to 'postfix | mail-transport-agent' everywhere in main/restricted, yes?
<daniels> Kamion: d'oh
<lamont> Kamion: ouch
<mdz> Kamion: what do you think about the sudo group patch?
<Kamion> mdz: I still have trouble with the name, I think adm/admin is asking for confusion
<jdub> mdz: (rock!)
<mdz> Kamion: I agree, but I haven't a better idea
<mdz> jdub: how about you?
<mdz> jdub: (name for the group)
<dilinger> not bad.  57 seconds between the grub prompt and gdm prompt
<Kamion> how about 'rootsudo'?
<elmo> mdz: svn co http://mg.pov.lt/gtimelog/svn/ gtimelog
<mdz> sudo is taken for something else
<dilinger> (including hostap firmware uploading and dhclient pauses
<mdz> elmo: is it usable?
<Kamion> although rootsudo is a bit insanely implementation-specific
<mdz> I've tried some other programs like that and found them less than ideal
<tseng> sudoers might be valid
<elmo> mdz: dunno, haven't tried, but the lunchpadders seem keen
<jdub> mdz: admin seems confusing to me too
<jdub> mdz: we really want to avoid 'wheel'?
<elmo> mdz: it's written by Marius, who was at Mataaro
<Kamion> jdub: wheel is gid 0 on BSD, ultra-confusing
<elmo> so if it's usable enough, he's probably persuadable to fix it the rest of the way
<jdub> Kamion: mmm, true
<jdub> WDOD? (what does osx do?)
<Kamion> OS X uses the wheel group, I think
* jdub really has to reinstall his ibook
<elmo> I guess 'r00t' isn't an option?
<Kamion> oh, wheel -> admin in OS X >= 10.3 apparently
<mdz> jdub: yes, wheel has too much baggage
<jdub> Kamion: hmm
<Kamion> (http://developer.apple.com/documentation/Security/Conceptual/Security_Overview/Concepts/chapter_3_section_9.html#//apple_ref/doc/uid/TP30000976-CH203-TPXREF121)
<mdz> jbailey: so your hotplug upload, does it address the ide-generic-loaded-last issue, or not yet?
<Kamion> I also think <= 8 characters would be a good idea
<mdz> agreed
<elmo> why do we need a group again?
<mdz> elmo: adding users to a group is simpler than modifying /etc/sudoers
<mdz> lets users add new users with admin privileges using the GUI
<mdz> prevents us from having to edit /etc/sudoers on the fly during install
<Kamion> I dunno, I guess admin is OK, it's really adm that's misnamed
<mdz> though i don't think the current patch implements that last bit yet
<mdz> admin is the least evil of those we've discussed
<jdub> i endorse admin
<mdz> confusion >> accidental vulnerabilities
<jbailey> mdz: No, but because PCI is loaded first, I think that should take care of it.
<infinity> You can't use "wheel"... "wheel" is gid 0 on many systems (same as "root" on Debian/Ubuntu)
<infinity> That's just confusing as all get out.
<jbailey> mdz: (I'm just running off for food, I'll reply as soon as I'm back)
<mdz> jbailey: for coldplugging anyway, which is all we really care about I think
<Kamion> infinity: yeah, I mentioned the BSD case above and I think everyone agreed
<Kamion> OK, I'll implement it with admin then
<jdub> mdz: so, would it be dangerous to assume that people who should have sudo access (admin group) also be able to read logs and so on (adm group)?
<Kamion> argh, the patch is evil though
<jbailey> mdz: For this round.  I'm going to provide a setup and work with dilinger to try and solve the ide hotplug thing properly.  No real idea on timing for it, though.
<Kamion> it randomly allocates gid 80 for itself
<jdub> or am i missing some of the love that adm gets?
<mdz> jdub: I don't think we can safely change ownership of log files to admin, if that's what you mean
<Kamion> jdub: one change at a time ...
<mdz> jdub: what Kamion said, and also "feature freeze" :-)
<jdub> mdz: no, don't go too far forward, only asking exactly what i asked :)
<Kamion> hm, so, I think I'm going to implement the admin group as a normal system group, not one in the 0-100 range
<Kamion> 0-99
<Kamion> although I could be persuaded otherwise
<mdz> I don't think it needs to be in base-passwd
<Kamion> however I was kind of hoping to avoid branching base-passwd for Ubuntu
<infinity> Kamion : There's no real reason to have a static group at all, is there?
<mdz> addgroup --system seems fine to me
<Kamion> since I'd have to allocate the gid in both places anyway
<Kamion> infinity: can't think of one
<infinity> I thin kthe only problem you may run into is that a couple thousand users out there may already have groups named "admin".
<Kamion> that is indeed uncomfortable; we won't be making this change on upgrades though
<infinity> In which case, you want to name yours "Homage-to-Debian-Exim"
<Kamion> (it's just too complicated and error-prone to try to do it on upgrades)
<daniels> inf	heh
<infinity> Kamion : Oh, is this a base-config change, not owned by sudo?
<Kamion> ... which means that users-admin probably needs to check for %admin in sudoers and print "you lose, kthxbye" otherwise
<Kamion> infinity: no, it's owned by sudo, but the sudoers file won't be changed on upgrade
<Kamion> we can release-note it anyway
<infinity> What if I install sudo after having created an admin group?
<Kamion> sudo's in Ubuntu base so that would only happen on Debian->Ubuntu sidegrades
<infinity> Check.  Let the Debian users work it out.  They're supposed to be smart.
<Kamion> I could print a scary warning though
<daniels> (in which case, you've already lost on group memberships anyway)
<mdz> Kamion: do you have an opinion on lamont's MTA proposal?
<infinity> Kamion : Well, if you're already testing upgrade vs. fresh install to determine whether or not to add the bits to sudoers, you may as well just test for the existance of the group too, and treat that as an upgrade.
<infinity> Kamion : No warnings required then, just a small loss in fucntionality.
<Kamion> mdz: it still feels wrong to me to ship without a mail-transport-agent and I'd much rather have Keybuk's dummy one, but if it can be made to work I think it's probably better than the current broken-postfix situation
<Kamion> infinity: the corner cases worry me, because both sudo and passwd need to ensure that the group exists
<mdz> lamont: I say let's do it; if we decide that it was a huge mistake, it's a simple matter to migrate to Keybuk's mini-MTA
<Kamion> infinity: I think I might just print a warning; if you're installing sudo from scratch, chances are it's part of a relatively small upgrade anyway
<daniels> Kamion: alternately, you could touch /var/lib/sudo/.have-i-created-the-group-yet
<mdz> that could very well happen
<mdz> but at least we'll have tried it
<infinity> daniels : How does that help?
<infinity> Kamion : What does base-passwd do on upgrades if a change it wants to make clashes with a group/user already on the system?
<Kamion> infinity: base-passwd always asks, but its situation is different
<Kamion> I'm just going to go with the scary warning, I think
<infinity> Well, given the sensitive nature of a "default admin group", that would be the only reason I'd treat it carefully.
<jdub> Kamion: sounds good
<jdub> Kamion: really happy this is going in :-)
<infinity> Make the scary warning blink. :)
<Kamion> WARNING: An admin group already exists! This group is used to grant root
<Kamion> privileges. Please audit the membership of your admin group and make sure
<Kamion> this is appropriate.
<Kamion> added "using sudo" after "root privileges"
<jdub> that was my only suggestion
<infinity> That should do.
<jdub> which i didn't even have time to fully type :)
<Kamion> actually
<Kamion> sudo's postinst already has code to ask you whether you want to abort the installation if gid 27 is not sudo
<Kamion> so it clearly cannot be a problem to do the same thing for admin :)
<infinity> I'd say not.
<infinity> Since admin is far more important than sudo.
<infinity> Wait, gid 27 is sudo?
<Kamion> yes
<infinity> Is that an Ubuntu-only thing? :)
<Kamion> hell no
<Kamion> <cjwatson@cairhien ~/src/debian/base-passwd/trunk/base-passwd>$ grep sudo group.master
<Kamion> sudo:*:27:
<infinity> Oh, wait.
<Kamion> that has been in Debian since at least 1996
<infinity> Wrong system.
* infinity crawls back.
<infinity> I was on a NetBSD box.
<mdz> is Keybuk in .za?
<jdub> hrm
<jdub> is there a shell builtinish way of determining if a string is in a variable?
<daniels> mdz: not that I know of
<Kamion> jdub:
<Kamion> case $var in
<Kamion>     *string*)
<Kamion>         do stuff
<Kamion>         ;;
<Kamion> esac
<jdub> ah, sensible - thanks!
<lamont> jdub: if it's at the start or end, you can use ${var#string} or ${var%string}
<lamont> and then compare to $var
<jdub> no, variable will be \n delimited
<lamont> ew
<jdub> i could do space delimited
<jdub> other option is grep, but i'd like to avoid that
<jdub> this is a rarely true branch in a tight loop
<mdz> it's shell; how tight could it be? ;-)
<Kamion> actually, I have an even better idea: let's do the %admin user business in passwd.config, where the initial user is created, and not in sudo.postinst at all
<Kamion> that way there is no risk that it might affect upgrades
* jdub stops prematurely optimising, and uses grep
<infinity> jdub : You know you'll just have to optimise it later when that shell script reaches 500k.  Why not start early?
<mdz> daniels: when do you expect to upload new xorg?  the duplicate bugs are coming fast and furious
<mdz> Kamion: that sounds right
<daniels> mdz: to be fair, most of the bug noise was me triaging ;) but hopefully today.  i'm just getting all the stuff I need to build and test X installed on the amd64 (given the implosion of my desktop yesterday), so hopefully tonight?
<lamont> "never unroll loops" heh.
<Kamion> mdz: ok, simpler shadow-only version uploading
<tritium> trulux, I'm back.  How's the LaTeX going?
<lamont> is there a working undelete for ext3?
<robertj> lamont: not that I know of, is there a reason for that question?
<lamont> yeah
<robertj> what happen?
<Kamion> not to my knowledge either, save for trawling through the disk for blocks you recognise
<lamont> I wanna undelete a bunch of files I just nuked
<Kamion> AFAIK ext3 zeroes the inodes
<lamont> not difficult to recover, just annoying
<mjg59> lamont: There's no undelete
<lamont> oh well.
<mjg59> You might get some stuff by grepping through the disk
<lamont> not worth the pain
<robertj> yeah I've grepped stuff back into existance
<lamont> it's just a few downloads from today that will have to be done again.
<Kamion> night all
<lamont> night Kamion 
<lamont> actually, there were some dups, so I can actually recover much of it
<jdub> $ dpkg -L xscreensaver | grep s.desktop$
<jdub> /usr/share/control-center/capplets/screensaver-properties.desktop
<jdub> /usr/share/control-center/Desktop/screensaver-properties.desktop
<jdub> /usr/share/control-center-2.0/capplets/screensaver-properties.desktop
<jdub> /usr/share/applications/screensaver-properties.desktop
<jdub> 
<jdub> elite!
<AndyFitz> skills that killz
<daniels> jdub is the vanillah killah
<jdub> and i make yo momma cry
<srbaker> anyone here know JL Boers?
<srbaker> anyone here using a T22 and getting middle clicking or scrolling?
<mdz> daniels:ok, mumble mumble feature freeze mumble mumble
<jdub> ogra: xss patch in :)
<mdz> daniels: so VT switching actually works for you on the live CD?
<robertj> are the gnome vfs handlers universally b0rk?
* lamont goes to run an errand
<Rotund> I want to get Ubuntu to auto-detect multiple video cards.  what is the program the installer uses to call xresprobe?
<mdz> Rotund: xserver-xorg.config
<mdz> Rotund: and the person maintaining it is daniels
<Rotund> great.  
<Rotund> thanks
<Rotund> how do I get that file?  I'm still on warty and don't want to add repositories
<Rotund> would it be in xorg_6.8.1.orig.tar.gz?
<farruinn> Rotund: you're talking about mixing warty and hoary, not a fun thing
<Rotund> yeah.  I know.  I just want the latest xserver-xorg.config
<Rotund> I upgraded to hoary a while ago and it crashed too much for my tastes
<Rotund> (I'm sure it's better now, but still little desire)
<mdz> Rotund: apt-get source xorg
<mdz> with a hoary deb-src entry in /etc/apt/sources.list
<Rotund> ohhh.  that's smart, but I just found it too
<Rotund> thanks
<Rotund> how would Ubuntu deal with such things
<Rotund> I know the general idea is "it just works"
<Rotund> obviously, with dual-head would mean one would need to at least need to determine the monitor configuration (which is 1, 2, etc)
<jdub> Rotund: that'd be a very welcome hack
<Rotund> and the no NVIDIA driver in the default makes it even harder
<Rotund> jdub: great.  I know I missed it on my wife's computer w/ 3 monitors
<Rotund> I need to talk out how it should work
<Rotund> would a Windows style "display properties" be easier?
<jdub> i thought about this a while back
<Rotund> great.  what was your thoughts?
<jdub> setting up a configuration by default would be most useful
<jdub> the only way you can really do that sanely is:
<jdub> - only enable heads that have monitors attached (ie. you can get ddc info)
<Rotund> great idea
<Rotund> BTW: which discover does hoary use?
<HrdwrBoB> AGP->first pci card->second pci card left to right default config
<jdub> - only enable multiple heads if you can determine a 'primary' output in a reasonable way (ie. on dual head cards, that's easy, on an agp+pci machine, you'd be making a reasonable assumption, on other machines it would be tougher)
<jdub> Rotund: xresprobe and ddcprobe, you'd have to run these on each available video card output
<zul> there kernel team stuff added to the wiki
<jdub> - if you can't enable it by default given the above points, add the configuration to xorg.conf but comment it out
<Rotund> okay.  currently it looks like xserver-xorg.config uses discover
<jdub> - having a display properties page that was gnomey and sexy and handled this kind of stuff would be ideal, but also very hard
<Rotund> okay
<Rotund> Another question (as people have asked me).  How do you have ubuntu auto detect the vid card again?
<jdub> should all be in the .config
* daniels springs up from having passed out on the couch and had weird dreams.
<jdub> hotplug loads the right drivers, though
<daniels> jdub: actually, you don't get to do multi-card DDC outside the X server
<daniels> only the primary one, since we call via VIE
<daniels> er, VBE
<jdub> daniels: so you'd have to run X to do the ddc? that doesn't sound terrible
<daniels> jdub: it's not terrible, but parsing the log output is pretty horrific
<jdub> so, assuming you can parse the log output sanely, is running X for ddc something you'd want to avoid in the common case (1 output)?
<Rotund> so, the installer would have to boot x?
<HrdwrBoB> I would think so, but you couldn't tell without starting X
<daniels> jdub: it can be done, but 'sanely' is pushing it
<jdub> Rotund: the install process already does
<Rotund> really?
<Rotund> did it in warty?
<daniels> well, not for DDC
<daniels> but if you're on a laptop, second-stage installer fires X up
<infinity> daniels : I assume the latest nv driver knows how to make my card go?
<infinity> daniels : warty on my new machine was less spectacular than I'd hoped. :)
<infinity> (Well, until I installed the binary driver..)
<Rotund> the nv driver isn't too good
<daniels> infinity: Yeah, nv in Hoary should be fine.
<infinity> Rotund : It's good enough to make a livecd work.
<Rotund> I'm assuming the nvidia driver will never be on the default install CD?
<infinity> Having a system try really, really hard to boot to X, then dump to a console and flip you the bird is no fun.
<Rotund> =)
<Rotund> I didn't have that issue w/ mine, but I had an old card at the time
<infinity> Yeah, mine was a shiny new 6800GT.
<infinity> It's been a long time since I had a card newer than the X driver I was trying to run.
<infinity> I'd almost forgotted that happens.
<Rotund> oh yeah.  no chance on the ancient XFree drivers =)
<daniels> 686-smp covers that just fine
<Rotund> really?  I just saw i686 and thought an original Pentium wouldn't work
<Rotund> If it supports i586, why not call it i586?
<daniels> Rotund: 686 is original pentium, iirc
<Rotund> no, 686 is the P2 (perhaps PPro too)
<daniels> interesting.  in any case, what's out ther eas '586' certainly isn't the pentium.
<Rotund> 586 is the Pentium, Pentium MMX, x586, MII (I think), K5
<Rotund> I think the Media GX was 586 (guess when I was really into hardware)
<Rotund> is XOSD supported on all video cards?
<Rotund> general X question.  Does xinerama need for each screen to be the same display resolution?
<Rotund> (all be 1024x768)
<HrdwrBoB> no
<Rotund> great
<HrdwrBoB> xinerama has massive limitations though
<Rotund> oh?
<HrdwrBoB> eg: no 3d
<Rotund> yup
<HrdwrBoB> video overlay can be .. weird, or not work at all
<infinity> daniels : Why bother enumerating unsupported cards?... if it's unsupported and lspci thinks it looks like a VGA adapter, just throw a signal at it.  How bad can that go? :)
<Rotund> yup.  and the sleep stuff too
<infinity> daniels : Windows has been managing that for ages with very little side effect.
<infinity> daniels : The odds of it being both unsupported AND not a PCI VGA device are so slim, you'd cover pretty much all cases of unsupported cards being able to display /something/.
<Rotund> what is the program that dumps the hard to parse info about the current screen?
<Rotund> HrdwrBoB: I also noticed xrandr didn't work in xinerama
<HrdwrBoB> xdpyinfo
<Rotund> BRB
<daniels> infinity: 'Swhat we do, but if it's from a specific vendor (ati, nvidia, intel), and we don't know about it, we throw it at the default driver for that.
<infinity> daniels : ... Which breaks if the default driver doesn't support my new PCI ID, so why bother?
<jdub> daniels: is there a known problem with agpgart not loading in current X?
<daniels> infinity: discover1-data was in sufficiently bad shape, even after I loved it quite extensively, that this was IMO the best choice.
<daniels> jdub: Er, loading agpgart isn't X's job.  It's hotplug's.
<jdub> daniels: i am being sleepy
<jdub> daniels: s/X/kernel/
<daniels> jdub: not sure, sorry -- seems to work fine
<marcin_ant> jdub: hi
<marcin_ant> jdub: could you tell me something about "ImprovedPanel"
<marcin_ant> jdub: from "secondary goals" section
<marcin_ant> jdub: from http://www.ubuntulinux.org/wiki/HoaryGoals
<daniels> fuck me
<daniels> jdub: http://gnome-look.org/content/preview.php?preview=1&id=18178&file1=18178-1.jpg&file2=&file3=&name=Tobacco+Sky&PHPSESSID=09b3ea2d25052f3ba8ff2b0c8d93d8e6
<daniels> jdub: also, http://www.gnome-look.org/content/show.php?content=17346&PHPSESSID=c43d53d9d12edc60e4ae0849b45a9c93
<infinity> Purdy.
<Rotund> which would be more "gnomey" an Advanced tab or an Advanced button for configuring the finer details of the video card?
<Rotund> (adding options, changing driver, etc)
<Rotund> or none of that at all?
<daniels> wow, this amd64 si frighteningly fast.
<daniels> Rotund: neither, really
<Rotund> okay.  so someone should have to manually edit their config file to change from nv to nvidia?
<Rotund> (Okay this is probably somewhat outside what GNOME should be doing in the first place... more of a distro thing)
<daniels> Rotund: that said, a graphical utility would be absolutely welcome
<Rotund> =)
<Rotund> okay
<daniels> the plan for hoary was to have the package just set up, out of the box, something that *worked*
<daniels> if you wanted to get fancy, we could have an all-singing, all-dancing graphical utility
<Rotund> how do I get xresprobe to do something?
<daniels> the former has been largely satisfied ...
<daniels> er, run it? :)
<daniels> sudo xresprobe $drivername
<Rotund> what is the $drivername?
<Rotund> =) sudo =)
<jdub> the name of the driver for your card
<Rotund> what happens if I have 2 nvidia cards installed?
<jdub> no idea
<Rotund> or in my wife's case, 3 ati cards =)
<daniels> Rotund: many things, none of which are the right thing
<Rotund> SWEET
<daniels> well, it's the right thing for the installer, but not the right thing to set the cards up
<daniels> it's kind of misleading, because all it does is asks the VESA BIOS 'hey, what up'
<Rotund> NICE
<daniels> this means it will only ever ask one card (i.e. $drivername is meaningless unless you're on a laptop), and that card is determined by the BIOS
<Rotund> okay.  So, what should I use instead?
<daniels> errrrrr
<HrdwrBoB> Rotund: or in my case
<HrdwrBoB> the name of one card
<HrdwrBoB> and the attached monitor of the other
<HrdwrBoB> in any case, it doesn't produce meaningful results
<daniels> you probably want to look at xprobe.sh and lcdsize.sh, and look into starting X with -probeonly, and grepping the log
<daniels> unfortunately, the grep logic in this case will be totally batshit insane
<Rotund> Also, mine is stupid as it has the right monitor and the wrong specs anyways =)
<daniels> if you're using warty, then yes, the sync ranges calculated are not necessarily what your monitor can do
<Rotund> no, it only goes to 1024x768.  of couse, my monitor is currently at 1600x1200
<daniels> cool
<Rotund> ummm.  something like that
<daniels> if that's hoary doing it, i'd love to know about it
<Rotund> no, I'd have to reboot to the live CD
<Rotund> too lazy =)
<Rotund> Does it use a lookup table or just ask?
<daniels> it probes the monitor for its list of supported resolutions
<daniels> in the case of a laptop, it starts up X and looks for a rather complicated list of magic strings
<daniels> if it really has no idea, it asks
<Rotund> okay. 
<Rotund> it's a desktop
<Rotund> CRT screen
<Rotund> DELL P780.  It hasn't detected it right yet
<Rotund> why does this work?  sudo xresprobe nvidia23
<daniels> because the driver argument is unused unless you're on a laptop
<Rotund> It's hard to try to get a display properties that doesn't have the ugliness of the advanced screen from Windows
<daniels> in the future, it may be used
<Rotund> 23?
<daniels> it depends how seriously we go down the grep-x-log-for-ddc-results insanity path
<daniels> er, yes.  dude, it's unused.  nothing looks at it, unless you're on a laptop.
<daniels> i routinely enter x in there
<fabbione> morning guys
<Rotund> hahah
<Rotund> morning
<jdub> anyone got openoffice.org2 packages installed atm/
<jdub> ?
<tritium> jdub, yes
<jdub> tritium: can you see if the .desktop files are separated into the subpackages, ie. openoffice.org2-writer
<tritium> jdub, sure
<Rotund> daniels: xresprobe only looks for the following above 1024x768.  1280x1024x75
<Rotund> THAT'S IT
<Rotund> even the newest version
<daniels> ok, so your monitor's lying
<tritium> jdub, they are separate
<tritium> ooo2-calc.desktop, etc.
<jdub> tritium: ie. that particular file is in openoffice.org2-calc?
<tritium> jdub, yes, checked with dpkg -L
<jdub> thanks
<syn-ack> Hey everyone.
<tritium> jdub, sure.
<Rotund> daniels: my monitor can only do 1280x1024 at 72, so it didn't lie
<daniels> Rotund: ok, so what's the actual probleM?
<Rotund> xresprobe doesn't detect much above 1024x768
<Rotund> does it detect anything better on your monitor?
<daniels> what?
<daniels> dude, it detects exactly what your monitor reports
<tritium> jdub, out of the available 13 packages, calc, draw, impress, math, and writer have .desktop files
<Rotund> what does sudo xresprobe return on your monitor?
<daniels> for me, this is 1600x1200 and everything below it, in nice little increments
<daniels> right now?  absolutely nothing, since I'm on amd64
<daniels> but on the i386, it returned a *lot* of resolutions, many of which were above 1024x768
<daniels> i can assure you that there is no bug in xresprobe
<daniels> it feeds through exactly what your monitor reports back
<Rotund> daniels: interesting. because looking at the code, I can't see how that's possible
<daniels> if you dislike the resolution reported, take it up with your monitor manufacturer
<daniels> you can't see how it's possible?
<Rotund> daniels: look at ddcprobe.c
<daniels> i can't see how it wouldn't be, but there you go
<daniels> Rotund: which bit?
<jdub> tritium: rocking, thanks
<tritium> yup
<Rotund> daniels: line 179-209
<daniels> Rotund: established timings are irrelevant
<Rotund> oh?
<daniels> Rotund: everyone uses custom timings or detailed timings, which are freeform in terms of the values you can put in there
<daniels> yes
<Rotund> ahh
<Rotund> okay.  so that's what that last part does?
<daniels> yes
<daniels> the bits that spew out ctiming: and dtiming: lines
<Rotund> that makes sense then
<Rotund> where's the code for xresprobe?
<lamont> Kamion: yesterday's ia64 livecd doesn't find the cdrom... :(
<Rotund> ahh... script w/o a .sh neverming
<fabbione> hey lamont
<fabbione> mind to send me your ssh pub key?=
<fabbione> so i can setup the access to the sparc buildd
<lamont> fabbione: sent
<Rotund> daniels: actually, ddcprobe gets the info right and ddcprobe does not
<fabbione> lamont: thanks
<Rotund> daniels: .sh does not
<Rotund> daniels: would you like my output from ddcprobe
<fabbione> lamont: i will send you an email back with how to access.
<lamont> thanks
<daniels> Rotund: yes, although this may merely be a feature
<lamont> and remind me what I'm doing and when...
<Rotund> =)
<daniels> Rotund: if you look at ddcprobe.sh, it will throw away the top resolution since this is never the native resolution on crts
<Rotund> oh
<daniels> s/native/optimal/
<daniels> if you have an lcd, it will take the top mode and run with it
<Rotund> okay.  that's it then.  it's the top one as the 1280 ones aren't mentioned
<Rotund> that works then.  thanks
<daniels> np
* lamont falls into bed
<fabbione> night lamont
<daniels> lam	night dude
<fabbione> lamont: you don't have ipv6, do you?
<daniels> mako: http://mako.yukidoke.org/copyrighteous/images/muppet_hat_2-small.png
<daniels> mako: dude, that is so emo.  you look like you're about to cry.
<mako> jordi: dude
<mako> daniels: is that emo?
<daniels> mako: crying is very emo
<tseng> you cant be emo wearing white
<tseng> its a strict rule
<mako> i was trying to look very serious
<mako> so i realized i look a lot like the EPA guy from ghostbusters.. i'm looking for pix
<tseng> hm youre right
<Rotund> is there a language that the x log parser should be in?
<Rotund> I'd assume something higher level would be better
<daniels> Rotund: probably python, but dude, it's a bitch to pars
<Rotund> I'm sure
<Rotund> =)
<daniels> the problem is that you can detect when you're getting xf86PrintEDID() output, but you need driver-specific smarts to work out which head that DDC info is for, e.g.
<Rotund> BTW: NVIDIA prints WAY different output
<daniels> way to go nvidia
<Rotund> =)
<daniels> most of the DDC stuff should be in one standard form (i.e. that from xf86PrintEDID())
<Rotund> I'm a tester during the day.  all I do is parse
<daniels> but, that being said, I can't say that I've seen an nvidia (i.e. driver nvidia, not driver nv) log file recently
<Rotund> (**) NV(0):  Default mode "1152x768": 65.0 MHz, 44.2 kHz, 54.8 Hz
<Rotund> (II) NV(0): Modeline "1152x768"   65.00  1152 1178 1314 1472  768 771 777 806 +hsync +vsync
<daniels> er, that's not what you're looking for
<Rotund> (**) NVIDIA(0):      Default mode "800x600": 49.5 MHz, 46.9 kHz, 75.0 Hz
<Rotund> (**) NVIDIA(0):      Default mode "800x600": 50.0 MHz, 48.1 kHz, 72.2 Hz
<Rotund> it's not?
<daniels> nope
<daniels> you're looking for the DDC output
* dilinger sighs
<daniels> grep for 'EDID Version'
<Rotund> I think that's it
<dilinger> i'm not sure whether it's the hardware or warty's kernel, but this machine keeps freezing :/
<Rotund> Validated modes for display device CRT-0:
<Rotund> okay
<daniels> Rotund: no, you do not want the validated modes
<daniels> you want the DDC output
<Rotund> what's a validated mode?
<Rotund> there are a bunch of resolutions in there that are not described in my config file
<daniels> this is well offtopic for #ubuntu-devel at the moment.  but basically all you need to know is that you're after what the monitor says is can do, which is in the DDC packet.  to find this, grep for 'EDID Version' and look around there'.  the mode stuff is useless as it's every mode X knows about, constrained by your configuration.  so if it's not set up right, it's useless to you.  and if you're probing, it isn't set up right by definition.
<zenwhen> daniels, is gnome-volume-applet currently iconless for you?
<Rotund> Really?  That's odd as it actually mentions a lot of things not defined in my configuration (resolutions and refresh rates)
<daniels> zenwhen: works fine for me
<daniels> Rotund: 'every mode X knows about, constrained by ...'; please read what I'm saying
<zenwhen> odd, It has no icon for me and I have to hunt for it. Its clickable area is an invisible line.
<zenwhen> lol
<zenwhen> newest hoary packages
<dholbach> good morning
<tseng> hey there, dholbach 
<dholbach> hai tseng
<dholbach> those guys at dumbledore.hbd.com want to "own" the channel ;-)
<morgs> dholbach: Eh, we're all sitting at the other end of a long thin pipe, and we want to see our updates before we all try to grab the debs at the same time!
<dholbach> morgs: you then should get yourself some apt-proxy :-)
<Rotund> interesting.  the nv driver supports running from either of the two outputs on my vid card, but can't do both at the same time!
<daniels> that's common
<Rotund> really?
<Rotund> weirf
<Rotund> BTW: could you answer my last question for the night from the pm
<magnon> woah, someone just yelled "APPROVED" in my face :)
<magnon> that one was a bit over the top
<daniels> Rotund: what was that?
<tseng> http://higgs.djpig.de/ubuntu/www/ < hmm
<tseng> rock.
<dholbach> tseng: cool
<jdub> heh
<jdub> rad ;)
<jdub> elmo: http://higgs.djpig.de/ubuntu/www/
* jdub whistles innocently 
<jdub> Mithrandir: did you end up doing guifications? what were the cool features in that?
<Mithrandir> jdub: yes, but it's still stuck in Debian's NEW.  I can just upload it to ubuntu; I assume elmo's not too happy about doing debian NEW processing to get stuff into ubuntu?
<drbyte> jdub: kernel maintainership on ubuntu/ppc, you still don't have anyone ?
<fabbione> drbyte: we still don't have an official responsable for the port
<drbyte> fabbione: hmm, okay. if you're still stuck say in March (when back in Melb, and my ppc hoard), i'd gladly help out. i do fedora/ppc (mainly still ppc32), and am aiming for them to run on pegasosppc hardware as well
<fabbione> drbyte: that's nice. thanks
<fabbione> i like the idea of multi distro kernel team
<fabbione> and that's what is coming up now
<drbyte> fabbione: though we're pretty anal about making sure we stick to upstream kernels (very few ppc specific patches)
<drbyte> fabbione: are ya'll comfortable with adding the new iBook/powerbook g4 sleep patches, and so on? that would rock, but we can't mainline it (policy-wise)
<jdub> Mithrandir: heh, don't think so, no ;)
<fabbione> drbyte: it depends. we discuss patches in the team
<pitti> Morning
<fabbione> clearly upstream bugfixes are always welcome
<drbyte> fabbione: ah, okay. so i'm guessing i should joing ubuntu-devel-list soon. yal
<fabbione> for external patches/features we are a bit more conservative
<fabbione> in terms that we include stuff that has an active upstream
<fabbione> but kill dead stuff
<fabbione> if upstream dies
<drbyte> ok.
<drbyte> fabbione: i'm no DD, i make rpm's well, but is the preferred debian/ubuntu method make-kpkg ?
<fabbione> drbyte: kinda.. yed
<fabbione> yes
<fabbione> it's a debian package, but there is a "packager" in the team
<fabbione> so you don't really need to worry too much about it
<fabbione> in terms that you can help the ppc side just providing patches or link to the Changesets
<fabbione> or stuff like that
<drbyte> ok. sounds good. that means i might not even need ubuntu on ppc yet :P
<fabbione> drbyte: well clearly testing the kernel is kinda mandatory
<drbyte> fabbione: i know.. i was just joking ;-)
<fabbione> specially if you want to take responsability towards the community :)
* drbyte has to test on fedora/ppc, specifix/ppc, and soon, possibly ubuntu/ppc
<drbyte> fabbione: so discussion on the list, i presume?
<fabbione> drbyte: yes. we are using ubuntu-devel as a starting point with [kernel]  prefix in the subject
<fabbione> if there will be enough traffic, we will ask for a mailing list
<fabbione> but most of the work is done on irc (here)
<fabbione> and stuff will be soon on the wiki
<fabbione> (after yesterday's kernel team meeting)
<drbyte> ok. i'll suck hoary down soon(ish) for ppc
<fabbione> cool
<dholbach> jdub: could you give a brief etymological talk on the word "rad"? i read it everywhere nowadays and since i'm a non-native speaker, you could surely enlighten me a bit :-)
<jdub> dholbach: it's short for radical, which is in the dictionary ;)
<dholbach> jdub: ah... yes - should be :-)
<jdub> dholbach: stupid english speakers ;)
<dholbach> jdub: stupid non-native english speakers - i had no imagination 
<tseng> dholbach: have coaster debs online somewhere?
<dholbach> tseng: i'm working on them, bryan just released 0.1.4.2 and i'm still sorting the auto*-doing-{post,pre}{rm,inst}-stuff out
<tseng> ok.
<tseng> whatever the issue is, ill blame him
<dholbach> hai mvo_
<mvo_> hi dholbach 
<mvo_> morning all
<jordi> mako: dude?
<jdub> mvo_: yo
<jdub> mvo_: do synaptic and apt-get share their pinning/on-hold status?
<haggai> mdz: ping
<bob2> amusingly, aptitude doesn't use the same pinning system as dpkg/apt
<Treenaks> bob2: sounds logical!
<mvo_> bob2: it should honor /etc/apt/preferences?
<bob2> bah
<bob2> hold, not pinning
<bob2> it's too early or late or something for me
<mvo_> :)
<Treenaks> doesn't apt-get honor the dpkg selections stuff?
<bob2> selections, somewhat, holds, yes
<thom> mdz: a pretty sweet pygtk app that keeps track of work done and so on
<mvo_> jdub: synaptic honors the apt pins but uses it's own config file to implement "locks" on versions
<Mithrandir> pitti: glibc change is ok with mdz on the condition that it makes it in before feature freeze.
<Mithrandir> pitti: can you do that?
<pitti> Mithrandir: sure, I can upload it
<Mithrandir> great, thanks.
<pitti> Mithrandir: i. e. it should be done today
<fabbione> not another libc6 update!
<Mithrandir> pitti: yes
<fabbione> :)
<Mithrandir> fabbione: MULTIARCH update. :)
* Mithrandir cackles
<fabbione> why am i afraid that it will break sparc?
<pitti> fabbione: please look at the patch, it looks safe
<pitti> fabbione: http://arch.err.no/index.cgi/tfheen@idi.ntnu.no--2005/pkg-glibc--multiarch--0--patch-2?cmd=cs_new&file=debian/patches/99_multiarch-ld.dpatch
<fabbione> looks ok....
<Mithrandir> fabbione: it should be harmless, but I could test-build it on sparc
<fabbione> Mithrandir: nah.. let the buildd munge it
<fabbione> i am checking one thing only..
<fabbione> gcc -dumpmachine
<fabbione> sparc-linux
<fabbione> is that what you expect?
<Mithrandir> yeah; it should be sparc64-linux or something if you have a sparc64 userland.
<Mithrandir> but sparc64 uses a different loader, so that should be fine, I imagine.
<fabbione> sparc64 gcc -dumpmachine
<fabbione> sparc-linux
<Mithrandir> does gcc -m64 -dumpmachine say the same?
<Mithrandir> well, shouldn't be a problem anyhow
<fabbione> yes
<fabbione> but i have no dirs like /usr/lib/sparc-linux/
<Mithrandir> that's ok, you'll have them later.
<fabbione> ok
<Mithrandir> it just adds them to the path, it doesn't remove anything.
* fabbione thumbs up
<Mithrandir> /usr/lib can't be removed from path in a _long_ time.
<Mithrandir> uhm, ld-linux' path, that is
<fabbione> why on heart ppc is always a porting bitch
<fabbione> 2.6.11 compiles everywhere other than ppc
<daniels> mono is the most hateful evil shit ever
<Treenaks> daniels: you've obviously never tried a jvm
<fabbione> none of you have ever tried a new kernel release on 6 arches
* fabbione larts people with his kernel power stick
<tseng> novell sure makes it hard to find their srpms
<fabbione> [RFC]  Changing COW detection to be memory hotplug friendly
<Treenaks> Moo
<fabbione> next will be: Changing PIGS and BULLS detection to be wifi friendly
<Treenaks> I want CHICK detection!
<Simira> :-)
<bob2> fabbione: you should apply the sleep patch again!
<daniels> VICTORI!!! TAKE THAT, MONO
<daniels> also, VICTORY
<daniels> mono has corrupted my ability to spell
<bob2> From: VICTORY ...
<daniels> bob2: heh
<thom> daniels: what are you doing to mono?
<Mithrandir> thom: torturing it
<fabbione> bob2: there are no updates from benh and today is Feature Freeze. kthxbye
<bob2> dammit
<daniels> thom: dbus-mono
<bob2> no MAD PHAT LAPTOP SUPPORT for ppc then
<thom> daniels: ahr
<thom> bob2: wha?
<fabbione> most his stuff is merged upstream
<fabbione> but not all of it
<bob2> thom: well, for modern ppc laptops
<bob2> ones with radeon 9200 need special love, aiui
<daniels> bob2: sure there is -- a dialog box saying 'should've bought an x40'
<bob2> rofl
<thom> daniels: so not fixoring mono for amd64 then
<jdub> mono 1.1 should be ok
<daniels> thom: no, cool as it would be
<daniels> jdub: doable, with an uvf break? :)
<daniels> as long as it doesn't spaz out and decide to change /usr/lib/mono *again*
<thom> jdub: yes, but it needs total repackaging!
<jdub> daniels: universe
<seb128> is somebody working to fix muine ? 
<jdub> thom: ouch
<jdub> thom: doable for hoary though
<thom> jdub: one source package versus about 3000
<daniels> jdub: i assume that means motu+own time, then?
<thom> that's why i didn't do it
<jdub> daniels: yeah
<daniels> jdub: ah, crap
<daniels> thom volunteers
<martink> jdub: mono 1.1 in universe would rock. No more manual mono compiles to use tomboy on amd64
<jdub> yeah, and beagle on all arches, etc.
<fabbione> jdub: is 1.1 buildable on sparc too?
<daniels> jdub: fwiw, the invocation required is /libdir /usr/lib /gacdir /usr/share/dotnet
<jdub> fabbione: i believe so
<daniels> afaict
<daniels> (as in, dbus-mono makes beagle work, and I don't care beyond there)
<jdub> oh man
<jdub_> pants off
<Treenaks> uh?
<jdub> mr 6dub is very laggy
<bob2> 4in6?
<jdub> 6to4, sipper
<jdub_> so i can say stuff
<jdub_> but not see stuff
<jdub_> or change nick
<bob2> 6inyourPANTS.
<jdub> mvo_: aha
<jdub> mvo_: dude
<jdub> mvo_: installation from web browser
<fabbione> goody.. amd64, ppc, i386, ia64 are GO
<jdub> mvo_: i'm using gnome-app-installer infrastructure to do the web side of that, was going to seed your brain with it ;)
<mvo_> jdub: hehe :) you are subscribed to the packagemanagment wiki page I'm just editing :) ?
<jdub> mvo_: i'm subscribed to all ;)
* mvo_ chuckles
<jdub> mvo_: so i can do a spiffy webpage for you
<mvo_> jdub: that would be cool
<jdub> fun proof of concept, anyway
<EvanCarroll> i just upgraded the style sheet for my website, anyone want to give input
<dholbach> seb128: is http://bugzilla.ximian.com/show_bug.cgi?id=70976 what we would need to get evolution back on amd64?
<mvo_> yeah and cheap to implement
<EvanCarroll> www.evancarroll.com
<bob2> EvanCarroll: this is a technical channel, dude
<seb128> dholbach: no, we already have this fix
<dholbach> seb128: oh ok
<pitti> elmo: xemacs21 sync, please
<pitti> elmo: oops, wait. Actually I just need 21.4.16-2
<pitti> elmo: but sid already has 21.4.17
<pitti> elmo: although 21.4.17 does not contain much more (only other fixes), and it is universe
<pitti> elmo: thus if you don't want 21.4.17-1, please sync 21.4.16-2 (it's still in the archive)
<thom> pitti/jdub: can i break UVF for apache2, please; two security bugs and a lot of changes from debian we want
<pitti> thom: microrelease?
<thom> 2.0.52->2.0.53
<pitti> thom: debian changes = bugfixes?
<thom> (there are a bunch of segfaults and two CANs fixed)
<thom> and yes, debian changes are stuff i'd be taking anyway
<pitti> sounds sane to me, however, I don't have the power to have the final word :-)
* fabbione thumbs up for 2.0.53
<thom> ber.
<thom> mdz/jdub: ping!
<daniels> jdub: dbus-mono 0.23-3, have at it
<jdub> thom: approve
<Mithrandir> seb128: jdub thinks we should have gaim with a non-palindromic version number in hoary, what do you think?
* jdub strings /dev/mem to see if he can recover the file he just *stupidly* deleted
<daniels> jdub: OH MY GOD YOU ARE WORSE THAN THE X SERVER
<daniels> or something
<thom> jdub: do i need both you and mdz to approve?
<seb128> Mithrandir: go for it :)
<jdub> thom: no
<thom> score
* Mithrandir kicks mini-dinstall in the nuts
<Mithrandir> when writing daemon code, please don't close std{in,out,err} without reopening them to /dev/null, kthxbye.
* dholbach does the laundry - bbl 
<daniels> heh
<jdub> oh man
* jdub obviously wrote one to throw away
<jdub> STOP DELETING FEATURES ON FEATURE FREEZE DAY
<fabbione> does anybody have a link to "infiniband" technology?
<Mithrandir> jdub: hmm?
<jdub> Mithrandir: i just deleted a feature.
<fabbione> oh here it is
<daniels> jdub: 6.8.1-1ubuntu16 to be uploaded today with some new features; 6.8.2-1 will come later, breaking uvf (not that it matters, since there's less code churn between .1-1ubuntu16, which has 6.8.x branch, and .2-1 than in most releases)
<daniels> s/releases/ubuntu revisions/
<jdub> man
<jdub> i am such a tool
<daniels> yes
<daniels> but why, specifically?
<jdub> i deleted a feature.
<daniels> which feature?
<jdub> the desktop file sucker which will seed gnome-app-install
* jdub gets on with a rewrite.
<fabbione> http://www.infinibandta.org/ibta/
* fabbione wants stuff like that
<fabbione> up to 100Gb/sec data transfer
<thom> INFINIBAND: ADRENALINE FOR DATA CENTERS
<rubenv> mjg59: or some X/dpms person: ping
<rubenv> my laptop screen does funny stuff I don't trust
<daniels> rubenv: oh?
<rubenv> when i do xset dpms force <something>
<rubenv> it doesn't blank & stuff
<sivang> morning all!
<rubenv> it shows lines & lights up
<rubenv> i don't dare to wait what'll happen in the end
<rubenv> it goes very very scary bright :-)
<daniels> rubenv: ooo.  what sort of video chipset?
<rubenv> nvidia, with nv driver now
<daniels> 'cool'.
<daniels> unfortunately, that's the most productive answer I can give
<daniels> that driver is a black box :\ no-one other than nvidia can do anything with it
<rubenv> no, not the binary nvidia
<rubenv> the open source nv
<rubenv> the binary one does it right
<daniels> yes, even the 'open source' nv, is not open source at all
<rubenv> but the open source one allows suspend to disk
<Treenaks> daniels: scary
<rubenv> perhaps i should go back to binary evil (with no suspend)
<daniels> for instance, fixing a bug on radeon the other day, I changed added save->fp2_gen_cntl = save->fp2_gen_cntl | RADEON_FP2_ON & ~(RADEON_FP2_BLANK_EN);
<daniels> the nv equivalent would ne pNv[0x1234]  = 0x5678;
<daniels> where no-one but nvidia has any idea what those numbers mean
<rubenv> aha, right :-)
<rubenv> unknown specs
<daniels> yeah.  the only people to ever change the nv driver have been nv, really.
<rubenv> damn you nvidia :-(
<Treenaks> daniels: so it's a good thing the laptop I want is Ati 9700 then?
<Treenaks> is/has
<rubenv> so no power management for me then :-/
<daniels> Treenaks: well, you won't get 3d without fglrx, which sucks horribly
<daniels> rubenv: you would appear to lose, yah
<Treenaks> daniels: yeah, but there aren't many other laptops which are almost fully supported AND have 1680x1050 resolution
* rubenv only has the second
<daniels> Treenaks: for 2d it'll be fine
<daniels> and you'll get power management and all that goodness
<daniels> (and I have the specs and full 2D DDK, so when stuff goes wrong, I can fix it, or at least have a go)
<Treenaks> daniels: the reason for not opening up is all patent license stuff, right?
<daniels> Treenaks: ish.  part of it's cross-licenced technology, part of it's just not wanting to let nvidia or whatever get at their chips (raising the barrier to entry to reverse-engineering everything they have)
<daniels> part of it may also be the soundblaster thing -- just not wanting people to make cheap knockoffs of their chips that work with their drivers
<Treenaks> argh
* rubenv goes & switch his X to nvidia drivers
<sivang> rehi all
<rubenv> i'd rather not have my screen burned while i'm showering
<daniels> Treenaks: either way, it sucks, yeah
<Treenaks> daniels: yeah.. and sticking with Intel/Via/S3 sucks too
<daniels> Treenaks: ironically, the most advanced open-source 3D driver is i915
<Treenaks> daniels: VIA sort-of works on sid + unofficial "r30" unichrome patches
<Treenaks> uh patches=patched packages
<daniels> Treenaks: 6.8.1-1ubuntu16 will have unichrome r30
<daniels> we currently have r29 or something
<thom> holy crap, novell just hired the xgl dude?
<daniels> thom: davidr?
<Treenaks> daniels: problem is DRM support in the kernel.. which is too insecure to be included by default (shared-mem video or something)
<daniels> woah yeah, they hired davidr.  jesus.
<daniels> Treenaks: yeah.  something about dri access being equivalent to a free run over /dev/mem.
<daniels> woah, they're hiring him for xgl.  sweet!
<thom> yeah
<thom> that's fully awesome
<daniels> now someone needs to hire anholt, ajax, idr, and brianp specifically for mesa-solo
<daniels> oh, and probably jonsmirl also
* Kamion likes the way most Ubuntu installation reports aren't even about the installer at all
<Mithrandir> Kamion: happy with the answer from the sun guy?
<Kamion> Mithrandir: yep, fantastic, thanks
<Mithrandir> Kamion: are you sending a "thanks a lot" letter or should?
<Treenaks> Kamion: what are they about then?
<fabbione> Mithrandir: did you have any chance to install ubuntu on sparc?
<Mithrandir> fabbione: just dist-upgraded, I haven't gotten around to doing a full install.
<Kamion> Mithrandir: I will do
<fabbione> ah ok
<Mithrandir> fabbione: I can look at it tomorrow if you remind me.
<fabbione> sure i think i can
<Kamion> Treenaks: usually either X or how the installed system works in general
<fabbione> tomorrow i will not be around 100%
<Treenaks> Kamion: ah, so you can just blame daniels and be happy :)
<thom> Treenaks: i think he does that anyway
<fabbione>   NUMA support (ACPI_NUMA) [N/y]  (NEW) 
<fabbione> hmmmm
<Mithrandir> fabbione: just prod me about it, but I'm busy today, so.
<fabbione> no problem
<daniels> Kamion: btw, since you clearly don't have enough work, want to take care of #6296 and #5894? :)
<Kamion> daniels: I have approximately zero idea how keymaps get from d-i to X
<Kamion> I assumed you were guessing them from console keymaps, I think
<daniels> Kamion: afaict we're guessing it from $LANG?
<Kamion> !
<Kamion> that's fucked up
<Kamion> and so, so wrong
<daniels> # Warty change: try to guess keyboard layout from $LANG
<daniels> case "$LANG" in
<daniels>   "bs_BA.ISO8859-2" ) LAYOUT="us,bs" XKBOPTIONS="grp:alt_shift_toggle" ;;
<daniels> ...
<Kamion> maybe we should just use the work Konstantinos has done in Debian on this, and be done with it
<daniels> although that doesn't explain how the dvorak damage gets there
<pitti> daniels: that means that currently an English-speaking guy in front of a Russian keyboard would get an English layout in X?
<Kamion> ok, that needs to die painfully
<Kamion> d-i has a separate keyboard chooser for a reason
<daniels> pitti: seemingly
<pitti> d'oh
* Kamion finds that code. Oh. My. God.
<daniels> maybe there's something I'm missing though, otherwise no-one would get a 'dvorak' layout?
<Kamion> I don't see how anyone does
<Mithrandir> magggic?
<Mithrandir> or nobody but mdz uses dvorak?
<daniels> Kamion: me neither
<daniels> Kamion: if you want to merge Konstantinos's stuff, that would be awesome :)
<fabbione> thom: how can i avoid a specific client to access pages on my web server?
<Kamion> I think I might do
<daniels> Kamion: phat
<fabbione> there is a new search engine that doesn't respect robot.txt
<seb128> jdub: around ?
<Kamion> mdz,jdub: how would you feel about pulling localization-config into main?
<jdub> Kamion: i'll leave this one for matt
<pitti> Mithrandir, daniels: I think ddaa uses dvorak, too
<jdub> seb128: yeah
<daniels> pitti: yeah, azerty dvorak.  bong.
<Mithrandir> fabbione: deny from $ip in htaccess?
<fabbione> Mithrandir: they use the same technics as google
<fabbione> if you ban the domain, they switch to non resolvable addresses and if you ban the address they switch to another net
<fabbione> FUCKING ANNOYING
<seb128> jdub: insight on #1080 appreciate :)
<daniels> Kamion: https://bugzilla.ubuntu.com/show_bug.cgi?id=6296
<thom> fabbione: ew. 
<Mithrandir> fabbione: ban on user agent?
<fabbione> Mithrandir: exactly
<thom> fabbione: see query
<fabbione> but i am more evil
<Kamion> daniels: yeah, you mentioned that, seems to be the same class of bug
<thom> it's mod_rewrite, sadly
<fabbione> Redirect on user Agent
<fabbione> thom: yes i am reading
<thom> redirect? where?
<fabbione> goatse.cx
<Kamion> daniels: if we don't want to pull in localization-config (which might make sense, it does quite a few things), then we should at least pull the logic from localization-config into xserver-xorg
<fabbione> let's them cache some good old shit
<thom> fabbione: they won't. you're just wasting someone else's bandwidth, and that's kinda rude
<fabbione> not really...
<daniels> thom: to be fair, i hardly doubt goatse.cx was set up for anything other than being put in slashdot comments
<daniels> kami	sure
<thom> true
<fabbione> daniels: point
<Mithrandir> fabbione: look at http://www.neilgunton.com/spambot_trap/
<Kamion> daniels: if we go that way, I'll put together some sample code for you
<fabbione> thom: can i put that rule in the generic httpd.conf or does it need to be x vhost?
<daniels> Kamion: dude, if you do, I'll buy you a night out down here on some *real* beer
<daniels> fabbione: rewrite is per-vhost
<daniels> fabbione: don't forget RewriteEngine On
* Kamion wonders if that's a threat or a promise ;)
<daniels> Kamion: heh, I'd say a case of Coopers, but that might be tricky on the plane.  but that offer's still valid if you like. :)
<fabbione> daniels: still x vhost, right?
<daniels> fabbione: yeah
<fabbione> ok
<jdub> seb128: hrm, what do you want me to say? :)
<haggai> jdub: was it you I was talking to at the con about dbus-qt bindings?
<jdub> haggai: possibly
<seb128> jdub: is there any way to get bug-buddy speaking to bugzilla ?
<jdub> seb128: i thought we were going to use the sendmail gateway
<seb128> jdub: I don't know what this gateway is ...
<daniels> haggai: if you test them in the next two hours, I'll upload before FF ends
<daniels> haggai: http://people.ubuntu.com/~daniels/dbus/
<seb128> jdub: where is the gateway ? how does it work ?
<daniels> haggai: asked riddell and amu to test a few days ago, but no response
<haggai> daniels: ah cool
<jdub> seb128: no idea :)
<daniels> haggai: tick tick :)
<seb128> jdub: ok, thanks anyway :)
<haggai> daniels: seems there is some problem with dependencies and we're not gonna manage to fix it all so don't worry
<daniels> haggai: what's the dependency problem?
<pitti> Mithrandir: just uploaded new glibc with your patch
<Mithrandir> pitti: thanks.
<Treenaks> eek @ ubuntu-user.. someone who tries "xhost +"
<daniels> whoops
<Kamion> mvo_: it would be really nice if new apt configure options came with documentation :)
<Mithrandir> yay.  I just repaid my mortage.
<daniels> Mithrandir: word!
<mvo_> Kamion: good point :)
<Kamion> (looks like -o Acquire::gpgv::Options::=--ignore-time-conflict works)
<mvo_> at least that's good news :)
<elmo> why are you ignoring time conflict, JOII
<elmo> or JOOI even
<Kamion> elmo: 'cos sometimes the clock is broken in the installer and we haven't got to the point of running ntpdate yet
<elmo> ah
<Kamion> elmo: daniels reported that he couldn't finish the installation because his clock was set to 2003
<jdub> mine was set to 1985!!
<jdub> o/~ and that's the power of love o/~
<elmo> daniels in "two year behind the times" shocker... ;P
<Kamion> jdub: your clock is *always* set to 1985
<daniels> elmo: says the man from leeds
<haggai> daniels: dbus-qt-1-dev depends on libqt3c102-mt-dev but it should be libqt3-mt-dev 
<daniels> haggai: i can fix that in an instant.
<daniels> haggai: if you --force-depends it, is the rest ok?
<haggai> daniels: looks like it, yes
<daniels> phat
<daniels> thanks
<sivang> hey jbailey 
<jbailey> Heya sivang 
<sivang> jbailey: how you been? :)
<jbailey> sivang: I've been sleeping. =)
<sivang> jbailey: ah well, that's ever good :)
<thom> jbailey: nice initrd-tools upload dude!
* jbailey waves the sarcasm detector over thom to see if it makes noise.
<thom> no, that was serious
<jbailey> Cool. =)
<jbailey> I need to spend some time over the next few weeks making sure that I have LVM and EVMS setups here to test on, so I'm always nervous uploading that my inbox will fill up with "You broke my system" emails =)
<thom> you've not killed by evms
<daniels> works with lvm on amd64, at any rate
<thom> uh, my
<daniels> thom: is lvm or evms recommended these days?
<Kamion> I need to have a RAID/LVM install test system that isn't mission-critical; maybe I can do a small LVM on the amd64
<ajmitch_> jbailey: I'll complain loud & long to you if you break my box, don't worry :)
<thom> evms allows you to use lvm as part of it, it's pretty cool
<Treenaks> thom: so evms is recommended?
<daniels> thom: ahr.  so if I have an lvm /home, then I can get all the EVMS goodness without reformatting?
<thom> daniels: afaik
<thom> Treenaks: i guess, i just use it on /home though so not an expert
<daniels> thom: phat
<ajmitch_> sounds good, I've got LVM on everything but / at the moment
* Keybuk beats jbailey up
<Keybuk> #6293: Only English people should be allowed to build packages
<daniels> Keybuk: what, no Welsh allowed?
<Keybuk> apparently noy
<jbailey> Keybuk: *that's* what I should've titled the bug. =)
<thom> we should just declare en_GB to be the one true sort order
<Keybuk> thom: NO!
* Keybuk likes all of [A-Z]  to come before [a-z] 
<thom> pfft, madness
<jdub> Keybuk: had you seen this?
<jdub> http://itkitchen.info/2004/10/27/planet-free-software/
<eruin> wasabi: Couldn't stat source package list http://archive.ubuntu.com hoary/universe Packages (/var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_hoary_universe_binary-i386_Packages) - stat (2 No such file or directory)
<eruin> err
<eruin> that wasn't directed at you :-)
<eruin> could anyone tell me if that's a problem on my part or archive.ubuntu.com ?
<daniels> thom: posix sort order, mofo
<daniels> thom: did you see that particular frightening quirk of the iaudio?
<thom> daniels: yeah
<Keybuk> why's that frightening?
<sivang> jdub: wow nic, dind't know you are one on the long history of blog development :) and scott also :)
<Keybuk> jdub: heh, fame
<jdub> Keybuk: authored by spiv
<jdub> er
<jdub> Keybuk: authored by spiv's other half
<daniels> Keybuk: don't get me wrong, I love it, partially because it's how ~/music on my desktop sorts also
<daniels> Keybuk: but on a piece of consumer hardware?  frightening.
<Keybuk> daniels: I would've have probably freaked if it didn't do that
<Keybuk> to be honest, I didn't notice
<Keybuk> jdub: she has an allergy to 'w's
* thom ducks and covers
* Keybuk considers orphanining libtool
<ogra> jdub.... psst....hoary changes ... boa constructor.....
<ajmitch_> what did I break?
<ogra> nothing.... i hope ;)
<ajmitch_> well it still runs here with py 2.4 :)
<ogra> just wanted to point out you first timer ;)
<ajmitch_> aha
<ogra> applause from germany.....
<jdub> ogra: xss went in, btw.
<jdub> ogra: (yeah, seen ;)
<ogra> jdub: i saw it....,ade me really happy :-D
<pitti> Hi ogra 
<jdub> ogra: already had a few people comment on it
<ogra> jdub now lets see if my hal patches get accepted by pitti
<pitti> ogra: I just wanted to remember you about the feature freeze today :-)
<pitti> ogra: can you send me a debdiff?
<pitti> or put it somewhere?
<ogra> pitti...just sending the first patch (lsb_release)
<ajmitch_> jdub: what's the status of bug management for universe for now?
<ogra> pitti, btw, what did you change between ubuntu1 and 3 ? it takes nearly 1min to get the first response from lshal after upgrade.....
<ogra> (without my patches)
<jdub> Kamion: nice reply
<jdub> ajmitch_: "not" :|
<pitti> ogra: I fixed the nasty "udev goes crazy" bug
<Kamion> jdub: I had to bite my tongue in a couple of places
<pitti> ogra: however, it should actually become faster with this fix
<ogra> pitti: nope.... the first execution of lshal gives me 0 devices... after about 30sec-1min i see them appear then....
<jordi> I wonder why the "About Ubuntu" menu item in the panel doesn't haev a Ubuntu logo.
<pitti> that's odd
<ogra> bearable...but not nice....
<pitti> ajmitch_: congrats for your first upload, and welcome aboard :-)
* fabbione looks at doko and gcc-4.0 4.0ds5-0pre6ubuntu1 accept message
<doko> fabbione: just a toy for jbailey
<pitti> ogra: works fine for me, after about 5 seconds I have all devices
* thom applauds Kamion 
<ogra> hmm...probably my setup....
<ogra> or my arch....
* daniels golf-claps Kamion.
<ajmitch_> pitti: thanks 
<fabbione> Kamion: to which post?
<fabbione> ah i found it
<Keybuk> seb128: latest evo still broken wrt. secure smtp
<Keybuk> and they've seriously broken quote-message-in-reply
<jdub> sounds like GTK BOOG to me!
* seb128 slaps jdub 
<daniels> jdub: no, it's a feature
<daniels> so seb has a few hours to fix it
* daniels giggles.
<seb128> hate hate hate hate evolution
<seb128> we should ship an another MUA
<Treenaks> seb128: like mutt?
<seb128> every single release broken
<jdub> where can i download the ubuntu uploader keyring?
<dholbach> re
<seb128> Treenaks: ...
<sivang> hey dholbach 
<seb128> Treenaks: you did that troll already yesterday
<dholbach> hi sivan! :-)
<sivang> dholbach: 'sup?
<Treenaks> seb128: no, that was another one
<jdub> aha
<dholbach> sivang: just did the laundry :-)
<dholbach> sivang: how are you?
<seb128> Treenaks: seriously, that was the same, and that's not really a chan to troll
<sivang> dholbach: fine, intend to fix 2 bugs today hopefully before FF is in effect :)
<Treenaks> seb128: I know
<dholbach> sivang: cool - which ones?
<mvo_> jdub: I should eventually be in ubuntu-keyring, but it's not (yet?)
<mvo_> s/I/it/ == the uploader keyring
* mvo_ needs to make less typos
<jdub> mvo_: looks like you are
<jdub> how else are you uploading? :)
<sivang> dholbach: 1849, and the one I already know by heart - 6092 :)
<mvo_> jdub: I mean, the uploader keyring should be available in the package ubuntu-keyring :) 
<jdub> oh
* jdub downloaded it from chinstrap ;)
<mvo_> but it's not right now
<dholbach> sivang: nice :-)
<mvo_> ah :)
<jdub> ah, so i am not so stupid!
<jdub> ah ha ha!
<mvo_> jdub: this was more a reminder to myself that I should add it to the ubuntu-keyring package :)
<daniels> jdub: scorchio!
<elmo> it's on the keyserverss too
<mjg59> rubenv: Yo
<jdub> Mithrandir: ping
<rubenv> mjg59: pong
<rubenv> mjg59: ever seen a laptop screen coming out of suspend lighting up abnormally?
<mjg59> Yes, the POSTing will often result in the backlight being on but the video chip not doing anything useful
<mjg59> Does it go back to normal eventually?
<rubenv> even when I disable posting i think
<rubenv> i don't wait to see what it does in the end :-)
<rubenv> I need this laptop ;-)
* ajmitch_ tries to decide whether to try & get to LCA in april
<rubenv> the nv driver also seems to do it if you do something normal dpms
<jdub> ajmitch_: as if you wouldn't!
<jdub> ajmitch_: what about UDU? :)
<rubenv> mjg59: also, i've read somewhere on nvidia's site that they have power management support, or is this horribly outdated info?
<sivang> Unpacking replacement login ...
<sivang> Errors were encountered while processing:
<sivang>  /var/cache/apt/archives/gnome-icon-theme_2.9.91-0ubuntu2_all.deb
<sivang> E: Sub-process /usr/bin/dpkg returned an error code (1)
<sivang> known probably?
<bob2> scroll up, that's not the error message
<ajmitch_> jdub: it'll be easier to get to that, once I find out details :)
<ajmitch_> it's just whether I can afford 2 weeks in .au :)
<sivang> bob2: err, lost the scrollback...he well, I can live with that until it's fixed..
<ajmitch_> thankfully I've got a friend in canberra who I could stay with
<sivang> apptemting apt-get install 0f
<sivang> s/0f/-f/
<mjg59> rubenv: The brightness is just because an uncontrolled TFT will turn white
<mjg59> There's no way it can damage anything
<thom> infinity: yes, it's known
<thom> uh, s/infinity/sivang/
<mjg59> But if the nv driver is doing it, then it's likely that your video BIOS is just broken
<rubenv> mjg59: well crap
<rubenv> nvidia doesn't do it
<sivang> Unpacking replacement libdbus-cil ...
<sivang> dpkg: warning - unable to delete old file `/usr/lib/mono/gac/dbus-sharp/0.23.0.0__9eef2692033670f5': Directory not empty
<sivang> dpkg: warning - unable to delete old file `/usr/lib/mono/gac/dbus-sharp': Directory not empty
<sivang> dpkg: warning - unable to delete old file `/usr/lib/mono/gac': Directory not empty
<seb128> haggai: around ?
<rubenv> mjg59: how the hell would my video BIOS break?
<mjg59> rubenv: As in, it's been written wrongly
<rubenv> mjg59: could very well be, it's dell software after all ;-)
<Kamion> sivang: those are just warnings, not errors
<mjg59> rubenv: What model is it?
<rubenv> Inspiron 8600
<sivang> Kamion: oh right :)
<haggai> seb128: yup
<seb128> haggai: for information OO.o is probably broken by the new eds (soname change in some libs)
<pitti> ogra: why did you modify Makefile.in instead of Makefile.am?
<pitti> ogra: you really wrote the additional rules yourself?
<haggai> seb128: oh thanks, I'll make sure I test against the new one
<ajmitch_> night all
<Mithrandir> jdub: pong
<elmo> daniels: what's this stupid libgl warning spam about anyways?
<daniels> elmo: could you possibly be less specific?
<elmo> libGL warning: 3D driver claims to not support visual 0x23
<elmo> and yes, Icould be a lot less specific
<daniels> well, your 3D driver is claiming not to support visual 0x23
<daniels> what hardware?
<elmo> MGA G550
<elmo> it does it for all of them
* daniels shrugs.
<daniels> dunno
<daniels> worksforme
<elmo> thanks, dude
<daniels> in all seriousness, I would have to poke at the MGA DRI stuff to do that
<daniels> and unless you want to rebuild my desktop for me and get a new version of xorg out before the feature freeze and make ddcprobe run just fine on amd64, I'm not going to spend an hour or so chasing up some random warning
<elmo> no need to be a drama queen; I didn't ask you to spend anytime on it, least of all an hour
<daniels> whatevah
<Rotund> elmo: glxinfo | grep 0x23
<mvo_> quick poll: do we want "auto-install-recommends" in synaptic on by default (like aptitude)?
<Rotund> huh?
<elmo> 0x23 24 tc  0 24  0 r  y  .  8  8  8  0  0  0  0  0  0  0  0  0 0 None
<elmo> mvo_: given a lot of our recommends can't be satisified in main, I guess not
<elmo> if it does get turned on, we should either fix the recommends or pull what we can into main
<elmo> no one's done a recommends check since Brazil, AFAIK
<Rotund> mvo_: I don't think so.  I noticed X recommends glide.  I don't have a 3DFX, so I really don't want glide
* pitti beats up ogra
<mvo_> thanks. we may turn it off in aptitude then as well
<pitti> ogra: so you really want to introduce buffer overflows in hal? :-)
<zul> hey
<ogra> pitti ? 
<pitti> ogra: I write a mail
<pitti> ogra: I have some other comments, too
<Rotund> when is the feature freeze date for ubuntu?
<infinity> Today.
<sivang> ogra: pitti always has, it's really hard to pass him on first try :-)) <smiles to pitti>
<Rotund> oh.  ouch
<sivang> Rotund: yes 
<elmo> rotund: http://www.ubuntulinux.org/wiki/HoaryReleaseSchedule
<sivang> infinity: do we have a scheduled time in which no uploads would be allowed after that?
<Rotund> darn.  I was going to help w/ the auto detect stuff for X, but I gotta leave
<infinity> sivang : I'm likely the wrong person to ask. :)
<Rotund> day job.  Hopefully I'll have some time tonight
<sivang> Rotund: well, maybe for hoary+1 then
* infinity points randomly at someone else, like jdub.
<sivang> infinity: I've bugged jdub too much in the last 24 hours, I am waiting for my jdub account to elapse :)
<Rotund> okay.  I'll aim for then
<Rotund> later
<ogra> sivang, i'm fine with critics from pitti.... but i need to know what to change to make him happy ;) 
<pitti> ogra: hold on, I'm still typing
<ogra> yup...i'm patient ;)
<zul> fabbione, ping
<fabbione> zul: pong
<sivang> pitti: lol 
<zul> fabbione: i added some pages to the wiki did you get 2.6.11 uploaded yet?
<fabbione> zul: not yet. fixing ppc ftbfs and waiting for ia64 to complete the build (and grab the configs)
<zul> okie dokies
<fabbione> zul: i think i will manage to upload tomorrow morning very early
<fabbione> i need to leave quite soon to pick up my parents
<zul> k, add your items to the todo list as well when you get a chance
<fabbione> zul: yes i know.. it's in my TODO list :-)
<zul> hehe
<fabbione> this afternoon and tomorrow morning will be a bit hectic for me
<Kamion> lunchtime
<infinity> What.. The.. Fuck?
<infinity> Also, -EWIN.
<fabbione> infinity <- 0w3n3d
<fabbione> :P
* fabbione hugs his sparc
<jbailey> fabbione: Is sparc going to be a supported arch in Hoary+1?
<zenwhen> hey
<fabbione> jbailey: i actually hope to get it for hoary :-)
* sivang wants a sparc
<fabbione> jbailey: sparc.u.c
<fabbione> i will make the official announce during the next week
<elmo> fabbione: speaking of sparc; how come it hasn't done the kernel yet?
<fabbione> so that people can trash it while i am away
<zenwhen> Hey I get the following error when installing gnome-icon-theme_2.9.91-0ubuntu2_all.deb
<zenwhen> trying to overwrite `/usr/share/icons/hicolor/48x48/apps/gnome-run.png', which is also in package gnome-panel-data
<zenwhen> and it dies
<fabbione> elmo: because my mirror went of out of sync for 2 days thanks to the people having 5 concurrent sessions
<jbailey> fabbione: Cool.  Means I need to get around to getting the sparc from a friend of mine soon.  He's giving it to me when he moves to replace my ultra that died.
<fabbione> elmo: and it is picking up now
<jbailey> fabbione: Are you doing usparc only, or also supporting classic sparc?
<fabbione> jbailey: only sparc64
<jbailey> fabbione: Yay. =)
<fabbione> jbailey: since i am doing it in my spare time :)
* jbailey dances to the 'no biarch madness' song.
<fabbione> but patches for sparc32 are welcome
<fabbione> jbailey: be carefull.. i am talking about kernel
<fabbione> the userland is the same as debian
<elmo> err, yeah, sparc 64-only userland would be real madness
<fabbione> that's a complete suicide
<jbailey> Ah well.
<fabbione> madness doesn't describe it
<fabbione> ;)
<jbailey> It's no crazier, than, say, running ia64. =)
<trulux> hi
<trulux> ajmitch_: congrats
<elmo> jbailey: err, sure it is?
<Mithrandir> jbailey: well.. does that say much? :)
<fabbione> now... the only 2 showstoppers for me to upload 2.6.11 are PPC and ia64
<mjg59> jbailey: Does sparc64 actually have a useful compiler yet?
<fabbione> which is the next arch are we going to drop?
<jbailey> mjg59: Does ia64? =)
<elmo> jbailey: ia64 is designed to be 64-bit, sparc is known to be more efficent with 32-bit code by default
<elmo> mjg59: useful how?  it's enough to compile the kernel and few bi-arch libs Debian has
<trulux> tritium: It's going fine
<mjg59> elmo: It used to require an egcs snapshot
<jbailey> fabbione: Which 'we'? 
<trulux> tritium: have i sent you what I'm working on? Maybe you could give me your opinion on formatting and such
<tritium> trulux, good.  Sorry I had to bail last night.  Sure, you can do that.
<tritium> (no, you haven't sent it yet.  Go ahead and send it, if you like)
<pitti> ogra: you have mail (three buffer overflows, two heap corruptions :-( ). I also have some other nitpicks, please don't take it personally
<ogra> i wont... is it solvable ?
<sivang> seb128: trying to fix 6092, dpkg-buildpackage: Build dependencies/conflicts unsatisfied; aborting.
<sivang> seb128: darn, sorry, that was supposed to be:
<seb128> ?
<sivang> seb128: dpkg-checkbuilddeps: Unmet build dependencies: system-tools-backends (>= 1.1.91)
<sivang> seb128: tried to install, no such pkg..
<seb128> yeah, you need to backends
<jbailey> elmo: As I understood it, it wasn't so much that sparc32 was more efficient as that sparc64 didn't add any wins beyond twice the data bandwidth.  So the efficiency loss is only from hauling twice as much data around when you don't really need to.
<seb128> it's probably in NEW
<seb128> ping elmo about it
<seb128> arg
<sivang> elmo: James my freind, how are you today? :-)
<seb128> probably need a seed update
<thom> elmo: fancy giving me some NEW love? ;-)
<sivang> seb128: who's allowd to update the seeds? can you do it?
<seb128> yep
<elmo> system-tools-backends_1.1.91-0ubuntu1_source.changes
<elmo> REJECT
<elmo> Rejected: Unknown distribution `unstable'.
<seb128> graaa
<seb128> thanks elmo
<sivang> seb128: woops :)
<seb128> my dh_make put unstable by default, not the first time I screw with it :p
<seb128> elmo: BTW that's targetted for main, I've to update the desktop seed first, right ?
<ogra> pitti....its a lot of work....but doesnt leave me depressive ;) thanks, i'll try to inject your changes in the other patches too, so they will be cleaner, thanks for the help :)
<pitti> ogra: Icurrently review your second patch
<sivang> seb128: yeah, I can recall at least another time when this happened :) 
<trulux> tritium: ok, DCC'ing...
<ogra> pitti: leave it... i'll send a new one if i made the corrections to the fist one...dont waste your time :)
<sivang> seb128: then I'll wait for the update..
<tritium> trulux, okay, I'll take a look at it
<seb128> sivang: http://pkg-gnome.alioth.debian.org/system-tools-backends_1.1.91-0ubuntu1_all.deb 
<trulux> tritium: OK, thanks!
<tritium> trulux, no problem.  Anything you want me to look for?
<trulux> tritium: what do you think that should be fixed in the layout and such
<trulux> it's going to be a large doc
<trulux> is USENIX/IEEETran good for it?
<trulux> or may i use book AMS or something alike?
<fabbione> jbailey: ppc or ia64 :-) we as in ubuntu ;)
<tritium> trulux, okay, I'll take a look
<jbailey> fabbione: Ah.  I didn't know that we were looking at dropping arch's.  I'm a day or so behind on my u-devel reading.
<jbailey> fabbione: I'd really prefer that ppc wasn't dropped. =)
<fabbione> jbailey: i was just kidding
<trulux> tritium: Many thanks
<jbailey> fabbione: Oh good.  Did you guys find someone for PPC stuff in the kernel meeting yesterday?
<fabbione> nope
<sivang> seb128: it's the same right?
<jbailey> One of those "I don't have the skills but would love to learn them" type of moments.
<sivang> seb128: ah, I only need to the binary pkg to build the frontneds?
<Kamion> seb128: you don't need to update seeds for build-dependencies
<tritium> trulux, where's the big table that you were going to \usepackage{longtable} for?
<seb128> Kamion: ok, thanks
<trulux> tritium: I didn't used it finally
<seb128> sivang: that's the package you are looking for no ?
<tritium> trulux, probably good
<Kamion> germinate sucks them in automatically once they're in universe
<sivang> seb128: I think so, thanks :)
<seb128> np
<seb128> Kamion: k
<tritium> trulux, which conference is this for?  got a url?
<jbailey> elmo: What's the best way to tell you that nagios-radius-plugin can be removed now.  nagios-plugins-extra is in the archive now.  (I need to hunt down why nagios-plugins didn't make it, but that's another question)
<elmo> nagios-plugins did make; I guess it's FTBFS
<jbailey> I'll check it again, I didn't see it in the build logs atall.
<elmo> oh, it may be dep-wait then
<Kamion> http://people.ubuntu.com/~lamont/buildLogs/n/nagios-plugins/1.3.1.0-12ubuntu2/
<elmo> and I removed nagios-radius-plugin
<jbailey> Kamion: I'm waiting for ubuntu3.
<Kamion> ah
<jbailey> elmo: Thanks.  What's the best way to tell you that, though?
<Kamion> build-dep on a virtual package probably means lamont has to clear the dep-wait by hand
<ogra> pitti: is it ok to drop efd = fds[1] ; and: dup2 (efd, STDERR_FILENO); completely ?
<elmo> jbailey: here, if I'm around, email if not
<elmo> forcibly given back ubuntu3
<pitti> ogra: I would not parse stderr with your "key: value" parser, that makes no sense
<jbailey> elmo: Cool thanks.
<elmo> oh, meh, that b-d probably means it'll go back into dep-wait
<pitti> ogra: either ignore it completely (just redirect to /dev/null), or write it into the hal logs
<ogra> pitti: so i throw it away then...thanks
<pitti> ogra: I don't know whether lsb_release actually writes something to stderr
<elmo> jbailey: if it d-w's again, you might need to fix the libmysqlclient-dev b-d
<pitti> ogra: if it makes no sense, redirect it to /dev/null (don't just close it)
<ogra> ok
<jbailey> elmo: 'k, thanks
<pitti> ogra: if it's closed and lsb_release indeed tries to write to stderr, this would crash with SIGPIPE
* fabbione is off. 2.6.11 will have to wait tomorrow
<pitti> ogra: I reviewed the second patch, mailed to you
<elmo> err
<elmo> is oocalc known to be likely entirely SNAFU in hoary?
<fabbione> s/calc//g :P
* fabbione is off for real
<ogra> pitti: thanks....now i need a cigarette.....uff...as i said, i dont trust my c-foo ;)
<ogra> pitti: thanks ;)
<elmo> meh, it's not reproduceable except in my expenses
<seb128> jdub: around ?
<pitti> elmo: for me it crashes when deleting a row
<dholbach> seb128: just changed  dh_make 's template to say "hoary" instead of "unstable" - want to upload? :-)
<seb128> dholbach: what package ?
<dholbach> dh-make 
<elmo> pitti: I've got that + crashing when cut'n'pasting a block of data, crashing when trying to open a file
<trulux> tritium: no con. , it's for be presented independently
<pitti> elmo: d'oh
<zul> gah...hate windows
<pitti> elmo: the other stuff works for me
<dholbach> seb128: deb-src http://ubuntu.gplan.info hoary main
<seb128> dholbach: quite busy atm, but I'll have a look on it soon
<jbailey> dholbach: It might be worth doing a hack to dh_make to look in /etc/lsb-release for DISTRIB_CODENAME
<dholbach> jbailey: oh cool, you're right
<jbailey> dholbach: That way the change doesn't have to be constantly changed, is based on the current system, and flows through to derivative distros with the right changes.
<dholbach> jbailey, seb128: i'll rework it
<dholbach> jbailey: thanks, master yoda :-)
<jbailey> dholbach: I knew my wrinkles were showing!
* jbailey runs off crying.
<tritium> trulux, it looks good.  I've been trying to find author information on usenix.  All I've found is this: http://www.usenix.org/events/samples/ 
<dholbach> jbailey: i'll still have to train my jedi skills 
<tritium> trulux, I've used latex-beamer for the talks I've given.  It's pretty sweet.  You might consider it for the presentation slides.
<tritium> trulux, if you don't have format guidelines, I think IEEEtran looks nice.  If you use your current format, check your top margin.  It seems too large.
<lamont> Kamion: need something cleared?
<Kamion> lamont: nagios-plugins - elmo did it though
<lamont> elmo: moving stars to multiverse?
<lamont> Kamion: cool
<daniels> elm	ping
<Riddell> haggai: is there a MOTU e-mail list?
<daniels> blah
<daniels> elmo: ping
<haggai> Riddell: no
<Riddell> haggai: someone is moaning to me about a broken package, anywhere I can send him to?
<lamont> daniels: I was wondering why you were pinging a tree....
<daniels> lamont: misguided irssi feature
<lamont> heh
<trulux> tritium: yeah, how could I change it?
<haggai> Riddell: ubuntu-devel.  We're waiting for bugtracking support still
<Riddell> haggai: he's already tried there, poor soul will just have to wait or fix it himself
<tritium> trulux, \documentclass{IEEEtran} (be sure to download the IEEEtran class)
<trulux> tritium: I'm going to test it in a backup, lemme copy the files and try to hange it
<tritium> trulux, or, margin setting is probably in the .cls file you're using
<trulux> it works out of the box with IEEETran
<trulux> without tweaking the tex
<tritium> it should
<trulux> still I prefer numbered sections and not ro. numbers
<haggai> Riddell: hmm, sounds like it
<tritium> trulux, your choice :)
<lamont> fabbione: you mean I have to figure out how to use imap now? :-)
<trulux> tritium: is it easy to change them?
<trulux> mdz: ping
<tritium> trulux, cuales?
<trulux> tritium: el poner nmeros romanos o sequenciales, es que la AMS est genial, tiene montones de objetos, y las book me encantan, el doc, tendr bastantes pginas, as que no se que escoger, tu que dices?
<elmo> lamont: meh, done
<elmo> daniels: ?
<tritium> trulux, oh, yes.  You can redefine how section numbers are produced.  /msg me for details
<trulux> tritium: ok
<daniels> elmo: is it possible to get a list of which xorg binary packages are in main and which are in universe?
<lamont> elmo: thanks
* Mithrandir takes a few dropkicks to gcc-3.4's head.
<elmo> lbxproxy, libxaw6-dev, proxymngr, twm, x-window-system, xdm, xdmx, xfonts-100dpi-transcoded, xfonts-75dpi-transcoded, xfonts-base-transcoded, xfonts-cyrillic, xfree86-common, xfs, xfwp, xmh, xprt
<elmo> are in universe - everything else is in main
<daniels> elm	thanks
<Mithrandir> I _love_ how building gcc-3.4 kills stuff in /usr/include. :(
<pitti> sjoerd: btw, pmount now already uses "quiet" for VFAT (just saw your hal commit)
<elmo> Mithrandir: how can it?
<Mithrandir> elmo: it removes /usr/include/bits when it's a symlink, at least.
<Mithrandir> elmo: I'm doing sbuild shit as root -- I'll need to hack gcc-3.4 I guess.
<Mithrandir> but the build system is soooo bad.
<seb128> elmo: could you sync evince 0.1.4 from incoming ?
<lamont> seb128: libbonobo ftbfs on ia64...  implicit func defn --> scan fail --> bummer
<seb128> k
<lamont> fabbione: what all did you change in the ia64 kernel?  it doesn't find the cdrom any more...
<sivang> jbailey: wrinkles? :)
<sivang> jbailey: btw, good idea to take it from lsb-release :-)
<mjg59> Anyone with ops on #ubuntu about?
<lamont> mjg59: yeha
<lamont> yeah, even
<lamont> had to check, you see...
<sivang> mjg59: what's cracking there?
<mjg59> lamont: The first time someone speaks, it carelos sends them a message
<mjg59> He doesn't actually seem to be around, but it's rather annoying
<lamont> mjg59: and what would you like done to him...
<mjg59> Removal? :)
* lamont has ops, but no clue what commands to execute...
<lamont> mdz about yet?
<zenwhen> who handles the gnome panel applets?
<zenwhen> The window list now picks up items from both of my monitors, the new modem lights applet is useless, and the volume applet acts really weird. lol
<kent> zenwhen, you get respons from Ubuntus bugzilla realy fast, and i think that bugzilla is the best way for the devlopers aswell :)
<zenwhen> yeah
<zenwhen> I suppose
<zenwhen> I just hate searching through it and always wind up putting it in thre wrong place or duplicating one
<sivang> zenwhen: better put it that way then getting it lost in the trail of irc backlogs..:-))
<kent> haha, for me aswell.  And even though i try not to, my first reaction is always to go out on irc and complain ;)
<mjt> sorry for asking here, #ubuntu is silent on the topic... Anyone know what's up with hoary repository -- 2nd day now ?  I can't apt-get update, it complains about MD5Sum mismatch for Packages.gz files...
<mjt> (or is it just me? :)
<zenwhen> I am not having any issues with it
<jbailey> mjt: No issues here ppc or i386
<mjt> maybe it's apt-proxy on another machine does weird things...  i don't have direct access to the 'net from this machine so have to use apt-proxy
<sivang> seb128: did you keep the backends patches I did on the ubuntu tool-backends package?
<seb128> what is tool-backends ?
<sivang> seb128: ah sorry, system-tools-backedns
<zenwhen> buzilla is fun on dialup
<zenwhen> kik
<seb128> that's the first release
<seb128> this is a new package
<seb128> sivang: read the changelog ?
<sivang> seb128: sure.
<seb128> so what's the question ?
<dholbach> bbl
<zenwhen> hey seb128  https://bugzilla.ubuntulinux.org/show_bug.cgi?id=6322 is solved, btw
<seb128> hi
<seb128> k, thanks
<haggai> mjt: I'm afraid that's an apt-proxy bug, that does happen sometimes
<zenwhen> you just have to upgrade gnome panel
<seb128> zenwhen: I know that
<mjt> haggai: i think it's apt bug, really ;) -- after manually updating /var/lib/apt/lists/* stuff and running apt-get install apt apt-utils (from 0.6.30 to 0.6.32) it works now ;)
<zenwhen> seb128, do you know what changed the Window lists's ability to know which apps are on which monitor in a twinview situation? 
<zenwhen> It sorted them in Warty, and now it lumps both monitors.
<zenwhen> oh
<zenwhen> its a bug
<zenwhen> lol
<zenwhen> I suck and will shut up
<haggai> mjt: that might be to do with apt-proxy's handling of the Modified-Since http headers
<mjt> haggai: nope, the files on archive and in proxy cache are the same, I verified
<mjt> haggai: and nope, apt-get update grabs them
<mjt> either way, apt-0.6.32 fixed the issue
<mvo_> mjt: I would be suprissed if it is a apt bug that is sovled with upgrading from 0.6.30->32. the changes are nearly all about apt-cdrom :)
<mjt> well, not really, but indeed changes are quite small
<mjt> still it works now and didn't work a few mins ago
<doko> elmo: please can you sync python-mode from unstable?
<zenwhen> I was really pleased with how well upgrading from a warty array install disk worked.
<zenwhen> I mean hoary.
<zenwhen> It went better than most Windows upgrades. ;)
<Hwolf> zenwhen. Every time I doubt my choice of running hoary, I think about the pc I just installed for a neighbour, which caught a virus before she got about running windows update.
<zenwhen> lol
<zenwhen> I am thinking of install hoary on the laptop that is arriving in the next couple hours
<zenwhen> installing*
<zenwhen> Because I want hoary to work well on it and the only way to affect that is to file bug reports.
<zenwhen> :)
<Hwolf> zenwhen, she bought an old laptop. 366mhz, 64mb memory, Think I can get it to run ubuntu?
<zenwhen> Hwolf, with XFCE, it should be fine.
<zenwhen> With fluxbox, it might be quite snappy.
<zenwhen> Woith gnome, its going to be sluggish.
<mdz> lamont: here
<Hwolf> ZenWhen. I call gnome sluggish on my pc. And it's a decent rig.
<mdz> Kamion: is localization-config sane for ubuntu?
<zenwhen> Oh, I am running a 3Ghz P4 and a Gig of PC3200 ram.
<daniels> mdz: anything you can think of before I upload xorg 6.8.1-1ubuntu16?
<zenwhen> Gnome is snappy for me.
<Kamion> mdz: I was having a look, but got distracted; there's a fair bit of stuff in there
<daniels> mdz: works fine for me on amd64 with DDC (although I have to select the resolution), i386 with laptop, and live CD through qemu
<mdz> haggai: pong
<mdz> daniels: changelog?
<Kamion> mdz: I think we should look at it in the long term, but for Hoary I think the least-breakage approach would probably be to clone its keyboard mapping logic into xserver-xorg's config script
<Kamion> and acknowledge Konstantinos in the changelog
<Hwolf> zenwhen. I've got an amd 1800+ and 512mb ram, which should be more than plenty for any typewriter inet/mail rig. Yet gnome is sluggish.
<mdz> Kamion: it strikes me as the sort of thing that we might be able to implement better by modifying the affected packages directly
<Kamion> mdz: yeah, I agree
<mdz> Kamion: I thought we already did that for Warty?
<Kamion> mdz: did which?
<mdz> (the xserver logic)
<Kamion> mdz: no, I looked at what we did for Warty this morning, and it's the source of a lot of bugs
<haggai> mdz: you asked me to ping you yesterday re bounties but I missed you when I got back
<zenwhen> Hwolf, sluggish compared to what?
<Kamion> mdz: we automatically pick a keyboard mapping based on the selected *language*
<daniels> mdz: /msg
<daniels> mdz: no, we guess based on $LANG
<mdz> Kamion: the stuff we have now is going to be obsoleted by smurfix's layout selector
<Hwolf> zenwhen, compared to windows xp if kept virus-free. sluggish compared to my expectations.
<Kamion> mdz: how so? smurfix's layout selector will presumably set debian-installer/keymap and the mapping will need to be just the same
<Kamion> I was under the impression that the layout selector was a replacement for kbd-chooser
<mdz> Kamion: it will find both the appropriate console keymap and the appropriate XKB keymap
<Kamion> mdz: hrm. ok.
<daniels> mdz: is that going to be good to go for hoary?
<Kamion> it's a hoary goal, and seems to be already well underway
<Kamion> I haven't had time to try it out yet though :-(
<bluefoxicy> OH NO YOU DIDN'T
<mdz> daniels: he's quite far along with the console stuff, and XKB is next
<bluefoxicy> bluefox@icebox:~$ cat /boot/config-2.6.10-3-amd64-generic | grep CAPA
<bluefoxicy> CONFIG_SECURITY_CAPABILITIES=m
<daniels> mdz: cool
<Kamion> elmo: not to be are-we-there-yet, but could I have file-kickseed in main so I can upload d-i with it?
<mdz> Kamion: I've tried it, it's quite nice
<bluefoxicy> M?!
<tseng> bluefoxicy: um
<tseng> the bug is patched
<daniels> bluefoxicy: please calm down, dude.
<tseng> and it went back to being M
<tseng> because its freaking useless
<mdz> amu: what is the status of the kubuntu seeds?
<bluefoxicy> tseng:  ah
<elmo> Kamion: it'll go in next cron.daily
<Kamion> elmo: ta
<bluefoxicy> tseng:  I thought the kernel devs were moving away from root and more towards caps though
<lamont> mdz: figured I'd lob mjg59's #ubuntu issue at you
<tseng> bluefoxicy: uh
<mjg59> Oh, he's quit now
<lamont> mjg59: ah, good
<elmo> [Updating]  python-mode (4.62-1 [ubuntu]  < 4.70-1 [debian] )
<elmo> doko: UVF, please mail mdz, jdub & cc me
<bluefoxicy> tseng:  check out kernel/module.c
<elmo> doko: you know a bunch of main packages are now built from gcc-4.0 right?
<bluefoxicy> tseng:  the pattern "uid" isn't found, but "CAP_SYS_MODULE" is required for inserting and removing modules
* bluefoxicy goes to read the capabilities code, but assumes the dummy operation is to equate any capability to root
<tseng> you dont need that stupid lsm caps thing to use caps
<tseng> im not even sure what it does, tbh
<bluefoxicy> tseng:  Oh, you don't?  I thought they moved capabilities out of the core and into a module "because it's bad to have policy in the kernel" or something
* bluefoxicy shrugs
<bluefoxicy> tseng:  thanks for the info
<tseng> grsec and rsbac use caps w/o ever touching that lsm thing
<tseng> suid apps drop their caps on start (postfix), etc
<tseng> if you figure out what that module even does, lemme know
<doko> elmo: yes, fastjar, libgcc1, libgcj-common. as discussed with jbailey and mdz
<elmo> doko: and libstdc++6
<amu> mdz: started 30min. ago   
<elmo> doko: gcc-4 doesn't ABI bump from 3.4? 
<doko> elmo: for i386, powerpc and ia64. correct.
<pitti> Morning mdz
<mdz> amu: what happened?
<mdz> pitti: morning
<doko> elmo: no
<elmo> doko: neat
<sivang> morning mdz 
<mdz> doko: we did not discuss libstdc++6
<mdz> but apparently it's only used by a few packages, the ones currently using gcc-3.4 I guess?
<amu> mdz: just started working, 1h or so      
<doko> mdz: correct, except for amd64, where we only had libstdc++6-0
<haggai> am I allowed to use gcj-3.4 for OOo2?  That might let me build OOo with gcj...
<trulux> mdz: there?
<mdz> trulux: yes, but backlogged
<doko> haggai: gcj-3.4 is still in universe. gcj-4.0 will enter main.
<mdz> amu: are you feeling ok?  usually we do not start work at the same time :-)
<mdz> trulux: I have that URL
<haggai> doko: hmm, that should be ok too
<trulux> mdz: ok, fine, lemme know if you need something
<amu> mdz: ;) hehe i've flexile working hours, our hole family is ill atm :)    
<bluefoxicy> pitti: have you looked into adding netdev-random to the hardened kernels
<mdz> trulux: looking at the init patch; is it certain to be a no-op in the default case (selinux disabled)?
<pitti> bluefoxicy: no, I didn't. Is there an URL for that?
<mdz> it's not clear
<bluefoxicy> pitti:  I dunno.  tseng might know
<bluefoxicy> pitti:  I just yanked 3000 and 3001 from the hardened gentoo kernels :)
<bluefoxicy> and put them in the Ubuntu ones
<trulux> mdz: It will work w/o selinux too
<bluefoxicy> no idea where they got 'em
<tseng> the url is really old, used to be maintained by RML
<tseng> he signed it over to albeiro, who seems to just mail them to me.
<bluefoxicy> buh
<tseng> bluefoxicy: if we want to do something with netdev-random
<mdz> trulux: it looks like it will print an error about mounting selinuxfs
<tseng> it really needs to be cleaned up and proposed upstream
<mdz> it needs to completely disable itself if selinux is not in use
<bluefoxicy> tseng:  I'm thinking more entropy == faster GPG key generation
<tseng> bluefoxicy: erm
<mdz> trulux: on the dpkg patch I defer entirely to Keybuk
<tseng> bluefoxicy: gpg key isnt very slow here
<tseng> bluefoxicy: but our main case for netdev-rand was SSP, which now uses urandom
<tseng> and alot less bits
<mdz> trulux: do you have links to the cron and pam patches?
<bluefoxicy> tseng:  over here when I do it (I do 4096 bit keys sometimes) it spits out like 5 lines of junk to the terminal, then one char per second, unless I move the mouse
<mdz> trulux: are you sure that cron isn't already done?
<mdz> trulux: it build-depends: libselinux1-dev
<trulux> mdz: libselinux1-dev needs to be in base, as well libselinux1 too
<tseng> bluefoxicy: im not sure its right for the ubuntu kernel
<trulux> mdz: cron is not done I think
<tseng> bluefoxicy: alberio is barely around lately.
<bluefoxicy> tseng:  what about mainline
<tseng> if someone wanted to maintain it, and keep up with all the new drivers
<tseng> then yes, it could be somewhat useful
<bluefoxicy> heh
<bluefoxicy> I'm just curious because people always say not to use /dev/random unnecessarily, like it's some precious finite resource that you need to use when you need great entropy
<tseng> theyd be right
* bluefoxicy tried to find a plug-in to make xmms use /dev/random :D
<bluefoxicy> tseng:  so anything that pumps it up with more high-quality entropy would be good then?  Or am I leading a bad conclusion?
<Keybuk> mdz: I've yet to see a dpkg patch that I would even consider
<dholbach> re
<tseng> bluefoxicy: netdev-random touches every net driver
<bluefoxicy> tseng:  I noticed, I had to manually patch 3
<tseng> pretty darn intrusive
<bluefoxicy> tseng:  is there any other way to tell if it's coming from net
<trulux> mdz: I've hacked out the behavior of libselinux and added a bootstrapping-capable package manager context setting helper that may help to avoid the dirty postinst hacks for dpkg
<tseng> bluefoxicy: just by watching the pool and not doing anything else adding entropy afaik
<trulux> mdz: I've sent it to Stephen (NSA) but dunno if it will get mainline
<trulux> bluefoxicy: getting entropy from network devices is pretty a weak thing
<tseng> its very effective, actually
<trulux> bluefoxicy: don't bother with it, believe in me
<tseng> just not that practical
<tseng> in terms of maintainability
<bluefoxicy> trulux:  well, they're affected by the load on routers along the path, noise, cable run length, load on other servers, everything half the internet is doing
<bluefoxicy> I'd consider that fairly difficult to reliably poison
<trulux> bluefoxicy: the Linux TCP/IP stack is somewhat a predictable design and this has been demonstrated many times, but, I can admit that it may require many more skills and a deep study on how it works
<bluefoxicy> tseng:  reading from the soundcard's analog in is also neat, since you can never perfectly buff out the noise on the mic port.  Audio-entropyd I think does that
<trulux> it's like gathering entropy from the sound card
<bluefoxicy> trulux:  interrupt timing, hardware not software
<trulux> would you trust in something that can get attached to a poisoned jack which sends a non-changing, repeated stream on a certan frequency which makes such amount of "true random" bits reallly true randomized?
<bluefoxicy> heh
<trulux> bluefoxicy: it's affected by software AFAIK :)
<bluefoxicy> trulux: interrupts are hardware.  They go through two interrupt chips that poke a port on your CPU
<trulux> have in mind a thing, and don't forget it: if you guess just one bit of the entrop, then the rest is completely in compromise
<trulux> the atacker should just greab a frozen seed of the compromised entropy and try to use it against the application at issue
<trulux> the standard random.c gives a good quality PRNG
<trulux> if you don't like it
<Kamion> that kind of depends on the quality of the input hash used for the entropy pool, of course
<trulux> let me know and I will port Fortuna CSRNG to latest sources
<Kamion> one ought not to be able to use knowledge of the input to work out what's in the entropy pool unless one knows *all* the input
<Kamion> (I don't know if Linux' entropy hash is actually good enough for that, though)
<lamont> so if package A gets absorbed into package B, should package B provide: A?
<trulux> yep
<trulux> Kamion: Linux uses SHA1
<trulux> Fortuna is based on Schneier's CSRNG design, relies in SHA256
<trulux> (real) implementation from CyptoAPI
<Kamion> it's not the SHA part that's important AFAIK, it's the CRC done when mixing input into the entropy pool
<Kamion> the comment in the kernel source says "This is not cryptographically strong, but it is adequate assuming the randomness is not chosen maliciously, and it is fast enough that the overhead of doing it on every interrupt is very reasonable."
<Kamion> so sounds like netdev-random is not such a good idea with that
<dholbach> wb ogra
<pitti> Hi ogra! I made some further comments in the meantime
<pitti> ogra: but it looks much better now :-)
<ogra> great.... just getting the mail......
* ogra wipes off the dust of the motorway.....
<trulux> Kamion: check jlcooke's fortuna
<trulux> jlcooke.ca/random
* wasabi upgrades Hoary and gnome-volume-manager crashes
<wasabi> (probably cuz hal restarts)
<ogra> wasabi: rather because it doesnt ;)
<wasabi> Ahh. Well, something. ;)
<pitti> ogra: why it shouldn't restart?
<wasabi> THis has got me thinking about some way to mark packages which require you to be either "logged out" on installation, or similar.
<wasabi> So that theydownload, but don't install until you log out.
<pitti> wasabi: actually gvm should reconnect to a new hal
<wasabi> Yeah, in this case yes. ;)
<pitti> wasabi: in warty this "just works"
<pitti> wasabi: but it obviously got broken in Hoary
<ogra> pitti: if hal doesnt restart gvm will be left without backend....dont take me to serious ;)
<wasabi> Well, I'd hate to have a user upgrade... like, gaim or something, because of a security bug, but never inform them that they need to close/reopen gaim for it to take effect.
<wasabi> Since we never have to actually reboot Linux, nobody will. ;)
<pitti> ogra: right, but usually it does restart and thus gvm is probably failing to reconnect
<pitti> wasabi: hmm, usually I add a note to the USN if something needs to be restarted manually
<pitti> wasabi: I probably forgot it in gaim, sorry
<ogra> pitti: btw, HAL_INFO and HAL_ERROR are not available in my testbed code ;) thus i commented these out....
<wasabi> Naw, I'm just using it as an example.
<pitti> ogra: why not?
<wasabi> Does USN's pop up when you upgrade?
<pitti> ogra: ./hald --verbose=yes --daemon=no
<pitti> wasabi: no
<wasabi> My mom doens't read them then
<pitti> wasabi: they get filed to ubuntu-security-announce@list.u.c
<pitti> :-)
<wasabi> Actually.
<pitti> wasabi: right, somehow this should be integrated
<wasabi> She wouldn't read them even if they popped up.
<wasabi> They woul dneed a "restart gaim now" button.
<pitti> ;-)
<wasabi> Like Windows has. =)
<wasabi> "Restart Windows Now"
<wasabi> hahah
<pitti> wasabi: no, they would need a button "just click this unless you know what you are doing" :-)
<wasabi> yeah
<ogra> pitti: because i dont use hal for the basic development..... richard huges has a nice testbed that prints out the set_string and device valueshal would recieve andi save a lot of time only compiling 150 lines instead of the whole daemon
* mvo_ not that we have upgrade hooks now
<Kamion> trulux: ah, interesting
<pitti> ogra: why you want to compile the whole daemon?
<pitti> ogra: caling make will just recompile the changed stuff
<ogra> pitti: i will remove the comments in the real patch
<pitti> ogra: ok
<pitti> ogra: anyway, calling make in the build tree and executing hal there works fine
<ogra> jup.... but i dont see hats going on .... as i do if the set_string or callout device just print to stdout
<ogra>  hats/whats
<trulux> pitti: what's the current status of hardened kernels?
<pitti> trulux: the current version works reasonably well; however, it does not ship any firmware images and vesa framebuffer breaks
<ogra> pitti: just makes initial development easier.... later i only have to add the headers and HAL_ERR HAL_INFO
<pitti> ogra: sure, that's fine :-)
<ogra> pitti: stdin is not fds[0]  ??
<pitti> ogra: no, when doing "int fds[2] " you must not access fds[2] 
<ogra> pitti: (Ahem. Womit fangen wir an zu zhlen? :-))
<pitti> ogra: yes, SCNR :-) I thought it would be obvious
<ogra> h, ok... now i see it
* bluefoxicy sigh
<bluefoxicy> is anyone else's hoary broke?
<bluefoxicy> I can't install ubuntu-desktop because lsb won't install
<bluefoxicy> locales depends on glibc-2.3.2.ds1-20ubuntu6
<bluefoxicy> glibc-2.3.2.ds1-20ubuntu6 does not appear to be available
<bluefoxicy> lsb depends on locales
<jbailey> ls
<jbailey> bah
<bluefoxicy> tuxnes metroid.nes
<trulux> tritium: ping
<bluefoxicy> oh, you're not justin o.o
<trulux> bluefoxicy: damn! dcc me the rom :)
* bluefoxicy saw a guy named Justin Bailey
<Kamion> bluefoxicy: wait a bit, it'll appear on your architecture in time
<bluefoxicy> Kamion:  *nod*
<trulux> is Hoary ready for x86? stable for desktop?
<bluefoxicy> trulux:  abril
<trulux> I want to do the warty->hoary on my development and daily use box
<bluefoxicy> trulux:  it's suitable for the desktop if you're a hacker
<trulux> bluefoxicy: lo soy?
<bluefoxicy> trulux:  I have no idea wtf you just said :)
<Kamion> bluefoxicy: it's just waiting for the i386 buildd to get round to building new locales
<trulux> bluefoxicy: Am I?
<trulux> :)
<bluefoxicy> :P
<bluefoxicy> Kamion:  /me on amd64
<Kamion> bluefoxicy: yes, and? the i386 buildd builds arch: all packages
<trulux> bluefoxicy: be sure to know if you really want to answr, it's trulux's ego feeding
<Kamion> such as locales
<trulux> noy a good idea
<trulux> :)
<Kamion> oh, i386 failed for some reason
<bluefoxicy> Kamion:  you cross-build all archs on i386?
<tseng> bluefoxicy: no, all-arch packages
<bluefoxicy> ah
<tseng> not arch specific
<bluefoxicy> was about to say, amd64 or PPC G5 is MUCH faster than x86 :)
<Kamion> you don't know what architecture: all means?
<bluefoxicy> Kamion:  no, I read all arch, not arch all
<zenwhen> bluefoxicy, I dont know about MUCH faster.
<zenwhen> Maybe a bit.
<zenwhen> x86 is by no means a slow poke dead arch
<Kamion> who cares, it's not like the buildds are running at full capacity
<Kamion> (for now anyway ...)
<ogra> pitti: any idea why i still dont get my prompt back after everything is closed ?
<pitti> ogra: ECONTEXT
<Kamion> Mithrandir: could you check out the glibc i386 build failure?
<ogra> pitti: ....i.e. the command hangs after xecution
<pitti> ogra: which command?
<bluefoxicy> zenwhen:  G5?  :)
<ogra> my compiled binary of lsb_release
<bluefoxicy> zenwhen:  daed has a dual-opteron his boss bought him
<pitti> ogra: hm, what do you mean? executing lsb_release does return to me...
<bluefoxicy> he uses it for researching 3D graphics or something (i.e. he's writing his own 3D engine and it takes too long to compile on x86)
<ogra> pitti: it should drop me at the prompt after all the strings are printed
<pitti> ogra: right, works for me
<bluefoxicy> anyway
<ogra> pitti: as i said, i compile a single binary from the .c file which i run on the commandline.... normally the code returns after execution... but lsb_release_new hangs
<pitti> ogra: strace it, where it hangs?
<ogra> heh... in read
<ogra> indeed
<ogra> uuuh what is ERESTARTSYS
<ogra> sounds weird
<bluefoxicy> is evolution supposed to cause a floating point exception?  :o
<ogra> bluefoxicy: only on amd64
<ogra> bluefoxicy: its the new floating point exception generator ;)
* bluefoxicy wants to see a sunbird build
<sivang> ogra: lol
<bluefoxicy> ogra:  will that increase the size of my entropy pool
<ogra> bluefoxicy: depends how deep you dig ;)
<bluefoxicy> heh
<bluefoxicy> damnit debian doesn't have a .deb for sunbird either
<bluefoxicy> "Once you are done building, run "make" in xpfe/communicator ( this is a bug )"  lol
<tritium> trulux, pong
<trulux> tritium: hey! how was your time? I was in the academy learning German
<dholbach> trulux: Guten Abend, wie war Dein Deutschkurs?
<tritium> trulux, fine, thanks.  I even got stopped by some Mormons since they saw the ashes on my forehead.
<trulux> tritium: a lot of progress, printed IEEETran How To and did some tweaks on the layout
<tritium> trulux, excellent
<trulux> dholbach: Hallo, Mein Deutschkurs war gut
<trulux> tritium: still I don't get the point on how to change the sections (and subsections) formatting (make them bold is a blocking issue, i need it)
<trulux> btw
<trulux> libsafe and Stack Shield are right broken
<trulux> bluefoxicy: SSP is the final way to go for sure
<tritium> I'll /msg you, trulux
<dholbach> trulux: Woher kommst Du?
<bluefoxicy> trulux:  I like libsafe in conjunction with SSP, though the overhead may not be appropriate.  I haven't had a chance to evaluate the overhead personally, but it's apparently "negligible".  Etoh managed to make 8% out of it on a test SSP did 4% on though, so it's likely something like applying SSP ~3 times :)
<trulux> dholbach: Ich komme aus Spanien
<Mithrandir> Kamion: will do
<Kamion> thanks
<Kamion> bluefoxicy: re ubuntu-devel, um, "Lightning" is not a misspelling
<bluefoxicy> Kamion:  wow.  you're right
<bluefoxicy> google said it was >:|
<Kamion> dict > google
<bluefoxicy> Kamion:  uhh, well uhh
<bluefoxicy> Happy new year then?  :)
<Kamion> :)
<tritium> op to #ubuntu please?
<sivang> tritium: what's going on there? still the one that PMs ?
<tritium> sivang, it's okay now.
<tritium> someone was changing nicks rapidly and flooding
<sivang> tritium: ah
<sivang> :-)
<sivang> sorry,
<sivang> that is  = :-(
<tritium> no worries.  it's not happening any more. :)
<sivang> good :)
<tritium> thanks, sivang 
<sivang> pitti : btw, take a look at #1849 tell me what you think? 
<sivang> pitti: (probably better add commmenst then talking here though :)
<pitti> sivang: mom, phone
<sivang> pitti: cool :)
<carlos> pitti: dude, postgres' gettext setup sucks too much or you have a bug in your script to extract .po and .pot files...
<carlos> pitti: I only got one .pot file (from debconf templates) and a bunch of .po files inside different directories
<pitti> carlos: wait, phone
<carlos> ok
<sivang> carlos: hmm, hoary mega import? ;-)
<carlos> sivang: working on it, yes
<carlos> :-)
<sivang> carlos: yay!
* pitti is back
<pitti> carlos: the reason is that there are no pot files in the upstream source
<pitti> carlos: there are only po files
<pitti> carlos: I'm afraid you have to get along with that
<carlos> pitti: and how do you get a .pot file when translating it into a new language?
<pitti> sivang: I followup to the bug now
<pitti> carlos: hmm, ask upstream?
<pitti> carlos: I can look in the cvs, though
<carlos> pitti: don't worry, will ignore postgres until I have time to look into it
<carlos> pitti: I asked you because you work on its .deb package, in case you know how it works
<sivang> pitti: thanks
<carlos> don't lose your time with it, it's not a critical application to get translated
<carlos> so it can wait
<pitti> carlos: hmm, no pot in CVS either
<carlos> that's normal, GNOME packages don't have it neither
<carlos> pitti: but they create it on build time
<pitti> sivang: cool, shadow and /etc/sudoers changes are already done? Great, thanks Kamion :-)
<sivang> pitti: yes :) kamion rocks, and rcaskey did the original patch :)
<pitti> sivang: followed up
<sivang> pitti: thank you && http://muse.19inch.net/~sivan/g-s-t/sivan_uid_fix.diff <== can I "upload" ;-) ?
<carlos> sivang: all people are hosted at muse?
<carlos> :-D
<pitti> sivang: please attach such things to the bug as patch in the future
<sivang> carlos: hehe :)
<pitti> sivang: something is wrong with this  patch, did you happen to swap the old and new dsc?
<sivang> pitti: lemme see..
<pitti> sivang: anyway, I don't know the Gnome API, but if that works, it looks good
<sivang> pitti: ok, thanks
<pitti> sivang: it just might look a little confusing
<sivang> pitti: btw, I don't think I swapped the dsc's
<pitti> sivang: since it has knobs for adjusting the value, which are just greyed out
<pitti> sivang: are you sure that the value can't be changed in another way?
<pitti> sivang: it would be nice to disable the uid changing code in addition, just to be sure
<pitti> sivang: add comments signs around the code
<Mithrandir> pitti: what other changes did you make to glibc than the multiarch patch?
<pitti> Mithrandir: none
<sivang> pitti: pretty much, I can unshow the widget all together if that's reasonable, I took that approach to differ as less as we can from upstream, but I can attempt remove the code form the frontend and the backend as well, but I don't think the uid can be changed that way unless someone fire up the backend by hand using it's new directive system.
<pitti> Mithrandir: just added your dpatch, added it to 00list, added changelog
<pitti> Mithrandir: however, I did not try to build it on i386
<pitti> Mithrandir: I used a powerpc chroot since I still have this with glibc from my previous upload
<pitti> sivang: don't remove the code, just comment it out
<pitti> sivang: well, and having a greyed out box which displays the uid is okay for me
<pitti> Mithrandir: can you reproduce the FTBFS on i386?
<Mithrandir> pitti: haven't tried yet.
<Mithrandir> I'm grabbing the build log now 
* Mithrandir whines about just getting 12k-ish from people.u.c
<amu> Kamion: will the germinate-output updated after i upgraded the seed? 
<Kamion> amu: it's updated daily at midnight; if you want it pushed, let me know
<amu> Kamion: so fire in the hole ;)
<ogra> pitti: any idea about my hanging program ?
<rubenv> anyone knows if kiko ever comes on IRC?
<pitti> ogra: no, sorry
<Kamion> amu: done
<ogra> pitti: but you see it too ?
<rubenv> (read: somebody point me towards kiko, i need him now :-))
<pitti> ogra: no, lsb_release returns fine for me
<Kamion> amu: looks like you still have a lot of GNOME stuff to get rid of :)
<amu> Kamion: i'm impressed how it works! nice sys    
<ogra> pitti: the binary i sent you ? (i'm not talking about lsb_release)
<Kamion> amu: if you're wondering where something comes from, see the rdepends/ directory
<Kamion> e.g. http://people.ubuntu.com/~cjwatson/germinate-output/kubuntu-hoary/rdepends/gnome-desktop/gnome-about
<Kamion> amu: thanks :)
<Kamion> amu: ah, perhaps you should just drop ubuntu-desktop from your desktop seed for now so that you can see what's going on?
<Kamion> amu: you can add kubuntu-desktop back in later
<pitti> ogra: ah, I didn't see your mail
<Kamion> rubenv: he quit #canonical nearly an hour ago
<amu> Kamion: yep, this was the first try ... probably the -desktop is needed first
<Kamion> yeah, you'll need to get rid of it before you can make the output make any sense at all
<rubenv> Kamion: crap
<rubenv> thanks anyway :-)
<Mithrandir> lamont: about?
<lamont> Mithrandir: yeah
<Kamion> rubenv: he's in a sprint at the moment, I'm guessing he's gone for dinner since a bunch of people left at the same time
<Mithrandir> lamont: I'm looking at the glibc build failure.. any great ideas?
<rubenv> the cape town sprint?
<Mithrandir> make[3] : *** No rule to make target `/build/buildd/glibc-2.3.2.ds1/build-tree/i386-libc/stdio-common/stamp.o', needed by `/build/buildd/glibc-2.3.2.ds1/build-tree/i386-li
<Mithrandir> bc/libc.a'.
<Mithrandir> that looks kinda bad.
<lamont> doko was thinking it could be because it's doing parallel make
<ogra> pitti: the code never seems to return from the fgets loop....but i dont see any logical error
<rubenv> i'll head on to #canonical for stalking behaviour :-)
<lamont> (i.e., borken dependenencies)
<rubenv> bah, no stalking then :-)
<pitti> ogra: I think I have a vague idea what's going wrong
<amu> Kamion: the file all show me at the end the total diskuseage?
<sivang> rubenv: you can also find him around #pygtk if you need him
<pitti> ogra: I think there is some synchronisation missing between the two processes
<rubenv> if you want, could you ping him for me?
<Kamion> rubenv: private channel ...
<rubenv> Kamion: yeah, i noticed
<Mithrandir> lamont: yeah, possibly.. I haven't seen it on i386 before and I've built that glibc a fair number of times.
<Kamion> amu: yeah
<sivang> rubenv: this is where I always talk to him :)
<Kamion> amu: "deb size" and "installed size" respectively
<pitti> ogra: ahem, what shall I do with this binary?
* pitti does not like to execute binaries sent by email
<pitti> ogra: in addition, I don't have amd64
<ogra> pitti: you should just see the error......
<Kamion> amu: the first in bytes and the second in kilobytes, for some strange reason
<Mithrandir> /bin/sh: /build/buildd/glibc-2.3.2.ds1/build-tree/i386-libc/stdio-common/errlist-compat.cT: No such file or directory
<ogra> pitti: argh, dumb me
<Kamion> rubenv: cape town> right
<amu> Kamion: thanks, and total size -50MB for d-i ? 
<Mithrandir> lamont: I agree to the parallell build thing; want to try a manual build with NJOBS set to 1?
<pitti> sivang: again, your patch is wrong; it _removes_ the changelog entry and the patch; you have to do it the other way round
<ogra> pitti: what kind of sync do you mean ? the child is called, drops its output to the parent and if nothing is in handle anymore the fgets while loop must end ... i dont see a sync problem there
<sivang> pitti: ok, I'll switch it
<Kamion> amu: that's at the end of the 'installer' output; 16MB for i386, but it's more like 34MB for powerpc so allow a bit more
<sivang> pitti: yeah, noticed it now :-/
<lamont> Mithrandir: you're suggesting that I do that, or saying you will?
<pitti> ogra: I had a similar problem when I did this for my "debcrash" project
<pitti> ogra: I solved this with a timeout
<ogra> hmm...weird
<pitti> ogra: however, did it work with your old version with open/read?
<Kamion> I should probably put germinate output up for all architectures
<amu> Kamion: mdz: do we add theopencd packages to the CD's ? 
<ogra> pitti: sure
<Mithrandir> lamont: suggesting you do it; I don't think I've got an account on any i386 buildd boxes.
<Kamion> amu: we intend to for Ubuntu; I don't know what's happening for Kubuntu yet
<Kamion> amu: we don't yet, though
<ogra> pitti: but this code was quite ugly compared to the one i'm looking at
<amu> Kamion: it rocks, i think it's a must to have it
<pitti> ogra: yeah, that's why I wanted to use a line-reading function
<pitti> ogra: I strongly suppose that your client does not recognize the EOF of the stream
<pitti> ogra: does the child process terminate?
<ogra> pitti: hmm, strace says yes: --- SIGCHLD (Child exited) @ 0 (0) 
<pitti> ogra: oh, that's interesting
<Kamion> amu: seems to be a 107MB tarball at the moment (http://maitri.ubuntu.com/theopencd/ubuntu/winfoss/latest/), but Henrik said he could reduce that
<ogra> pitti: and i saw a zombie this afternoon, remember ?
<pitti> ogra: that was the parent process which did not wait for its child
<pitti> ogra: you must call wait() somewhere in the parent
<ogra> pitti: yeah, strace ends with: read(3,
<ogra> and hangs there forever
<ogra> pitti: ok 
<pitti> ogra: however, this is a bit tricky. You can't call it before fgets(), you must call wait() after the loop
<sivang> pitti: ok, I fixed it http://muse.19inch.net/~sivan/g-s-t/sivan_uid_fix.diff
<pitti> ogra: please try to use select() before attempting to fgets()
<ogra> pitti: what about waitpid ? and getting the childs pid ?
<pitti> ogra: not necessary, you only have one child
<elmo> Kamion/mdz: that URL isn't permanent btw; you guys know that right?
<elmo> kamion/mdz: also which machines in the DC will you need to download it from.. just little?
<Kamion> elmo: he didn't say that, although I kind of assumed that it might change
<Kamion> elmo: just little
<Kamion> (as far as I know)
<pitti> ogra: the "I evade the problem" solution is just to use a temporary file
<pitti> ogra: or just read /etc/lsb-release
<ogra> bah
<pitti> ogra: the other solution is to use select with a reasonably long timeout before the first fgets()
<pitti> ogra: and then select with a short timeout
<elmo> Kamion: okay, done little, you'll need to let me know if you need it for any others
<pitti> ogra: and stop reading from the pipe (and do wait()) if select times out
<ogra> pitti: i like to solve problems, not to work around them ... if possible ;)
<pitti> ogra: that worked for me, dunno if there is a better method
<pitti> ogra: google may help, LDP has a nice book where IPC is explained
<ogra> pitti: i'll try it...
<ogra> pitti: i'm fine with man and info ....
<pitti> ogra: http://www.tldp.org/LDP/tlk/ipc/ipc.html
<pitti> ogra: bah, that's the wrong one, sorry
<Kamion> elmo: OK, it's not something I'm likely to manage to get done until about next week anyway I suspect
<ogra> pitti: but nice to have a list ofthe signals handy, thanks ;)
<pitti> ogra: http://www.tldp.org/LDP/lpg/node7.html#SECTION00700000000000000000
<pitti> ogra: wrt signals: signal(7)
<mdz> elmo: what URL?
<pitti> ogra: rather than fiddling with select(), can you please try to check feof before?
<mdz> amu: we do not yet, but we will
<ogra> pitti: yup
<pitti> ogra: while (!feof(fd)) { fgets(...); ... }
<pitti> ogra: btw, if anything helps, just use popen
<ogra> lol
<pitti> ogra: usually it should be avoided, but since you don't supply any variable parameters to it, it would work
<ogra> pitti: so i needed 2 weeks of work to get back there ? no, never
<pitti> ogra: but please try the feof() first :-)
<elmo> mdz: the one for the opencd tar ball
<ogra> pitti: i will do everything, but you wont see me using popen 
<pitti> ogra: nice :.-)
<pitti> whoops, EBROKENSMILEY
<ogra> heh
<mdz> elmo: the one that henrik sent?
<mdz> elmo: just little, yes
<pitti> sivang: can I wait with uploading g-s-t until you fixed the sudo issue, too?
<Treenaks> pitti: Invasion of the three-eyed smileys!
<pitti> sivang: then we can do it in one shot
<elmo> mdz: yeah, the reference to maitri has to go
<pitti> mdz: thanks for fixing the hpoj script
<pitti> mdz: nice to see it working :-)
<mdz> pitti: with that patch, and a non-interactive postinst, it can go into supported
<mdz> pitti: but I don't see much to be gained by putting it in desktop, since it doesn't work until you run the configuration tool :-/
<pitti> mdz: right
<mdz> pitti: the autodetection that it does is quite smart, it might be possible to use it non-interactively
<sivang> pitti: sure
<sivang> pitti_dinner: regarding commenting the code of the change, I am still checking but it seems it would also break the assigning of uid when creating a new user...so if we can do without it would probably be better.
<ogra> pitti_dinner: if i change: if (0==fork ()) to if (fork ()) it works....
<Kamion> hooray, a little bit more sanity inflicted upon cdimage
<Kamion> now it actually uses germinate to generate the installer task rather than grep-dctrl to pick it out of Packages files
<carlos> pitti_dinner: I'm going to rename the pmount's template at Rosetta from hoary-template to hoary-pmount
<pitti_dinner> ogra: that's wrong
<tritium> trulux, I finally got it!
<pitti_dinner> ogra: that reverses the sense of it and the previous version was right
<ogra> pitti_dinner: so i will resort to switch(),feof didnt work either....
<mdz> pitti_dinner: so many firefox vulnerabilities :-(
<tritium> trulux, /msg me for the fix
<jdub> pants off!
<pitti_dinner> mdz: indeed, there were three new ones; fortunately with patches
<pitti_dinner> pitti_dinner: not switch, select :-)
<Menaherann> holle
<Menaherann> could you guys help me with a problem that i have with ubuntu in my laptop?
<Menaherann> if possible/
<Menaherann> ?
<zul> have you tried on #ubuntu first?
<trulux> jdub: I dislike such jokes ;)
<Menaherann> yep but they haven't deliverd any results
<Menaherann> i don't have to much time, i just wanted t see if i could get some help here, so i can come bak letr and then deal with it....
<Menaherann> [gotta work] 
<mdz> lamont: ping
<lamont> ack
<mdz> lamont: cloop build changes
<mdz> lamont: there is an ubuntu-live metapackage in the queue now, headed for NEW
<Kamion> is the live seed actually sane?
<lamont> mdz: and livecd should have base+desktop+live?
<mdz> Kamion: jdub and I disagree a bit on this particular point :-)
<mdz> lamont: yes, note that the live seed will depend on language-support-en
<mdz> lamont: so you should be able to remove the locale.gen hack
<jdub> we don't disagree
<jdub> but it is up for discussion :)
<lamont> mdz: ok - want me to remove that in this round?
<mdz> so far, language-support-en is the only thing which makes obvious sense to me for the live seed
<mdz> lamont: once ubuntu-live is up, yes
<mdz> lamont: i.e., pthread_cond_wait(&elmo)
<Kamion> haha
<Kamion> gah, why is baz ignoring the cacherev in seeds--hoary--0--patch-10 and merrily patching away from base-0
<Kamion> oh, germinate totally ignores the live seed at the moment
<Kamion> I should fix that
<jdub> when are we going to start stripping mo files?
<zul> kablooie
<mdz> <mdz> the current live seed is fairly huge
<mdz> <mdz> gnumeric and abiword are over 10M each
<mdz> <mdz> jdub: isn't the "show off abiword and gnumeric" use case better satisfied by luis' live CD?
<mdz> <mdz> I'm inclined to remove everything but language-support-en for now, and have a serious discussion about what extra stuff should go on the live CD
<amu> elmo: could you give the kubuntu-meta your go into
<jdub> mdz: ok
<mdz> amu: elmo already gets mail about NEW automatically
<jdub> mdz: btw, can normal humans who usually just play in the cloop pool change the isolinux splash easily?
<mdz> jdub: yes
<mdz> jdub: isolinux/splash.rle
<jdub> boh
<jdub> i even saw taht the other day
<jdub> *bong*
<jdub> thanks
<amu> mdz: right, NEW have an average lag of 1-2 days 
<jdub> mdz: bmp in rle format?
<mdz> /mnt/isolinux/splash.rle: Syslinux SLL16 image data, 639 x 320
<jdub> oh ok, i gather there'll be a converter in syslinux
<Kamion> see the debian-installer source package
<mdz> jdub: if you do this experiment, please add instructions to the wiki howto
<Kamion> build/boot/x86/pics/
<jdub> mdz: i'll encourage luis to ;)
<Kamion> there are various README files there with conversion rules from .png
<Kamion> (etc.)
<jdub> Kamion: ah, ok
<luis_> mdz: I will, thanks
<mdz> luis_: excellent, thanks
<luis_> mdz: are you who i'd talk to about the language selections?
<mdz> luis_: which language selections?
<luis_> mdz: someone asked today about a dutch-language liveCD
<jdub> mdz: back to above; aren't we going to put more than just -en on the livecd?
<mdz> jdub: probably
<mdz> jdub: we're going to hit space limitations very soon though
<luis_> mdz: I have no answer for them, but I was curious if you or anyone else had given thought to fleshing out the language TODO in the wiki
<mdz> depending on how much win-foss we add
* Kamion wonders what germinate does if he puts a package already in ship in live as well
<jdub> mdz: surely that's because we're not stripping mo files from the original packages?
<amu> luis_: see http://sweb.cz/Frantisek.Rysanek/splash/isolinux-splash-HOWTO.html
<jdub>   1. convert klowner.png klowner.bmp
<jdub>   2. bmptoppm < klowner.bmp | ppmtolss16 #FBFDFA=7 > klowner.rle
<mdz> jdub: partly
<luis_> amu: ooh, awesome, thanks
<jdub> ^ the # colour there is the background
<mdz> jdub: remember that language packs have all of main in them, and we also would need to install language-support-XX
<jdub> mdz: that's going to require a full rebuild...
<Kamion> d'oh. apparently the answer is "just totally ignores it"
<jdub> mdz: i'd hazard a guess that BigTen of main would be smaller than mo files in all livecd packages
<mdz> Kamion: is there much point in germinating the live seed, since the live image builder doesn't use germinate?
<Kamion> mdz: curiosity :-)
<Kamion> mdz: also it's useful to give you size calculations
<jdub> it's a good check to make sure live is a subset of supported
<Kamion> that too
<Kamion> I thought I did most of the work required to support this earlier this afternoon, but apparently I need to do some more to support disjoint seeds
<Kamion> or, well, two seeds neither of which inherit from the other but which may expand to contain the same packages
<Kamion> but I want to do this anyway because it makes germinate more general, which is a good thing
<jdub> yes, the launchpad guys can look over your shoulder when they do it ;)
<mdz> hmm, forgot to add ubuntu-live to the live seed, adding now
<mdz> jdub: that's an easy hypothesis to test
<Kamion> jdub: ... might have been a result of reviewing something the launchpad guys were doing, yes ...
<mdz> 74M     usr/share/locale
<mdz> that's in the live environment
<jdub> Kamion: *blink*
<Kamion> # Keep this list topologically sorted with respect to SEEDINHERIT.
<mdz> jdub: add up BigTen Installed-Size and compare to that
<Kamion> I love writing comments like that; it gives me wonderful schadenfreude
<amu> :)
<jdub> mdz: hrm, ends up being around 96
<jdub> d'oh
<mdz> jdub: the language packs have, e.g. gcc translations in them
<mdz> speaking of which...build-essential in the live seed?
<jdub> yeah!
<Kamion> make germinate CRY
<jdub> one problem with having bigten installed by default
<jdub> (install, not live)
<jdub> is that locales regeneration is *insane*
<jdub> language-pack-en is bad enough ;)
<Kamion> -en only has about forty-seven locales, you wuss
<mdz> Kamion: does that make germinate cry any more than language-pack-en?
<mdz> er, s/pack/support/
<mdz> both l-s-en and build-essential are in ship already
<Kamion> mdz: no (and don't worry about it, anyway, the bug needs to be fixed and good test cases won't do any harm)
<luis_> hrm
<luis_> jdub: any opinions on the advisability of modifying system-wide defaults v. putting things (like a .gconf dir) into /etc/skel/ for the livecd?
<mdz> Kamion: does germinate-output/hoary obsolete germinate-hoary-output?
<jdub> luis_: system wide defaults is cleaner and easier to understand later
<luis_> that was my initial thought
<luis_> but it seems like maintenance-wise, it'll be a bigger hassle
<mdz> luis_: also consider that things in /etc/skel cost you memory and boot time when they are copied into the user's homedir, while system-wide defaults don't
<Kamion> mdz: yes, germinate-hoary-output is a compatibility symlink to germinate-output/hoary
<Kamion> I got fed up of the germinate-%s-output naming scheme
<luis_> mdz: ah, good point
<mdz> Kamion: so it would be safe to update ubuntu-meta, debzilla, and whatever other places use that
<luis_> mdz: though at this point I've got like 20M of data files in /etc/skel/ so defaults probably don't matter too much
<mdz> Kamion: (if you know others, tell me, I'm making a list)
<mdz> luis_: eek!
<jdub> luis_: (you should so symlink those)
<luis_> jdub: ooh
<Kamion> mdz: er, I didn't know anything automatic used germinate-output!
<Kamion> mdz: nothing should, since that output is only for i386
<luis_> jdub: you are wise beyond your years
<Kamion> mdz: ubuntu-meta only seems to use the seeds
<jdub> luis_: s/years/ears/g
<luis_> (though really I haven't noticed that much startup penalty)
<mdz> luis_: it is also perfectly valid to create /home/ubuntu on the cloop image
<luis_> jdub: also, mdz is wiser than you are
<mdz> that whole /etc/skel thing is pretty crack, actuaally, and I had been meaning to remove it from the howto
<amu> luis_: heh
<mdz> Kamion: ah, right; debzilla does use it though
<mdz> Kamion: and so its ideas about non-i386 are probably skewed
<luis_> amu- so, I've been really, really busy and totally focused on just getting this done for LWE
<luis_> amu: after I've burned it I'll write you an email describing everything I've done and we'll see how we can go about getting it merged into gnoppix, or whether or not that makes sense even
<Kamion> mdz: eek, OK, should I give you multi-architecture output?
<mdz> luis_: Kamion is the person to talk to about setting the default language
<Kamion> mdz: if so, leave the link alone for now and I'll make it keep pointing to i386
<mdz> Kamion: maybe; doesn't seem particularly urgent, though
<Kamion> booting with preseed/locale=<locale> should set the language
<Kamion> assuming I haven't broken localechooser recently :)
<mdz> is there a way to read preseed stuff from a file on the CD as well?
<mdz> "create /path/to/foo" is preferable to "edit isolinux/isolinux.cfg, add this parameter"
<mdz> for cut-and-pasteability
<seb128> elmo: have you synced evince this afternoon ?
<Kamion> yes, put the file on the CD and boot with preseed/file=/cdrom/foo/bar/baz
<jdub> luis_: in future, our configuration changes will be defaults files
<jdub> luis_: so that'll make life easier
<mdz> Kamion: bleah ;-)
<amu> luis_: cool, if we can merge, it will make the things easier ;)  
<Kamion> the file should look like 'd-i preseed/locale string en_GB.UTF-8' or similar
<amu> luis_: guess you didnt build debs?
<Kamion> mdz: consider that you can put preseed/file in isolinux.cfg once and never change it again
<Kamion> as in, *we* can put preseed/file in isolinux.cfg
<mdz> Kamion: does it DTRT if the file is missing?
<sri> hi all
<Kamion> mdz: think so; if not we can always make the file be present but blank
<luis_> amu: no, I've never built a deb in my life and this week didn't seem a good time to start :)
<sri> following up on my problem I've been having with my X cursor that I started having last week.
<mdz> Kamion: does kickstart by any chance have a parameter which specifies the default system runlevel?
<mdz> I implemented that in casper recently, and it deserves to be more generic if something else can use it
<sri> so currently, I kind have gotten xcursor somewhat working with ximian artwork
<amu> luis_: feel free and build rpm's alien convert them into deb *ducks*  
<sri> however, some stuff like the icon for drag doesn't show up
<luis_> haha
<Kamion> mdz: s/kickstart/preseed/
<luis_> never built an rpm either :)
<sri> and if I set it up such that I use default it's really awful (box wtih black and transparent lines)
<Kamion> mdz: oh, you actually do mean kickstart, sorry :)
<sri> so I'm kinda mystified now. :/
<Kamion> mdz: no, it doesn't
<mdz> Kamion: I actually meant kickstart in context, as in: would you have to implement this anyway in order to support compatibility with kickstart
<sri> any ideas?  I got the latest update from today
<Kamion> mdz: yeah, that just occurred to me, sorry
<mdz> ok, just another lonely casper hack then :-)
<amu> luis_: ;-)  
<sri> one other question, how do I get xorg to just use the built in default?
<mdz> doko: python2.4-minimal should not be essential
<mdz> only python-minimal
<mdz> doko: please fix
<mdz> hmm, probably away/asleep, will file bug
<Kamion> should be fixed immediately, I don't think dpkg forgets the essential flag once it's seen it once?
<Kamion> could be wrong, but
<sivang> pitti: If I am to comment the code of the uid change, I would take out the ability to set it up even when creating a new user, there is a way in the code to check if A user is new or old, so I will use that instead, ok?
<pitti> sivang: sure :-)
* Kamion watches hoary-changes and notes people skating even closer to the feature freeze than him. :)
<doko> mdz: ok
<mdz> doko: oh, good, you're here
<jdub> dear mister zimmerman
<mdz> doko: I filed #6362
<jdub> please choke esound like a baby kitten
<Kamion> -bazaar                                    | bazaar                          | Ship seed                                | Robert Collins <robert.collins@canonical.com>                             |          275892 |            1176
<Kamion> hmm, wonder what I broke
<pitti> yay
<jdub> and shove it into the garbage compactor
<Kamion> +bazaar                                    | bazaar                          | Live seed                                | Robert Collins <robert.collins@canonical.com>                             |          275892 |            1176
<jdub> like the vermin that it is
<jdub> love,
<Kamion> +bazaar                                    | bazaar                          | Live seed                                | Robert Collins <robert.collins@canonical.com>                             |          275892 |            1176
<jdub> jdub
<mdz> jdub: today, seriously?
<jdub> I AM SERIOUS
<mdz> POLYPAUDIO ARE GO?
<jdub> yeah
<jdub> can i add polypaudio-alsa and polyaudio-x11 to the seed?
<mdz> Kamion: I hope that isn't true about dpkg/essential
<jdub> and polypaudio-clients to supported?
<mdz> jdub: wtf is polypaudio-x11?
<jdub> load-module module-x11-bell sample=x11-bell sink=output
<jdub> :-)
<jdub> the machine that goes (nice) bing!
<mdz> its slacker maintainer didn't give it a proper description :-)
<mdz> but yeah, sure
<sivang> jdub: yay!
<jdub> heh
<jdub> WHERE WE'RE GOING, WE DON'T NEED ROADS
<sivang> jdub: heheh
<sivang> esound is dead , long live poly audio!!
<Kamion> jdub: yay back to the future
<jdub> Kamion: i often use it as test material
<Kamion> testing for what exactly?
<jdub> Kamion: recently for testing polypaudio/alsa synchronisation and then 5.1 output :)
<Kamion> ah :)
<jdub> also to see if there is still a heart beating in my chest
<pitti> Mithrandir: ping
<jdub> mdz: (note: polypaudio-alsa by default)
<sri> ha, fixed my prboelm.
<sri> I rock.
<pitti> Mithrandir: http://www.ubuntulinux.org/support/documentation/usn/usn-78-1
* sri does the 'X cursor, you suck, and I win," dance.
* sri does an exit..stage left.
<sivang> jdub: what hardware did/are you going to test 5.1 output on?
<jdub> have tested
<jdub> nforce2
<sivang> cool 
<pitti> night, guys
<Kamion> gar, no python 2.4 in warty => I don't get to use the sets module in germinate :(
<mvo_> mdz, jdub: can we have the isdn stuff in ShipSeedProposals in the ship seed plesae? at least pppdcapiplugin and capiutils is essential for isdn support.
<doko> mvo_: yes please, I think they are marked as such in the Wiki
<sivang> jdub: should probably work fine on emu10k right?
<jdub> haven't tried
<mjt> ok, so it seems quite alot of ppl are having probs with MD5Sum mismatches when apt-get update'ing hoary 
<mdz> mjt: that usually means that they got Release from one mirror and Packages from another
<mjt> "usually" does not apply in this case ;)
<mdz> mjt: ?
<mjt> take a look into #ubuntu
<mjt> i *know* i specified all that stuff correctly
<mjt> on my machine anyway
<mdz> I didn't say that you specified it incorrectly
<Kamion> mjt: think round-robin DNS
<seb128> mdz: that happens here too, and I've only archive in my sources.list
<mjt> host archive.ubuntu.com
<mjt> archive.ubuntu.com has address 82.211.81.138
<mjt> no round-robin DNS
<Kamion> oh, that was round-robin until recently ...
<mdz> yes, i thought so too
<mdz> anyway, it's happening to me, too
<mdz> perhaps auckland is itself out of sync
<seb128> Kamion: I think there is an issue somewhere ... does it work for you ?
<Kamion> seb128: I haven't noticed any problems, but I update irregularly
<Kamion> it worked for me half an hour ago or so
<mjt> ditto here
<mjt> but does not work now
<mvo_> I get md5sum mismatch here now too
* thom dropkicks firefox in the head
<seb128> I've the issue for like 1 hour
<seb128> and I've updated a bunch of times
<mjt> does it really mismatch, anyone tried to verify? ;)
<jamin> i get errors when i run apt-get update too.  and then it tells me i should run apt-get update to fix the problems. :)
<dilinger> thom: ooh, do it again!
<sivang> phe, /me getting the same
<mjt> hmm.. only 5min TTL for archive.ubuntu.com A record -- it it normal?
<mdz> mizar:[/tmp]  grep main/binary-i386/Packages.gz Release
<mdz>  ea462f666061853e4e2397429f6a9768           562705 main/binary-i386/Packages.gz
<mjt> and the md5 sum of the file is? ;)
<Kamion> yeah, fails on amd64 now too
<mjt> btw, what's the point checksumming .gz file instead of the original?  There are many ways to gzip the file (-0..-9 etc), but original content does not change
<mdz> 67d8d283a8c9e5e25ad5d43f06b7e36e  Packages.gz
<mdz> mjt: if it says the md5sum doesn't match, it doesn't match
<Kamion> mjt: .gz file is what you download, it's convenient to have that in Release
<thom> dilinger: with pleasure
<mdz> mjt: Release has checksums for uncompressed, gzip, and bzip2
* thom roundhouse kicks firefox in the head
<dholbach> thom: how do you do that? roundhouse kicking is new to me :-)
<Kamion> dholbach: knee up to the side, twist while extending foot
<mjt> re checksumming .gz: imagine that same apt-proxy which gets the file using rsync and gzips it after - it will not work
<mjt> s/work/match/; s/it/checksum/
<dholbach> Kamion, thom: wow... you two are doing martial arts, right? ;-)
<Kamion> roundhouse kicking is not a concept entirely exclusive to martial arts :)
<thom> only on firefox
<mdz> mjt: that would be an example of a broken proxy
<jdub> dholbach: Kamion is irish, he learned this at the pub when only a bairn.
<dholbach> Kamion: well it's no known concept where i live :-)
<Kamion> anyway I think of a roundhouse kick as mawashigeri ;)
<doko> elmo: any chance to get libmpr-dev into main? gcc-4.0 builds are currently broken.
<dholbach> Kamion: you do karate! :-)
<Kamion> dholbach: yeah
<Kamion> although nowhere remotely close to, say, lamont's standard
* dholbach can still remember mawashigeri - although it's been 12 years since i was instructed how to do it 
<seb128> new control-center coming which handles xmodmap files, I think it'll make some people happy :p
<jdub> seb128: ooh
<dholbach> you guys seem very destructive to me in general
<jdub> seb128: more crazy X keyboard bugs to chomp on!
<seb128> :)
* seb128 wonders if he should upload the new evince to hoary
<dholbach> roundhouse-drop-whatever--kicking, choking-kittens - that's not nice at all
<dholbach> seb128: go ahead :-)
<seb128> uploaded it this afternoon to debian and asked for a sync to elmo, but no sync for the moment
<sivang> seb128: GO! GO! GO! ;-)
<Kamion> dholbach: broken software does this to you
<dholbach> Kamion: i must have found other ... compensation
<dholbach> s
<Kamion> argh, extra complication in germinate
<seb128> thom: stop kicking firefox and fix the cursor :)
<Kamion> so, when it finds a package needed in, say, the ship seed that's currently in, say, supported, it promotes it
<Kamion> but if that package is needed in the live seed too, now there's nowhere from which to promote it
<Kamion> I think I need to have it leave a shadow or something
<lamont> Kamion: how about supported->ship->live->desktop->base?
<lamont> that is, force ship to be a superset of live
<Kamion> lamont: could do, but it's semantically wrong and I want the flexibility anyway ...
<lamont> ah,ok
<lamont> so supported->{live,ship}->desktop->base?
<lamont> to continue my sloppy syntax
<Kamion> lamont: yeah
<Kamion> SEEDINHERIT = {
<Kamion>     'desktop':          ['base'] ,
<Kamion>     'ship':             ['base', 'desktop'] ,
<Kamion>     'live':             ['base', 'desktop'] ,
<Kamion>     'supported':        ['base', 'desktop', 'ship', 'live'] ,
<Kamion> }
<sivang> hrm, nice => http://nat.org/2005/february/#9-February-2005
<lamont> Kamion: cool
* lamont goes to fetch kids
<sladen_> lamont: do you know if the kexec stuff is packaged?
<jdub> amu: around?
<amu> jdub: yep
<sivang> jdub: so gnomeui is considered as dead ;-) http://developer.gnome.org/doc/API/2.0/libgnomeui/gnomeapp.html ?
<ajmitch_> morning
<jdub> sivang: it'll be deprecated soon; why?
<sivang> jdub: ah, that link is broken is it intentional or just an error?
<jdub> oh, dunno
<jdub> 404?
<jdub> probably error
<jdub> http://developer.gnome.org/doc/API/2.0/libgnomeui/
<sivang> yeah, ok never mind
<shaya> uh, anyone else get MD5 errors when they try to apt-get update?
<shaya> Failed to fetch http://archive.ubuntu.com/ubuntu/dists/hoary/main/binary-i386/Packages.gz  MD5Sum mismatch
<shaya> Failed to fetch http://archive.ubuntu.com/ubuntu/dists/hoary/universe/binary-i386/Packages.gz  MD5Sum mismatch
<shaya> Failed to fetch http://archive.ubuntu.com/ubuntu/dists/hoary/main/source/Sources.gz  MD5Sum mismatch
<jaco> shaya it don't works this evening i think
<lup|gnometogtk> jdub, then this http://bugzilla.gnome.org/show_bug.cgi?id=165804 will have to be integrated in gtk ?
<jdub> lup|gnometogtk: lots of stuff will be
<jdub> the migration has already begun :)
<shaya> jaco: isn't it a bit beyond evening for you?
<seb128> jdub: should we drop the network icon from computer:/// (#2302) ?
<jdub> yes :)
<seb128> right
<seb128> thanks :)
<Mithrandir> seb128: new gaim uploaded
<seb128> cool
* jdub is grateful for the easy question for a change ;)
<jdub> Mithrandir: dude
<shaya> seb128: evolution is usable again :)
<jdub> Mithrandir: so i was thinking
<seb128> shaya: amd64 ?
<shaya> imap on any platform
<seb128> oh that
<jdub> Mithrandir: how hard would it be to add an "accept mails signed by keys in this keyring" option to mailman?
<shaya> I was getting used to thunderbird
<jdub> Mithrandir: that could handle mime and inline sigs?
<shaya> evolution needs an rss reader integrated with it
<Mithrandir> jdub: easy.
<jdub> shaya: blam
<seb128> shaya: what bug was that ?
<jdub> Mithrandir: i would love that feature :-)
<Mithrandir> jdub: give me some beer and a couple of hours and you'll have it. :P
<jdub> Mithrandir: you coming to .au? ;)
<shaya> jdub: I actually like thunderbird's better.  blam only has the feed, it doesn't remember all entries
<Mithrandir> jdub: 'course.
<jdub> shaya: oh? sucky
<jdub> shaya: use Planet :-)
<jdub> Mithrandir: rock, beer's on me :-)
<shaya> planet doesn't remember what you read or want to read again
<shaya> i like the read/unread interface
<jdub> heh
<jdub> PICKY!
<jdub> tried straw?
<shaya> no
<shaya> doesn't seem to be in ubuntu
<Mithrandir> straw scrolls the item window to the top when the feed is refreshed.
<thom> i like the "not sucking" part of planet, which is somewhat lacking from every other linux rss reader
<mdz> Kamion: mind if I make the apt-setup template change I just suggested on the list, or would you rather do it?
<shaya> thom: thunderbird is the best one I've used
<Mithrandir> thom: doesn't have any feed priority thingy
<jdub> shaya: make a hep account and use rss by imap in evolution :)
<thom> shaya: i think you're making my point for me :-)
<Mithrandir> which means news sites which get 60-ish stories a day would dominate.
<Mithrandir> shaya: chunderbird is kinda crackful.
<shaya> hep account?
<jdub> google for hep
<shaya> hmm
<shaya> hep is interesting
<shaya> packaged for ubuntu?
<jdub> no
<jdub> you can just create a hep accountv
<jdub> on the demo site
<jdub> but it shouldn't be hard to use on ubuntu
<jdub> if you want to run it locally
<shaya> demo site?
<Mithrandir> rss2email too; I'm considering setting it up and just dropping it in some maildir
<shaya> anyways
<shaya> time for a 90 minute showing of new stargate sg1 episode
<enrico> Hello.  I did cat /etc/debian-version on Hoary and it says "3.1".  Is that intended?  And is there a way to detect what is the ubuntu version?
<dholbach> enrico: cat /etc/lsb-release
<enrico> dholbach: thanks!
<dholbach> enrico:    grep DISTRIB_RELEASE /etc/lsb-release | sed 's/DISTRIB_RELEASE=//g'   :-)
<enrico> oh.  Debian doesn't have /etc/lsb-release...
* dholbach already did that just today :-)
* jordi is being interviewed about Ubuntu. Dunno why me, but anyway, I think I can answer these without saying too much nonsense.
<jdub> jordi: when they ask "who is your daddy?" the correct answer is "mako"
<jordi> jdub: :)
#ubuntu-devel 2006-02-13
<ajmitch_> afternoon sabdfl 
<sabdfl> hey guys
<dieman> mjg59: yo, for your laptop stuff how can people help out with 'odd' laptops?
<dieman> mjg59: for that brightness thing
<dieman> that you blogged about
<dieman> ive got a fujitsu i wouldn't mind being able to do it on :)
<desrt> BenC; ping?
<lucas> hi
<zakame> heya lucas 
<pitti> Good morning
<freeflying> pitti: hi
<freeflying> pitti: I've mail you what you need about scim
<pitti> freeflying: yay, thanks
<pitti> freeflying: just read it, awesome
<freeflying> pitti:  :(
<pitti> freeflying: why :( ?
<pitti> freeflying: I'll do the new language-support packages today then
<freeflying> s/(/)
<freeflying> pitti: the fonts about chinese should be solved 
<pitti> freeflying: hm, we recently changed to ttf-arphic-ukai/uming, that's not enough?
<freeflying> pitti: cool ,thx
<jdub> BenC: ping
<dholbach> good morning!
<freeflying> pitti: the seeds of dapper still use ttf-arphic-bkai00mp ,etc now 
<pitti> freeflying: hm, indeed
<pitti> freeflying: sorry, I thought this had already changed
<pitti> freeflying: ok, so I throw out the 4 old ones (bkai00mp, bsmi00lp and so on) and replace them with ukai and uming?
<freeflying> pitti: nice 
<pitti> freeflying: that will additionally need about 11 MB of CD space
<pitti> freeflying: what would be the advantage of ukai/uming over the current fonts?
<pitti> freeflying: (NB that we still need to *remove* 25 MB from the CDs to get them in the right size again)
<siretart> morning
<pitti> hi siretart 
<siretart> huhu pitti 
<freeflying> pitti: ttf-arphic-gkai00mp ttf-arphic-gbsn00lp can be removed also
<siretart> who is actually keeping track and processing https://wiki.ubuntu.com/MorgueCandidates ?
<freeflying> pitti: uming/ukai can display chinese well then those used be 
<dholbach> siretart: we'll have to - a list of stuff we already told James, which was removed and still is to be removed.
<freeflying> pitti:  after remove those four fonts , no extra space need for uming/ukai at all
<pitti> freeflying: yes, I took them into accout already; current set of fonts is 16.5 MB, ukai+uming about 24
<pitti> ok, so it's only 8 MB more, but still
<siretart> dholbach: I see
<freeflying> pitti: as for scim , more space need ?
<dholbach> siretart: We can expect him to track a wiki page.
<siretart> dholbach: in which timeframe?
<pitti> freeflying: yes, but scim is smaller; still, we cannot actually afford more stuff on CD
<dholbach> siretart: timeframe?
<pitti> freeflying: but we can throw out more language packs
<pitti> freeflying: I'll talk with Kamion once he's back from his illness
<freeflying> pitti: waiting for good news from you  :)
<siretart> dholbach: In which timeframe can we expect that MorgueCandidates are actually removed?
<dholbach> siretart: No idea, if we sent new candidates everyt two weeks - would that make sense?
<dholbach> siretart: removing source packages doesn't sound ultra-urgent to me, does it?
<siretart> dholbach: it should be done. I'm quite frustrated because I had an urgent removal request 3 weeks before breezy release, which got missed
<dholbach> If we start mailing now, every two weeks that should be fine for release, no?
<siretart> I hope se
<Kagou> hi
<Kagou> where can i found build logs of daily iso ?
<siretart> dholbach: ok, I have a rather long list of packages which are on MorgueCandidates and already removed. I will remove them from there
<dholbach> siretart: Thank you very much.
* dholbach hugs siretart
<dholbach> There must be something wrong with lists.ubuntu.com - all the -motu posts I checked in the archive look like this: https://lists.ubuntu.com/archives/ubuntu-motu/2006-January/000192.html - no mail text at all. :/
<jdub> hrm
<jdub> and where is the sexy template?
<jdub> Znarl: ping
<fabbione> see
<fabbione> i join the channel and jdub starts "sexy talk..."
<sivang> morning all
<dholbach> hey mvo
<dholbach> hey sivang
<mvo> hey dholbach
<Pygi> mornin'
<Tm_T> oh boy, where's libortp0 from dapper
* sivang hugs dholbach mvo Pygi 
<janimo> dholbach, hey any news on the xfce ufv exceptions?
<dholbach> janimo: Ah, I was just looking for you on ubuntu-motu.
<janimo> I am a lazy motu so did not show up recenmtly :)
<dholbach> janimo: could you attach changelog diffs and diffstat?
<janimo> I am here mostly
<janimo> dholbach, there are ~ 20 packqages
<janimo> I have no diffstatts either since it's a 4.2->4.3 transition
<janimo> most are very heaviuly tweaked
<janimo> and the debian changelog is ostly 'upstream svn snapshot'
<janimo> mostly
<dholbach> Could you discuss this with Matt and Colin on your own then?
<dholbach> I meant the upstream ChangeLog.
<janimo> dholbach, yes I will
<dholbach> Thanks a lot.
<seb128> hey dholbach
<janimo> upstream is lazy and does not keep changelog, they rely on svm logs
<dholbach> GAR!
<janimo> I mean they update the changlog before release usually
* dholbach is out for a dogwalk
* seb128 kicks network-manager
<dholbach> hey seb128
<janimo> dholbach, have a nice dogwalk :)
<dholbach> janimo: thanks
* mvo waves to seb128
<Pygi> seb: what's the problem with network-manager this time? :P
<seb128> hey mvo
<seb128> resolv.conf with no dns configured
<seb128> and dunno if that's due to nm, but:
<seb128> # sudo ifup eth0
<seb128> ifup: failed to open statefile /var/run/network/ifstate: No such file or directory
<Pygi> ah, I ussualy don't bother on GUI tools 'cause I'm used to them not working'
<Pygi> but it should be fixed
<Mithrandir> pitti: you can't detect whether you're on a live cd or not.  That's a feature.  I wonder if just setting a blank password would solve 30118 better.
<pitti> Mithrandir: hm, not even by looking at /proc/mounts or so?
<Mithrandir> pitti: I think answering the question "what is a live cd" would be a good start, really.
<jamesh> seb128: https://launchpad.net/malone/bugtrackers/ubuntu-bugzilla/20183 <- deleted the bugwatch and reimported this bug
<seb128> jamesh: yeah, I've noticed the bunch of mail from malone, thank you :)
<Tm_T> should I file a bug, I need libortp0 back to dapper
<Mithrandir> jamesh: got a chance to look at debian bug #340904 ?
<Tm_T> incoming Kopete 0.12 needs it in jabber jingle voice support
<jamesh> Mithrandir: not yet, sorry.
<Mithrandir> jamesh: np, just didn't get any response at all earlier, so I continued prodding.  I'll stop now.
<janimo> Mithrandir, can the livecd kernel be passed some option if it's not started by grub?
<jamesh> thanks for prodding :)
<Mithrandir> janimo: it's started by syslinux/isolinux, but there's no reason why you can't boot it using grub as well.
<Mithrandir> janimo: you mean for detecting whether this is a live cd or not?
<janimo> yes
<Mithrandir> well, you could look at whether /proc/cmdline contains boot=, but it's not the right fix at all
<Mithrandir> with persistent mode, I think the live cd should behave like a real system
<janimo> yes I mean /proc/cmdline and having syslinux and grub pass different thins there not necessarily boot but some magic kewyword
<Mithrandir> boot=casper, I meant
<janimo> aha
<Mithrandir> anyway, I'm testing another fix for the problem now
<Kamion> pitti: have you seen all the Debian bugs about sudo environment variable breakage? Do they affect us too?
<pitti> Kamion: I saw some, I'll read about them again; I talked with elmo about the katie breakages, but he said he already adapted to that
<pitti> Kamion: but precisely for that reason I don't want to stuff that patch into stables
<Kamion> concerns me for dapper too
<pitti> Kamion: since we keep variables for non-restricted users, we should be less affected, though
<Kamion> ok
<pitti> Kamion: it's in the dapper release notes, but I think we just have to cope with a whitelist; otherwise restricted sudo does not make sense at all
<Kinnison> What package provides the "restart required" dialog? Is it update-notifier?
<pitti> Kinnison: yes
* Kinnison is filing bugs from his dapper install experience on monday night
<seb128> what is the bug about?
<Kinnison> truncated restart required bubble
<Kinnison> bug 30812
<Ubugtu> malone bug 30812 in update-notifier ""restart required" bubble appeared truncated" [Normal,Unconfirmed]  http://launchpad.net/bugs/30812
<seb128> that's one for mvo :)
<ogra> yeah, i noted that too 
* ogra goes confirming
<jdub> wow, irssi pulling 83MB resident
<jdub> guess i should clear some backlogs
<maswan> ... or get more ram. ;P
* Kinnison files bug 30813 too
<Ubugtu> malone bug 30813 in synaptic "add repo dialog misnames dapper as breezy" [Normal,Unconfirmed]  http://launchpad.net/bugs/30813
<maswan> http://www.acc.umu.se/~maswan/2005-12-10/2gbit-freesoftware.html <- btw, that's final now, anything you guys want to give publicity to?
<maswan> like sticking it on the fridge or so
<jdub> hrm, cleared a lot of backlog, but irssi is still pulling lots of ram
<jdub> might try its restart thingy
<jdub> maswan: looking
<Kinnison> wow, the distro team close bugs fast
<Kinnison> mvo: thanks dude
<mvo> Kinnison: thanks for reporting it :)
* Kinnison has one more to report
<Kinnison> on glibc
<mvo> the upgrade prompt thing?
<mvo> I think that is reported already
<fabbione> yeah
<fabbione> i did
<Kinnison> oh, I couldn't spot it
<Kinnison> I may have to go and dupe it
* Kinnison goes to look
<Kinnison> hmm, related but I'm not sure they're dupes
<jdub> maswan: whoa, nice!
<Diziet> Cripes, we're wading in `compreg.dat' reports.
* sivang reads last report of distro sprint.
<Kinnison> Diziet: whassat?
<sivang> Diziet: didn't you solve / workaround that?
<Diziet> There's something out there that creates a file called `compreg.dat'.
<Diziet> But we don't know what it is.
<Diziet> Whatever it is, it runs as root.  And we have to make it not do that somehow.
<sivang> Kinnison: FFox related
<Diziet> 30791 and its (half a dozen, at least) dupes.
<sivang> Kinnison: FFox and dependants, I think
<seb128> Diziet: the bunch of mails you got about that is because I asked to jamesh to import the bugzilla bug, it was not migrated because there was a launchpad task pointing on it before the migration
<Diziet> Ahh.
<seb128> ie: those are not new bugs we have got recently
<seb128> and the import updated all the duplicates to point to that one
<Diziet> Hmm.  I'm not sure I really want to assume^Whope that it has just vanished.  But I'm really stuck for a way to diagnose it.
<seb128> we didn't get any complain for it for some time
<seb128> but I think there is not a lot of people who do breezy to dapper updates at the moment
<Diziet> When there are I'm sure it will show up again.
<seb128> most people did them some time ago to track dapper or will do when dapper is stable
<jdub> maswan: published :-)
<seb128> probably :/
<Diziet> I suppose perhaps we can get testers to do that evil thing I suggested.
<seb128> Diziet: I'll do that next time I do a 5.10 install/dist-upgrade to dapper
<seb128> but I didn't get the issue previous time I did that
<WaterSevenUb> hey. which package provides the installation splash screen?
<Diziet> seb128: Yes, same here.  Very frustrating.  Thanks.
<maswan> jdub: thanks :)
<mvo> Diziet: I found the reason for the compreg.dat I think. it seems to be created by gtkmozembed in gnome-app-install
<Kamion> WaterSevenUb: which splash screen?
<Diziet> mvo: Oh !  So do you have a recipe to reproduce it ?
<WaterSevenUb> kamion, dapper installation, first screen, f2 language, accessibility, etc...
<Kamion> WaterSevenUb: various things cooperate to create that, but mostly gfxboot-theme-ubuntu
<sivang> Kamion: are you working on a graphical boot loader? (Saw a bit about it in the last sprint report)
<Kamion> sivang: already done
<Kamion> try e.g. the last Flight CD
<mvo> Diziet: in a breezy chroot, rm compreg.dat (if it is there already), run sudo gnome-app-install, check if the file is there again
<Kamion> or the one before that for that matter ...
<Diziet> Oh, that simple !
* JaneW got disconnected will repost Q
<JaneW> hi all. Does anybody know what (if any) efforts are being made to support Ubuntu for IntelMac
<JaneW> I have a journo asking, and he has asked Red Hat; Suse; Mandriva etc
<mjg59> JaneW: Right now, none - I don't think any of us have the hardware
<mvo> Diziet: if you want to do it in dapper I need to send you a small patch to make g-a-i work with pymozembed again (but it will crash, so it may spoil the fun)
<mjg59> JaneW: But at the moment, there's no way of supporting the graphics, so it's a bit of a moot point
<Diziet> mvo: That explains why the reports have stopped coming, too.
<JaneW> know if there are plans for it for Dapper +1
<JaneW> the guy is reporting for Computerworld magazine
<mjg59> JaneW: I'm certainly interested in supporting the laptops as quickly as possible
<tseng> JaneW: if redhat drops the appropriate code soon, it would be a non-issue
<WaterSevenUb> kamion, thx. I was trying to figure out why when we select other language via F2, the main menu options do not appear translated.
<mjg59> JaneW: But we're blocked on graphics hardware support
<tseng> JaneW: (not that i would quote that)
<JaneW> mjg59: what's the issue with it?
<mjg59> JaneW: It's a 
<JaneW> can we come up with an official stance?
<mjg59> n entirely new graphics chipset, and we can't drive it
<Kamion> WaterSevenUb: no infrastructure for translating the main menu options yet, sorry
<JaneW> oic
<Kamion> JaneW: ATI need to release the specifications
<mvo> Diziet: yes, that was the clue that I needed
<mjg59> JaneW: And it's unlikely that the Apples have VESA BIOSes, so we can't use the vesa driver
<mjg59> (Of course, having the hardware would make checking this quite a bit easier)
<JaneW> "Red Hat says contrary to earlier reports, there's no official plans now; Suse says it's going to wait for the community to bring them a working ELILO dual-boot loader, essentially; Mandriva says it's working on something in-house and hopes to have something ready by Q2.  
<JaneW> "
<mjg59> Kamion: For 2D, it'll be fairly easy to reverse engineer
<Kamion> in the event that they *do* have VESA BIOSes then we'll be fine, ish
<ogra> additionallywe dont know about the boot procedure of these things ... i heard they have no supportable BIOS ...
<Treenaks> ogra: they have EFI
<Kamion> ogra: it's EFI, which is like ia64
<tseng> ogra: "working elilo boot loader"
<mjg59> JaneW: But in any case, without any of the developers having any of the hardware, we're not going anywhere :)
<ogra> ah, k
<ogra> mjg59, another laptop for your collection ? :)
<Treenaks> Speaking of ATi.. I still have 2 bugs open on the current driver :(
<Treenaks> one for the LaptopTestingTeam laptop
<Treenaks> s/the/my/
<jbailey> Kinnison: glibc work won't start until later today to give Celso time to hunt a Soyuz bug. =)
<jbailey> Kinnison: (I don't want to destroy the evidence)
<Kinnison> evidence?
<Kamion> WaterSevenUb: if you're keen to translate something, I'd love to have at least *one* translation of installer/build/boot/x86/help.pot in the debian-installer source package, so that I can make sure the translation infrastructure for that works
<Kamion> that will give you a translated help menu
<jbailey> Kinnison: bug 30621
<Ubugtu> malone bug 30621 in malone "glibc changelog seems to list two versions and have eaten a line for the changelog" [Normal,Rejected]  http://launchpad.net/bugs/30621
<jbailey> Ah, perhaps he's finished with it now.
<WaterSevenUb> kamion, let me have a look.
<jbailey> Ubugtu: Lier.
<jbailey> liar, rather.
<jbailey> I wonder where I file bugs against Ubugtu.
<jbailey> Ah, well.  Exercise time first.
<Kamion> http://people.ubuntu.com/~cjwatson/testing/ and http://people.ubuntu.com/~cjwatson/testing-ports/ are working again now
<Kamion> Mithrandir: ^-- since you were asking for them
<Mithrandir> Kamion: \o/  thanks
<Mithrandir> ooh, ubuntu-desktop seems installable.  Is the debootstrap problem fixed so I can roll images?
<sivang> Kamion: cool, it both usable on CD boots as on HD boots?
<Kinnison> Mithrandir: I fixed the publisher, dunno about debootstrap itself yet
<ogra> doko, any news about zope3/schooltool ? 
<Kamion> sivang: only CD
<Kamion> Mithrandir: heading towards the archive now
<ogra> (i need it to make edubuntu-server (and the CDs) work)
<dholbach> ogra: jinty
<Kamion> but there's still the vim-runtime priority bug which will break image building
<Kamion> 10:07 < Kamion> elmo: please make vim-runtime Priority: important, sorta urgent
<ogra> dholbach, yes, but doko was already in contact with him
<WaterSevenUb> kamion, yeah, it seems easy. Just a stupid question, where can I access this help menu in the installation?
<Kamion> WaterSevenUb: F1 on a VERY current CD image
<Kamion> like, today's
<WaterSevenUb> kamion, 8Feb :-p
<WaterSevenUb> :)
<Kamion> try pressing F1 then
<Kamion> oh, probably not a new enough d-i on it or something
<Kamion> in that case you can't access it yet; tough :)
<WaterSevenUb> i've already tried...
<WaterSevenUb> yape:) That's problematic to test the translation :)
<JaneW> Kamion: can I say we expect support to be avilable in the Dapper+1 time frame? (IntelMac)
<Kamion> JaneW: I don't think we can promise anything
<mjg59> JaneW: It's /possible/ (though not likely) that it could be done in the Dapper time frame
<Kamion> if it's closed hardware then we're stuffed until magic appears
<mjg59> But right now, it's impossible to know how long it is
<mjg59> Kamion: The graphics stuff isn't going to be a blocker for long
<JaneW> ok I'll be suitably vague ;)
<mjg59> Kamion: There's way too much incentive to get that fixed
<Kamion> WaterSevenUb: yes, sorry, I'm happy for a contributed translation to be untested
<WaterSevenUb> kamion, will do it. ok:)
<Kamion> mjg59: yeah, but at the same time we really ought not to promise things that aren't entirely in our control
<Kamion> WaterSevenUb: meh, current d-i failed to build because of locales crap shifting around under me
<Kamion> I'll sort that out
<JaneW> thanks guys
<irvin> hi all
<Riddell> Kamion: could you promote these source packages to main?  scim skim scim-qtimm im-switch anthy; and these binary: anthy im-switch libanthy0 libscim8c2a libskim0 scim scim-qtimm skim
<Kamion> Riddell: I cannot do promotions at the moment, sorry.
<Kamion> ask elmo
<Kamion> (I suggest mail)
<Riddell> ok
<HiddenWolf> yay, there was finally a conclusion to the input-debate? :)
<lucas> what's the problem with elmo ? He seems to have a huge backlog regarding sync requests
<lucas> he is still ill ?
<dholbach> lucas: try to tame your tongue a bit. "what's the problem with elmo?" is not appropriate at all.
<dholbach> lucas: You're speaking about a person - keep that in mind.
<tseng> lucas: he did just spend the last weeks slaving to move the archive to launchpad.
<Kamion> lucas: the fact that folks including elmo are still very busy rewriting ftpmaster tools to work with launchpad is relevant; individual sync requests are much less important
<HiddenWolf> mjg59: ping
<mjg59> HiddenWolf: Hi
<lucas> dholbach: sorry, my fault. the french equivalent of " what's the problem with <sbody> ?" is ok
<lucas> Kamion: ok
<HiddenWolf> mjg59: Hi.
<HiddenWolf> mjg59: pitti and seb128 referred me to you.
<HiddenWolf> mjg59: I'm having an issue that when watching a movie fullscreen in totem, my monitor goes to standby. I'm guessing this is because g-p-m overrules totem/screensaver and sends the monitor to sleep.
<ogra> HiddenWolf, plesae file a bug on totem
<seb128> ogra: why?
<siretart> Kamion: I completly agree that James has more important things to do than processing sync requests. Anyway, is it really necessary that he does all syncs himself? can't this be delegated to someone with more ressources?
<ogra> gnome-screensaver respects the _NET_WM_STATE_FULLSCREEN_ setting afaik 
<ogra> seb128, ^^^
<ogra> the app should set it
<seb128> the issue is not gnome-screensaver
<HiddenWolf> ogra: I did that yesterday, and hadess replied with "NOTMYPROBLEM"
<seb128> totem speaks with gnome-screensaver by dbus and that works fine
<ogra> seb128, exactly, the issue is the app not setting the state
<seb128> the issue is not the screensaver starting but the screen going to standby
<ogra> then i wonder what the wm--spec is written for
<ogra> oops, i didnt get that above .... ignore me 
* ogra shuts up
* HiddenWolf hugs ogra
<Kamion> siretart: my understanding is that it will be once the relevant launchpad code is written
<Kamion> siretart: for now, delegation has the ultimate effect of creating more work for James because he still has to keep track of which sync requests other people have randomly picked up and ensure that all of them get done; that's why he asked mdz and me not to do them
<seb128> ogra: _NET_WM_STATE(ATOM) = _NET_WM_STATE_FULLSCREEN
<seb128> ogra: according to xprop
<seb128> ogra: totem does use the wm-spec, you should try before ranting on apps not following a spec
<ogra> seb128, yes, i guess g-p-m needs a patch
<siretart> Kamion: I'm a bit concerned that the releavant spec has priorty 'NOTFORUS': https://launchpad.net/products/launchpad-upload-and-queue/+spec/package-source-management . This indicates that changing the current process is not a priority
<ogra> seb128, i haver bugs about totem-xine, i mixed that up
<seb128> ogra: note that fullscreen is probably a windowmanager issue and not an app one
<ogra> seb128, but movie players shoud set the state, no ? 
<Kamion> siretart: I don't think that has much bearing on reality
<Kamion> frankly
<siretart> I hope se. really
<siretart> s/se/so/
<Kamion> given that e.g. a basic reimplementation of the sync tool for use with launchpad has already been written
<siretart> ah, thats good to hear.
<Kamion> also, it's entirely legitimate for the soyuz team to put process improvements below bringing soyuz up to par with the process implemented in katie
<Kamion> I have no complaints with them doing so
<seb128> ogra: dunno what they should do, but according to xprop it has "_NET_WM_STATE(ATOM) = _NET_WM_STATE_FULLSCREEN" and it speaks by dbus to gnome-screensaver so that's probably not an app bug
<ogra> seb128, as i said above, g-p-m needs a patch to respect this ...
<siretart> /me neither. 
<ogra> (i wonder why dbus is needed if the X atom is set)
<ogra> isnt that duplication ? 
<Mithrandir> because there's no such thing as just using a single hammer?  Be sure to use the whole array of options.
<janimo> Kamion, I talked to dholbach about bulk approval of updating to xfce 4.3 and related UVF exception (the one I asked for in advance in the TB meeting of Jan 17th)
<ogra> heh
<janimo> he said I talk to you or mdz since these are apporved for main pending promotion so not MOTU territory
<seb128> dunno exactly how gnome-screensaver work, I guess that the dbus dialog is when using it without fullscreen
<ogra> ah, that'd make sense
<janimo> and also because there's no diffstat/changelog it's basically ~20 packages from a new development line
<seb128> and anyway why a fullscreen should stop the screensaver?
<seb128> you can pause a movie for some hour
<janimo> so could either you or mdz approve uploading them
<seb128> the screen should standy then
<ogra> because you dont want it to pop in while watching a movie
<seb128> fullscreen doesn't indicate you watch anything
<janimo> they're stable enough and soon to become 4.4
<ogra> but its likely that you watch something ...
<Kamion> janimo: please send e-mail about this with a description of the changes
<Kamion> to me and mdz
<Kamion> we don't typically do approvals of large changes by IRC
<ogra> even if its only a audion vizulazation plugin
<janimo> Kamion, will do thanks
<seb128> ogra: why? some people have a command line in full screen, some other have a text editor open in fullscreen, etc
<ogra> seb128, i'm not talking about terminals ... only about players
<seb128> the wm-spec doesn't say what kind of app you are using, does it?
<ogra> and i think its very likely you want to watch if totem runs fullscreen
<ogra> nope
<seb128> so how is gnome-screensaver supposed to know?
<ogra> but as you pointed out, totem already uses it
<ogra> and g-s-s respects it ...
<azeem> seb128: you don't run editors full screen usually, only maximized
<ogra> lets just make g-p-m work the same way
<ogra> no need to discuss it to death :)
<seb128> azeem: it was a random example to point that not only player have a full screen option
<seb128> you can open a pdf fullscreen to read it if you prefer the example
<seb128> that should not prevent the screen to go standby if you run away an hour
<torkel> azeem: hitting F11 in the latest gnome-terminal runs it in fullscreen :-)
<azeem> torkel: ugh
<seb128> azeem: same for epiphany, same for evince
<seb128> that's pretty standard GNOME behaviour
<seb128> why "ugh"?
<pitti> ogra: speaking of the screen saver, would it be possible to not activate it after resuming from sleep?
<pitti> ogra: it doesn't lock the display anyway, so no point
<azeem> seb128: I see the point for evince (doing pdf presentations e.g.), but not for the terminal, but that is besides the point anyway
<azeem> the question is rather: Does the window content change?
* HiddenWolf cries out: "but where do I file the bug!"
<azeem> if I sit before a terminal and watch a compile pass by, I'd be annoyed when the screensaver kicks in
<ogra> pitti, we had a discussion in hoary that resulted in the locking ...
<azeem> if I just leave a blinking prompt, no problem
<ogra> pitti, not sure if we should change behavior here
<seb128> azeem: the screensaver has no information like "the window details are changing"
<ogra> pitti, i'd rather have it locking 
<pitti> ogra: it should either lock or not start the saver at all, but right now it's quite pointless IMHO
<seb128> azeem: that's why the app speaks by dbus to it
<pitti> ogra: can this be configured then? I'm quite annoyed of locked screens if I didn't ask for it, and if I want to lock, I can do that explicitly
<ogra> pitti, yes, i'll look at it ... i'd like to keep the behavior we had in breezy and before for this ... users will expect it to behave the same
<pitti> ogra: full ack
<Mithrandir> I think we should have something so a window can say "I have activity in me", whether it be a movie player, a phone application or something else.  And in addition, you'd want to monitor keyboard and mouse, possibly others as well
<ogra> pitti, can you check if "require password" is set for you in g-p-m's gconf settings ? 
<seb128> Mithrandir: there is a dbus interface to say "hang on, I don't want you to standy anything"
<seb128> standby anything
<pitti> ogra: in some minutes, I'm just booting the live cd
<seb128> Mithrandir: that's what totem does by example
<ogra> oki
<pitti> ogra: but actually, yes, I'll check in in the live as well; I might have changed the configuration in my ~
<azeem> are libnotify events propagated to the screenserver, so people see (through a blinking icon in a corner, perhaps) that there is something they possibly want to tend to?
<Mithrandir> seb128: that requires a lot of applications to use dbus.
<ogra> pitti, thanks
<seb128> Mithrandir: what other way would you like to use? setting a wm property and making apps using it?
<Mithrandir> seb128: something like that.  LAST_ACTIVITY or something.
<ogra> seb128, yes
<Mithrandir> which is a timestamp.
<seb128> that would work fine yep
<infinity> Someone may want to ping daniels. About 3 months ago, he hacked mplayer, xscreensaver, and some other stuff to do a root window hack to record when the screensaver should and shouldn't come on.
<infinity> And then never uploaded it.
<infinity> Adapting the patch to gnome-screensaver would be trivial.
<seb128> ah, nice
<ogra> cool
* dholbach hugs daniels
<Mithrandir> I'm wondering if it should be per-window or not.
<seb128> no need
<infinity> Mithrandir: It's a root ewindow property that records the window ID of the window that doesn't want to be saved.
<Mithrandir> no, I can't see a need either.
<infinity> Mithrandir: So when the screensaver checks to see if it should come on, it reads the root hint, checks to see if the listed windows still exist (this saved you from crashing mplayers), then acts accordingly.
<Mithrandir> infinity: I was thinking of changing it slightly so you'd just touch a property which counted as activity in the eyes of the screensaver.
<infinity> Mithrandir: See the bit about crashing media players.
<infinity> Mithrandir: The property won't get unset in that case.
<Mithrandir> so?  It's a timestamp
<Mithrandir> so N seconds after your mplayer has crashed, the screensaver comes on.
<infinity> A timestamp that you update every few seconds/minutes while playing a movie?  Fragile.
<Mithrandir> (since it's no longer being updated)
<Mithrandir> what's fragile about that?
<infinity> How often do you update it?
<infinity> Each application would have its own idea of what's appropriate, and each user (like freaks who set their screensaver to come on in 60 seconds.. <stare>) would have their own idea.
<Mithrandir> every ten seconds?
<azeem> infinity: you would query screensaver about its timeout value, and then choose something smaller ;)
* Mithrandir bats his eyelashes.
<infinity> The other way (set it once, unset it when you're done) works better, IMO.
<Mithrandir> how do you support multiple applications which may or may not want the screensaver to come on?
<Mithrandir> like, ekiga.
<infinity> I'm not sure I understand the question.
<infinity> You mave multiple applications open, they've all added their window IDs to the root hint.
<Mithrandir> I'd like the screensaver not to go on while I'm talking on the phone, even though I'm not pounding the keyboard.
<infinity> They remove their IDs one by one as they decide they don't want to interrupt the screensaver anymore.
<Mithrandir> how do you prevent the race condition therein?
<Mithrandir> (since afaik X properties are get + set, not "change"?)
<infinity> get+set is only a theoretical race in my world.  Unless you can start two movies and a phone in a few thousand CPU cycles.
<infinity> You click faster than I do.
<Mithrandir> I run remote X apps once in a while
<pitti> ogra: bah, g-p-m is not installed on the latest ppc live that I have :(
<infinity> Still not seeing the issue.
<Mithrandir> get + set can then take a lot more time.
<infinity> Remote apps set the root window hint on your local root... Which your (local or remote) screensaver will check.
<Mithrandir> sure
<infinity> Oh, I suppose it can take more time, but not so much.
* infinity shrugs.
<Mithrandir> but the race widens
<ogra> pitti, it went into -desktop very recently 
<infinity> Anyhow, I suggest one of the desktop guys ping daniels about his patches, and go from there.  My only interest was in having mplayer and xine not be retarded about screensavers.
<Mithrandir> I just think the "update timestamp" to simulate activity is prettier.
<pitti> Mithrandir: hm, we *could* not show the 'and enter your password' bit if / is a unionfs
<infinity> (They do hackish things like simulate keystrokes to fake out the swcreensaver which seems to not work reliably)
<Mithrandir> pitti: ewwwwww
<ogra> guys, please dont discuss such features if youre not willing to implement it :P i'm swamped in ltsp work ...
<pitti> Mithrandir: tell me something better :)
<infinity> ogra: The one daniels wrote is implemented, just that the code isn't in the archive.  Like I said, ping him (or get seb or dholbach to)
<ogra> ...and edubuntu ... and g-p-m
<pitti> Mithrandir: alternatively we just drop the 'and enter your password' completely
* infinity heads to bed... Finally.
<pitti> Mithrandir: we'll have a manpage soon anyway
<ogra> infinity, its a hack for xscreensaver which we dont use anymore
<dholbach> infinity: good night.
<pitti> sleep well infinity 
<ogra> will surely need a lot adjustment
<ogra> night infinity 
<mvo> night infinity
<Mithrandir> pitti: I'm going to fix it to just work correctly, I think.
<infinity> ogra: The hack will port easily, I'm sure.  If not, send it to me.  I just don't have his patches in front of me.
<ogra> oki
<pitti> Mithrandir: fix what?
<Mithrandir> pitti: actually, is there any reason why gss can't query pam whether "" as its password would succeed and if so DTRT?
<pitti> Mithrandir: erm, I'm speaking about the sudo message, not gss
<pitti> yes, g-s-s needs to be fixed differently
<Mithrandir> pitti: oh, yes, just drop the "and enter your password" since the user should be able to understand what "password" means in that context anyway.
<pitti> true
<Keybuk> before my amd64 committed hari-kari, I discovered that Windows takes just 2s to boot on it ... damn we have some work to do
<ogra> go ahead :)
<pitti> ogra: I can't find an appropriate gconf key that contols the locking after suspend
<pitti> Keybuk: you mean 2 s until the login screen appears?
<pitti> Keybuk: wow, I saw it boot in some 20 seconds on older boxes, but 2 s is indeed impressive
<pitti> To run a command as administrator (user "root"), use "sudo <command>."
<pitti> See "man ubuntu_root" for details.
<pitti> ^folks, that should be better than the previous help text. any ideas for further improvements?
<pitti> maybe s/details/help/
<ogra> pitti, its in /apps/gnome-power-manager/general
<Keybuk> pitti: no, 2s until desktop
<Kamion> not "ubuntu_root", I don't fancy branding that for kubuntu/edubuntu
<pitti> Keybuk: boggle
<Keybuk> it'd been pre-setup to login automatically I think
<pitti> Kamion: sudo_root?
<ogra> pitti, called require_password
<Kamion> pitti: better, certainly
<pitti> ogra: ENOSUCHKEY
<ogra> uh ? 
<ogra> hmm
<infinity> Keybuk: That's a heack of a lot faster than Zofia's XP installation.  And your machine can't be THAT much faster.  Does it have everything under the sun disabled?
<Keybuk> infinity: no idea, sadly everything is kinda disabled by the coolant system leaking ;)
<Keybuk> I'll tell you when I get the replacement <g.
<ogra> infinity, fresh installs of XP are that fast ...
<ogra> if you installed the first app on it it slows down like hell
<pitti> well, they rather boot everything non-essential in the background, right?
<infinity> ogra: Oh, I know they're fast (and hers is ripe and due for a rebuild), but I've never seen 2 seconds to desktop.
<freeflying> sorry for bother you , https://launchpad.net/malone/bugs/5981 still need be solved 
<ogra> i cant remember my last *fresh* XP ...
<Ubugtu> malone bug 5981 in openoffice.org2 "OOo crashes when input chinese" [Normal,Unconfirmed]  
* pitti never had anything newer than 3.11...
<ogra> but my GFs XP boots slower than breezy here
<infinity> pitti: Most of the services they can get away with starting late, they do, but there's still a fair few things to bring up before GINA (the security subsystem, ie: "the login box") can kick in.
<infinity> They also seem to pull some tricks to reduce I/O bandwidth to anything started in the background.
<HiddenWolf> ogra: my XP is faster than my dapper by a mile still.
<infinity> So they don't have the complete lack of responsiveness that we do when logging in with the world eating our disks in the background.
<HiddenWolf> ogra: that said, it's not much used.
<infinity> (takes longer for it all to start, but feels snappier while it's doing so)
<ogra> HiddenWolf, my GF has a hell lot of stuff installed ...
<tseng> ogra: are you talking from boot to login, or boot to desktop
<tseng> most of the end-user crap starts after login
<tseng> and why oh why would compaq make laptop keyboards where Ctrl is smaller than a letter key
<ogra> tseng, boot to login
<ogra> she has no autologin enabled
<tseng> boot to login on my canonical laptop is blazing fast with xp pro
<seb128> Keybuk: around?
<Keybuk> seb128: yup
<seb128> Keybuk: since today I've no DNS listed to /etc/resolv.conf on my box (using network-manager)
<seb128> what package is to blame?
<Keybuk> no DNS?  that's usually written by dhclient
<Keybuk> check you don't have resolvconf installed
<seb128> the file has 
<seb128> "# generated by NetworkManager, do not edit!"
<seb128> and nothing else
<Keybuk> yeah, nm likes to add that comment and lots of blank lines
<Keybuk> hmm
<Keybuk> I've disabled all that stuff in my package here, it doesn't seem to do anything for us
<seb128> un  resolvconf     <nant>       (aucune description n'est disponible)
<Keybuk> dhclient should be writing /etc/resolv.conf though
<Keybuk> check syslog
<jpatrick> mako: ping?
<jdub> seb128: whoa, that's a terrible bug
<seb128> I don't use a dhcp on that box usually
<seb128> I've a fixed IP list by /etc/network/interfaces and the DNS where written to /etc/resolv.conf
<seb128> s/where/were
<seb128> it seems that something destroy my "by hand made" resolv.conf, and I tend to blame network-manager since it put a comment to it
<Keybuk> oh, that's probably n-m destroying it then
<jdub> seb128: no, the bug with all that french output!
* seb128 slaps jdub
<mako> jpatrick: yes
<jpatrick> mako: it's about my membership
<Keybuk> n-m and static configuration don't appear to be friends
<seb128> Keybuk: and do you know about that?
<seb128> $ sudo /etc/init.d/networking restart
<seb128>  * Reconfiguring network interfaces... ifdown: failed to open statefile /var/run/network/ifstate: No such file or directory
<seb128> ifup: failed to open statefile /var/run/network/ifstate: No such file or directory
<Keybuk> huh?
<Keybuk> where's your ifstate file
<seb128> good question
<seb128> seems I've none
<Keybuk> was your card even ifup'd ?
<Keybuk> sounds like it wasn't
<seb128> eth1      Lien encap:Ethernet  HWaddr 00:40:05:5E:A8:68
<seb128>           inet adr:192.168.0.2  Bcast:192.168.0.255  Masque:255.255.255.0
<seb128>           adr inet6: fe80::240:5ff:fe5e:a868/64 Scope:Lien
<Keybuk> and sounds like n-m is playing the "do ifup/down's job for it" game
<Keybuk> ahh
<Keybuk> right
<seb128> and I'm IRCing from that computer
<Keybuk> so I know what's happening here
<Keybuk> 1) your card isn't being ifup'd during boot
<Keybuk> 2) n-m is bringing up your card by parsing /e/n/i (this code is being removed)
<Keybuk> 3) and stomping all over your resolv.conf
<Keybuk> and that's why ifdown is failing
<Keybuk> so ... paste your /e/n/i somewhere
<seb128> Keybuk: k, brb, just restarting to try something first
<zul> heylo
<Kamion> Kinnison: hooray for automatic d-i processing that worked
<mdz> pitti: how did the langpack update go?  everything OK with the new key authentication under launchpad?
<pitti> mdz: I just uploaded a couple of language-support packages
<mdz> pitti: oh, I see
<pitti> mdz: so, I don't know whether the langpack key is indeed still restricted to language-* packages
<mdz> pitti: so those were just signed with your personal key
<pitti> mdz: no, they used the langpack builder key
<mdz> pitti: it's not restricted, but it should work
<mdz> pitti: please let me know when you test it
<mdz> pitti: oh?
<mdz> ok then
<mdz> so it works ;-)
<pitti> yes, I built them the usual way
<pitti> apparently :)
<pitti> mdz: I added some scim modules, so we now get OOTB input support for Asian languages
<pitti> mdz: hm, that might be worth to be noted on the release notes
<pitti> s/on/in/
<mdz> pitti: yes, please add it
<Riddell> mako: jpatrick is around if you are able to consider his ubuntu membership
<janimo> Kamion,  bug 30320 is similar to what I had in flight 3. I remember infinity fixed that shortly after I reported
<Ubugtu> malone bug 30320 in debian-installer "daily of Jan 27 does not install on hp nx8220" [Normal,Unconfirmed]  http://launchpad.net/bugs/30320
<seb128> Keybuk: http://ubuntu.pastebin.com/544975
<Kamion> Feb  2 16:20:57 debootstrap: Cannot find /lib/modules/2.6.15-14-386
<Kamion> probably just out-of-sync kernel modules or something
<Yagisan> pitti: which asian languages ? and do you have a link to an iso - I'd love to have decent support for all my gnome/kde/x11 apps
<Kamion> dunno though, Adam will have to look at it
<seb128> Keybuk: and when I start nm-applet I've no connexion picked, it should probably use the only available one rather than requiring me to click on it
<Keybuk> seb128: try "ifconfig eth1 down" ... then "ifup --allow-auto eth1" and see whether that works
<Keybuk> seb128: also check your eth1 is really eth1, and not eth0 suddenly :)
<pitti> Yagisan: we won't ship them on the CDs, they are just too big
<seb128> Keybuk: I've 2 card but the first one is broken (and the corresponding line is greyed)
<pitti> Yagisan: look at dapper-changes for the set of language-support packages I updated
<pitti> Yagisan: or the last bzr commit in langpack-o-matic :)
<Yagisan> pitti: :'( not on cd
<seb128> Keybuk: 
<seb128> $ sudo ifup --allow=auto eth1
<seb128> ifup: failed to open statefile /var/run/network/ifstate: No such file or directory
<Keybuk> ok...
<Keybuk> seb128: sudo /etc/init.d/loopback start
<Keybuk> then try it
<seb128> $ sudo ifup --allow=auto eth1
<seb128> Error : Temporary failure in name resolution
<seb128> run-parts: /etc/network/if-up.d/ntpdate exited with return code 1
<seb128> 
<seb128> that works, eth1 is up/configured
<seb128> but something nuked the dns again :p
<seb128> (I've nm-applet running)
<torkel> nm-applet nukes resolv.conf
<Keybuk> right, yeah
<Keybuk> interesting that it didn't get configured during startup though
<seb128> yeah, I wonder why
<Keybuk> you have /etc/udev/rules.d/85-ifupdown.rules ?
<seb128> yep
<seb128> http://ubuntu.pastebin.com/544985
* jdub blinks
<jdub> oh yeah, *.pastebin.com
<Keybuk> is that space really there?
<fabbione> mdz, Kamion: ping?
<mdz> ?
<seb128> Keybuk: no, it's a copy error from the command line
<fabbione> mdz: i need a permanent UVF exception for redhat-cluster-suite (same as we did for breezy)
<mdz> fabbione: why?
<fabbione> mdz: i am pulling changes only from their STABLE CVS branch.
<Keybuk> seb128: ok ... I'd guess it's just n-m fucking up
<Keybuk> but still no idea why you're missing ifstate
<Keybuk> you have /etc/rcS.d/S08loopback ?
<fabbione> mdz: basically importing the fixes in debian/patches or making a new CVS snapshot is the same.
<fabbione> mdz: the latter is easier for me
<fabbione> mdz: and it has the same result
<seb128> Keybuk: yep, and lo is correctly set up on boot
<fabbione> mdz: it's purely cosmetic in the package version
<mdz> fabbione: sure, but you can always ask
<fabbione> mdz: sure. if there is something more than bugfixes i will notify
<fabbione> mdz: but on the stable branch is RARE
<seb128> Keybuk: should I file a bug about the resolv.conf issue?
<Keybuk> seb128: *boggle* how can you have lo but not /var/run/network -- they're made in the same script!
<Keybuk> seb128: sure
<torkel> seb128: I think it is already filed
<seb128> that I'm wondering
<seb128> Keybuk: I don't reproduce the ifstate bug now
<seb128> Keybuk: but the dns screwage is easy, drop the nm-applet comment line, and pick you static eth interface from the applet
<seb128> it overwrites /etc/resolv.conf with its comment
<seb128> (and some extra blank lines after that)
<seb128> and it doesn't update ifstate, which makes that too:
<seb128> $ sudo /etc/init.d/networking restart
<seb128>  * Reconfiguring network interfaces... SIOCADDRT: File exists
<seb128> Failed to bring up eth1.
<seb128> $ cat /var/run/network/ifstate
<seb128> lo=lo
<seb128> $
<Keybuk> *blink*
<Keybuk> see, you're still not getting eth1 coming up on boot!
<Kinnison> Kamion: rock on
<seb128> Keybuk: that's right, and I wonder why
<seb128> but that's a different issue of the ifstatus missing I had before
<Keybuk> indeed
<Keybuk> curious
<seb128> eth1 is listed by ifconfig in fact
<seb128> it's just not configured
<Keybuk> can you try booting without logging in to X for me?
<Keybuk> and IRC from a vt
<seb128> sure
<seb128> Keybuk: k, I'm not logged in
<Keybuk> seb128: ok, can you cat /var/run/network/ifstate now for me?
<seb128> lo=lo
<Keybuk> ok, and ifconfig says that eth1 isn't up?
<seb128> ifconfig lists it but with no IP
<seb128> ie: it's up but not configured
<Keybuk> it's UP?
<seb128> ifconfig
<seb128> ...
<seb128> eth1 .. blabla
<seb128> ie: it's listed
<Keybuk> uh, the blah blah is a bit important
<seb128> Link encap...
<seb128> UP BROADCAST...
<Keybuk> *sigh*
<seb128> no inet line
<Keybuk> lazy frelling germans :p
<Keybuk> TYPE IT ALL :)
<ogra> hey
<seb128> hum, brb, I'll IRC from an another box and ssh, it's faster :)
<Keybuk> hehe
<ogra> :)
<ogra> doko, !
<ogra> doko, any news about schooltool ? did you talk to jinty ? i'd really love to unbreak the edubuntu CDs ...
<seb128> ok, now I'm on the laptop
<seb128> so
<seb128> ifstate:
<seb128> lo=lo
<seb128> ifconfig:
<seb128> eth1   Link encap:Ethernet HWaddr 00:40:....
<seb128> inet6 addr: .....
<seb128> (ups, there is an inet6)
<Keybuk> could you not just paste the entire output please? :p
<seb128> UP BROADCAST RUNNING MULTICAST MTU: 1500 Metric: 1
<seb128> I've no network on the box
<seb128> I've to configure eth1 to do that :p
<Keybuk> heh
<Keybuk> right, so what's the full hwaddr ?
<seb128> 00:40:05:5E:A8:68
<seb128> if you want the full ifconfig I can put that to a file, configure eth1, copy it and reboot to have a clean state again
<Keybuk> no, is ok
<Keybuk> 004005       Ani Communications Inc.
<Keybuk> does that sound right?  (never heard of them)
<Keybuk> what's the mac address of eth0?
<seb128> the card is a RealTek RTL-8029
<seb128> 00:11:09:2D:23:BF
<Keybuk> k...
<Keybuk> do you have /sys/class/net/eth1 ?
<seb128> yep
<seb128> device/device in it says 0x8029
<Keybuk> cat /sys/class/eth1/device/modalias
<Keybuk> (and yes, you'll have to type it all <g>
<seb128> pci:v000010ECd00008029sv000010ECsd00008029bc02sc00i00
<Keybuk> ok ...
<Keybuk> you have both 8390 and ne2k-pci loaded? (lsmod)
<seb128> correct
<seb128> ne2k_pci   11872  0
<Keybuk> ok ...
<Keybuk> ifconfig eth1 down
<Keybuk> then udevplug /class/net/eth1
<seb128> 8390   11648 1 ne2k_pic
<seb128> it's up and configure now
<seb128> inet addr: 192.168.0.2 Bcast:192.168.0.255 Mask:255.255.255.0
<Keybuk> is /etc/resolv.conf right?
<seb128> yep but it was not in a state likely to be destroyed
<seb128> ie: I've put the DNS manually after the nm comment
<Keybuk> how do you mean?
<seb128> I can retry without the nm comment :)
<Keybuk> hmm
<Keybuk> try rebooting now, see if it comes up on its own this time
<seb128> rebooting
<dholbach> mdz: thanks for the UVF processing.
<seb128> Keybuk:  back to initial situation
<seb128> ifstate: lo=lo
<Keybuk> seb128: buggered if I know I'm afraid
<seb128> no inet addr for eth1
<pitti> mdz: I'd be glad if you could take a look at http://people.ubuntu.com/~pitti/tmp/sudo_root.8
<Keybuk> at this point I'd suggest booting init=/bin/sh, doing the initial bits of the boot by hand, and then making sure udevplug does /sys/class/net/eth1
<Keybuk> or if udevplug doesn't, that at least udevd does
<seb128> ifconfig eth1 down && ifconfig eth1 up  doesn't change anything
<mdz> pitti: s/less questions/fewer questions/
<seb128> hum
<pitti> mdz: reload please, I fixed some \- quotings
<Keybuk> seb128: ifconfig eth1 down && ifup eth1 will though, right?
<seb128> it doesn't set an IP no
<seb128> oh
<seb128> ifup
<Keybuk> seb128: try adding || true onto the end of the ntpdate call in /etc/network/if-up.d
<seb128> lemme try
<Keybuk> see if that helps
<seb128> rebooting
<seb128> eth1 is correctly configured after an "/etc/init.d/udev restart"
<Keybuk> yeah, that's what makes no sense
<Keybuk> makes it sound like it's not getting the uevent during boot
<pitti> mdz: do you think the general verbosity and scope is right?
<Keybuk> did the || true on its own help?
<seb128> Keybuk: interesting, something breaks it
<Keybuk> seb128: "something breaks it" ?
<ogra> gremlins :)
<seb128> sec
<seb128> I got the "disk mounted n time ..." on boot
<seb128> did ctrl-C
<seb128> and tried from there
<seb128> eth0 was not up
<seb128> and eth1 was up with the correct IP
<Keybuk> with just the ntpdate fix?
<Keybuk> or something else changed?
<seb128> after pressing ctrl-D and continuing the boot it's broken again
<Keybuk> "broken again" ?
<seb128> eth1 no IP
<Keybuk> ok ... try just booting into single user mode
<seb128> eth0 up
<seb128> so a script is breaking it between the disk prompt and the login prompt
<seb128> yeah, doing that
<Keybuk> I bet it's NetworkManager starting up and tearing down the interfaces
<Keybuk> though what happens to ifstate, I've no idea
<mdz> pitti: I suggest referring to the wiki for more information
<pitti> mdz: ok, I'll add a SEE ALSO
<mdz> pitti: I also question the recommendation to use 'tee' since it does not have the same behaviour as >
<mdz> pitti: cat /dev/kmem > foo and cat /dev/kmem | tee foo are not quite equivalent ;-)
<pitti> heh, true :)
<mdz> pitti: I'd omit the "unless cracked" comment
<pitti> so, some >/dev/null bits shoudl be added
<mdke> me too, "cracked" is a difficult word to understand
<mdz> pitti: s/the installer has to/the installer is able to/
<seb128> Keybuk: network is fine in single user mode
<Keybuk> seb128: with eth1 in ifstate?
<seb128> lo=lo
<seb128> no eth1
<Keybuk> that's weird
<seb128> it as an inet addr
<Keybuk> did you have "|| true" in the ntpdate script?
<seb128> yep
<pitti> mdz: ok, reload please
<pitti> now for real
<Keybuk> I suspect if you step through each rc2.d init script, you'll find it S12dbus that brings it down
<mdz> pitti: s/setup with/set up with/
<seb128> how do I step?
<Keybuk> cd /etc/rc2.d; ls; ./S05vbesave start; ./S10acpid start; ...
<seb128> oh, step from here?
<Keybuk> aye
<pitti> mdz: I also fixed that 'setup' in the first paragraph
<Keybuk> by hand
<mdz> pitti: looks good now
<pitti> mdz: thanks for the review; I'll stuff that into sudo and also update the bash text
<pitti> mdz: 
<pitti> To run a command as administrator (user "root"), use "sudo <command>."
<pitti> See "man sudo_root" for details.
<seb128> Keybuk: right, after running dbus start eth0 is up and eth1 is unconfigured
<pitti> mdz: ^ less technical than the previous version
<Keybuk> pitti: "sudo <command>".
<Keybuk> pitti: otherwise you make it look like "." is part of what you have to run
<bradb> Hey dudes, I have another Malone UI prototype to show you: a new advanced search (the "Advanced Search coming soon" bit on the +packagebugs report.) I was hoping for some developer feedback before proceeding.
<pitti> whoops, right
<seb128> bradb: shoot
<bradb> coming up in one sec...
<bradb> http://flickr.com/photos/84096161@N00/97183390/
<seb128> starts looking like bugzilla :)
<bradb> I think we can make it look a lot less "zilla" if we're persistent though.
<seb128> bradb: still missing one of the most useful feature "search to comments too"
<ogra> SHINY !
<seb128> bradb: zilla is nice :)
<Diziet> Damn, I forgot -sa again.  Oh well.
<bradb> seb128: Yeah, searching comments is a limitation that I don't know that I can currently overcome. But I have to revisit the issue with stub.
<bradb> We have to make it happen soon enough.
<seb128> bradb: other way it looks great
<ogra> Diziet, at least we'll know who broke soyuz :P
<seb128> bradb: though it doesn't make obvious to know if searching or "a word" does a and or or of the words used
<bradb> seb128: true
<ed1t> does anybody know where does all the startup programs list is stored in?
<seb128> Keybuk: if I uninstall network-manager my eth1 is configured correctly (but still not listed by ifstate)
<Keybuk> seb128: if you ifconfig eth1 down and ifup eth1, is it in ifstate?
<ed1t> coz i got devilspie at order 1 on startup and now ubuntu wont load after login screen
<seb128> Keybuk: yep, eth1=eth1 now
<Keybuk> seb128: kooky
<seb128> ed1t: ~/.gnome/session-manual or something like that
<jbailey> Who was it who agreed to do the X stuff?
<bradb> seb128: Can you think of any other important search options it's missing?
<HiddenWolf> ed1t: try order 50 or so. stay away from lower orders, since that's when gnome starts up.
<Keybuk> jbailey: you did
<seb128> jbailey: you
<dholbach> Keybuk: Yeah, I remember that too.
<jbailey> Oh joy.
<dholbach> seb128: will you forward the bugs to jbailey then?
<ed1t> HiddenWolf yea i put 1 for devilspie and i think thats the reason why its not loading gnome anymore
<jbailey> seb128: We'll trade.  You take glibc, I take X?
<seb128> dholbach: just reassign to him :)
<dholbach> seb128: yeah.
<seb128> jbailey: why do you want to trade with me? trade with dholbach!
<jbailey> seb128: You're the one who maintains everything starting with g.
<dholbach> jbailey: you wouldn't want that.
<jbailey> dholbach: You're right that I truly wouldn't. =)
<dholbach> :-)
<seb128> jbailey: my first action will be to rename it "libc6" so :p
<jbailey> Ahahah
<jbailey> But.. But..  think of all the poor ia64 users!
<Keybuk> what, both of them?
<seb128> ok ok, you can keep glibc
<seb128> dholbach can do xorg
<jbailey> Keybuk: No, just the one.  The other one got a faster computer. =)
<seb128> bradb: how do I specify if I want to search on upstream or dapper or ... bugs?
<seb128> Keybuk: anything else you want to try about that network issue?
<bradb> seb128: There's the "Upstream Status" field which allows a kind of upstream searching. And there's the milestone search field. Do you mean wanting to find backport/security bugs? (That'd be something different, not on the new search UI.)
<ProN00b> why won't ubuntu get the new firefox ?
<Keybuk> seb128: not at this moment
<Keybuk> seb128: can't think of anything else
<Keybuk> if you can strace it and stuff and figure out why ifstate isn't updated at boot that'd be nice
<ProN00b> since you don't seem to be writing security patches for 1.0.7
<seb128> Keybuk: who is supposed to update it on boot?
<ProN00b> the only choice is to get 1.5.0.1 out as a security update
<ProN00b> why don't you
<ProN00b> ?
<pitti> ProN00b: we'll upgrade to 1.0.8 as soon as it's oit
<pitti> out, even
<seb128> bradb: what is the milestone again? "this bug is to fix for ..."
<Keybuk> seb128: ifup is
<Keybuk> run from the udev rules
<ProN00b> think more practical, and less close minded uh noes updating is bad for stable
<pitti> ProN00b: and 1.5.0.1 for dapper is in preparation
<seb128> bradb: like "milestone dapper" is what I want to fix for dapper?
<Keybuk> and it locks the file and stuff to prevent concurrent writes
<ProN00b> pitti, 1.0.8 ? whats that suposed to be ?
<bradb> seb128: Yeah, milestones are forward-looking targets.
<pitti> ProN00b: well, the next version after 1.0.7?
<bradb> Clearly "Milestone" is not a good word to describe this.
<ProN00b> -_-
<seb128> bradb: I may have some breezy bugs open because I want to backport some patches there, how do I find them?
<ProN00b> pitti, why not accept release versions as release versions ?
<seb128> is that a milestone?
<ProN00b> i mean they are not your release versions, but certainly the ones of the firefox team
<dholbach> ProN00b: You might consider that people have given this a thought before accusing them as "close minded".
<bradb> seb128: That's not possible in either the current, or the new UI, but I can add that in the new UI.
<seb128> bradb: BTW why did you put a binary package field? I hate that, when I change the source package to reassign a bug most of the time I forget to update the binary
<seb128> that requires extra step
<seb128> is useless and confusing
<pitti> ProN00b: upstream announced it for next week
<pitti> ProN00b: I don't understand what you mean
<bradb> seb128: Because many users don't know the difference between binary and source package, so they file the bug on whatever's in their head.
<bradb> So the bug filing form figures out what they mean.
<ProN00b> dholbach, no, and even if they ran this choice through their stupid distribution ruleset in their mind, the choice of not putting firefox releases even in the security patches is the wrong choice if it contains security fixes
<mdke> bradb, why is the distinction made at all in malone?
<ProN00b> pitti, another thing is that i don't want to install a "new os" everytime you update the versions
<pitti> ProN00b: hmmmmmmmmmmmm? You are sounding seriously confusing now
<dholbach> ProN00b: Try to do this discussion in a calm way or stop it.
<bradb> mdke: So that people who report a bug on foo-doc can see that a bug was reported on foo-doc. Instead of reporting it on foo-doc, and seeing just one package value saying "foo".
<seb128> bradb: you should have only one field that accept both so and convert that to the source package
<pitti> ProN00b: so, we will put 1.0.8 as security updates into warty/hoary/breezy and update dapper to 1.5.0.1
<pitti> ProN00b: do you see anything problematic in that appraoch?
<seb128> bradb: reporting on nautilus-data should assign the bug to nautilus in a transparant way for user
<bradb> seb128: We do that already, it's just that we also populate and show the binary package. I could remove the bin package easily enough.
<seb128> that would be nice
<mdke> bradb, why not just have them file bugs on foo in the first place?
<seb128> because as say people open a bug on gnome-panel gnome-panel by example
<ProN00b> yeah, because 1.0.8 will just be open to less vulns than 1.0.7 but there are still alot in it, which are fixed in 1.5.0.1, pitti 
<seb128> if I want to reassign to GTK I've to update 2 fields now
<bradb> mdke: Because a lot of users have no idea about bin package vs. source package
<seb128> you add extra step for daily work
<mjg59> ProN00b: Do you have any evidence for that?
<seb128> like we had not enough already ;p
<pitti> ProN00b: if that is the case, then these vulns are at least not documented
<bradb> mdke: A lot of people were complaining that they couldn't file bugs on something, because it turned out they were trying to specify the binary package name, not the source package name.
<pitti> ProN00b: right now it's the other way round: only 3 of the 10 or so vulns that affect 1.5.0 affect 1.0, too
<ProN00b> pitti, mjg59 is 1.0.8 your own bug fix version of 1.0.7 ?
<pitti> ProN00b: no, I'm waiting for upstream's
<mdke> bradb, ok, i'm starting to understand. I kinda thought there might be an easy way to have both source and binary names pointing at the same thing
<pitti> ProN00b: we already tried bakcporting firefox patches in the past, and it caused nothign but trouble
<ProN00b> pitti, the obiously best solution is to just use the newest firefox version if there are any bug fixes apearing in its changelog, this would also be what the user wants, don't you see it ?
<ProN00b> isn't ubuntu meant to be a os for humans ?
<pitti> ProN00b: that's what we are going to do
<mjg59> ProN00b: Users who are running stable releases of operating systems do not want security fixes to be accompanied by extra features
<pitti> upgrade stables to 1.0.8 as soon as it's out
<mjg59> (And extra bugs, and extra crashes, and so on)
<pitti> oh, you meant it *that* way; right, as mjg59 says
<seb128> bradb: that should really be one field accepting both source/binary packages
<mjg59> ProN00b: So for versions of Ubuntu that ship with Firefox 1.0.7, we'll ship 1.0.8. For those that have 1.5.0, we'll ship 1.5.0.1 (or whatever)
<ProN00b> mjg59, oh noes, damn, those evil features and potential bugs might get me if i want to protect myself from the nice little small known vulns in 1.0.7
<bradb> seb128: On the bug form, it already is. But on the +editstatus page, it's a little trickier.
<ProN00b> 1.0.7 known vulns
<ProN00b> 1.5.0.1 no known vulns
<ProN00b> ubuntu version: 1.0.7
<mdke> ProN00b, they have explained very patiently to you that security vulnerabilities are addressed in each version where they appear
<bradb> seb128: Admittedly, the person setting it on +editstatus will hopefully understand why, if they specify a binary package name, it gets auto-converted to the source package name.
<pitti> ProN00b: the vulns will be fixed 1.0.8, which is in preparation; we can't be even faster than upstream 
<bradb> So maybe we can tune +editstatus to keep it just one field there too.
<pitti> ProN00b: 1.5.0.1: lots of unknown new vulns introduced in 1.5
<seb128> bradb: that's the editstatus page which bother me, it forces me to update 2 fields instead of 1, so it slow me down when reassigning a bug
<ProN00b> pitti, lots of known vulns in 1.0.7
<tseng> 1.5 also changes the api, and means all the apps using gecko would be rebuilt
<bradb> seb128: Yeah, I definitely see what you mean.
<ProN00b> pitti, whats better, unknown or known vulns ?
<tseng> so its not as simple an issue as you seem to think it is
<pitti> ProN00b: known ones
<ogra> ProN00b, you dont get the point ...
<seb128> bradb: to come back to the new mockup for bug query, I think it's great :)
<seb128> bradb: with an option to using comments too it would totally rock :)
<ogra> ProN00b, mozilla announced to release 1.0.8 soon ... we'll ship it and close the vulns 
<ogra> thats it 
<Kamion> ProN00b: upgrading to 1.5 in dapper was a complex upgrade involving many other packages, and there was lots of breakage in dapper when it was only half-done
<bradb> seb128: cool. I'm tweaking it now for release targets vs. backport fixes. Comments'll definitely be trickier. :P
<Kamion> ProN00b: our considered opinion is that it's not suitable to backport it to a stable release that currently has the 1.0.x series
<bradb> Though that would clearly rock to get working.
<pitti> 1.0.8 is prepared and in QA; let upstream do their job
<ProN00b> -_- Kamion i can't believe that, how can it break other packages ?
<pitti> ProN00b: it's called 'API'
<Kamion> ProN00b: have a look at all the other packages that have tight versioned dependencies on firefox
<Kamion> firefox locales and the packages that embed gecko
<pitti> ProN00b: lots and lots of packages use libnspr, libnss, and some even use the whole mozilla API
<pitti> ProN00b: not to mention the countless translation packages and such
<Kamion> also firefox extensions
<mdke> examples are yelp (gnome help), add applications, epiphany
<xhaker> quick question: why are there missing icons?
<ProN00b> pitti, Kamion sounds like dll hell to me...
<dholbach> xhaker: you mean on the gnome desktop?
<Kamion> ProN00b: DLL hell is when you can't spot the problems as a user until stuff crashes; in this case you can spot the problems because the package manager will prevent you from installing the packages
<xhaker> i noticed on gdm options menu.. and some stock icons i used in gtkwifi are now missing too
<Kamion> mdz: good news is that I've implemented parallel install/live CD builds
<Kamion> mdz: bad news is that it doesn't appear to save any time, presumably due to insufficient I/O bandwidth on little as elmo suggested
<dholbach> xhaker: gnome-icon-theme uses icon-naming-utils now - it's a transition, which causes minor breakages.
<Kamion> it's about 20 minutes either way
<seb128> Keybuk: S35mountall breaks the ifstate eth1=eth1
<seb128> Keybuk: I don't know why though
<xhaker> dholbach: are you sure /usr/share/icons/hicolor/16x16/stock/data/stock_lock.png i.e. will be back?
<Keybuk> mehan?
<Keybuk> paste your /etc/fstab somewhere
<dholbach> xhaker: it's not filed as a bug yet.
<xhaker> dholbach: i better update my icon dirs on the app
<xhaker> thanks for the info
<dholbach> xhaker: I'll talk to upstream about this one.
<Keybuk> that'd be a cute race ... if ifup finished about the same time that /var was moved out of the way
<seb128> xhaker: no, it'll not be back
<Keybuk> but that's suppppposed to be impossible
<dholbach> xhaker: Upstream says that it won't be installed to hicolor again - that was a 'mistake'.
<xhaker> seb128: i understood that after i slocated the icon and noticed they go on different dirs now
<seb128> Keybuk: a min, putting the concerned box in a state where I can copy fstab without having to typing the whole of it :)
<jdub> BenC: ping
<dholbach> xhaker: did you have a hardcoded path?
<seb128> dholbach: the issue is if you use a theme which doesn't Inherit from gnome
<seb128> hicolor is always used
<seb128> which is not the case of gnome
<xhaker> dholbach: yes i did.. i don't think there is another option
<xhaker> dholbach: is there any api function to get the lock icon from the current icon theme?
* xhaker dogfooding
<stewart> Hi Im just playing with dapper where has the multimedia selector gone
<xhaker> gstreamer-properties
<mdke> stewart, lots of menu items have been removed for simplicity
<seb128> "some" rather than "lot"
<seb128> "some" rather than "lots"
<ogra> Diziet, wow, your changelog is a book
<stewart> Im hoping to run my hauppage but cant find tv time in the repos our that nice little multimedia gui for testing
<stewart> are you guys ditching the gui gor multimedia for good?
<Amaranth> multimedia gui for testing?
<tseng> Filename: pool/universe/t/tvtime/tvtime_1.0.1-2ubuntu1_i386.deb
<tseng> its right ^ there
<stewart> yeah under hoary and breezy there was a gui for changing and testing your multimedia (sound and video capture) etting
<stewart> in gnom system preferences
<Amaranth> should still be there
<xhaker> stewart is saying he misses gstreamer-properties menu item
<stewart> not under my flight 3 of dapper
<mjg59> stewart: In theory, it should all work automatically now
<stewart> mwhahaha
<mjg59> (And hasn't been ported to gstreamer0.10, so isn't visible by default)
<mjg59> If it's failing out of the box, then please file bugs
<stewart> thats OK makes it tricky to test that the TV card works without a tv app so I better get one
<mjg59> stewart: Heh
<stewart> any idea why tvtime doesnt show in my synaptic?
<xhaker> you need to enable universe.. do you know how to do it?
<stewart> yup
<Kinnison> Kamion: ping?
<Kamion> Kinnison: yes?
<Kinnison> Kamion: Can you please retry the queue command which resulted in 30827 and tell me if it's any better?
<Kamion> Kinnison: new and more exciting failure
<Kinnison> can you /msg me the traceback?
<stewart> an odd thing was that I had to sort an entry in my sudoers file to be able to run as root
<stewart> although I think thats a well known
<Kamion> Kinnison: https://chinstrap.ubuntu.com/~dsilvers/paste/fileqCjeZE.html
<Kamion> (sorry, was already in the process of pasting it)
<Kinnison> Kamion: oooh yummy
<stewart> and gedit seems to not run from sudo
<Kamion> stewart: you in the admin group?
<Kamion> if you installed your system fresh with warty, you won't be
<Kamion> if you installed fresh with >= hoary, you should be
<stewart> its a clean install of dapper
<stewart> used advanced install
<stewart> and created my user through the installer
<stewart> vim works just fine
<Kamion> what did you have to change in sudoers?
<pitti> stewart: sudo gedit works fine for me, although gksudo gedit is prefered
<stewart> just needed to add an entry for my user using  visudo
<Kinnison> Kamion: and now?
<pitti> stewart: there was no entry for %admin?
<stewart> root    ALL=(ALL) ALL
<stewart> stewart ALL=(ALL) ALL
<Kamion> Kinnison: https://chinstrap.ubuntu.com/~dsilvers/paste/fileIGSBf2.html
<stewart> the second I added
<Kamion> stewart: did you choose to set a root password in the installer?
<Kamion> using expert mode
<Kinnison> Kamion: Ohferchrisstsake
<stewart> yeah think so both user name and root pwd are the same though (stupid I know)
<Kinnison> Kamion: Okay, I need to get stub to do a grant
<Kinnison> Kamion: go me
<Kamion> stewart: in that case yes this is well-known
<stewart> thought so cool
<Kamion> currently we assume that if you set a root password then you want to use it
<Kamion> (instead of sudo)
<Kamion> we're hoping to sort this out much better upstream after d-i etch beta2 is released
<Kamion> and hopefully have time to sync that into dapper so that this stops being an issue
<Kamion> Kinnison: ok, thanks
<Kinnison> Kamion: sorry about this
<shaya> anyone having issues w/ /usr/share/autostart on dapper right now?
<stewart> Ive got a default sources.list has that not got multiverse enabled?
<thesaltydog> I was on #ubuntu, asking questions on network-manager not working... and I have got this answer:
<thesaltydog> <ydo> thesaltydog: then pay support or wait until april?
<thesaltydog> is it normal?
<Kamion> stewart: correct and deliberate
<Kamion> thesaltydog: that depends on how demanding you were being of the people volunteering help :)
<stewart> OK is it a probe to enable?
<stewart> problem
<thesaltydog> ok.. the logs are there.. No matter.
<Kamion> if you were being demanding, then I'm not too surprised; otherwise it may just have been somebody being unnecessarily hostile
<Kamion> either way, this is not an escalation channel for #ubuntu disputes
<Kamion> stewart: we decided long ago not to enable it by default (there's way too much dodgy stuff in multiverse that people with more-than-casual legal concerns may want to think about), but you can certainly enable it yourself if you like
<stewart> I just get error messages when I try and set mutiverse
<Kamion> "multiverse"
<stewart> Errhttp: dapper Release.gpg
<stewart>   Unable to connect to  http:
<Kamion> perhaps you could paste the exact line you have in sources.list for multiverse
<stewart> universe sorry
<Kamion> same question then
<stewart> by default I have these 2 
<stewart> deb http:///ubuntu/ dapper-backports main restricted universe multiverse
<stewart> deb-src http:///ubuntu/ dapper-backports main restricted universe multiverse
<Kinnison> Kamion: we can't progress this bug until the grant is done, I'll get back to you when it is ready 
<Kamion> stewart: you have no host in those URLs
<Keybuk> "///" ?
<Kamion> stewart: http://some.host.name/ubuntu/
<Kinnison> dapper backports?!
<Kamion> Kinnison: they *will* exist, so the installer sets up sources.list that way because it won't get a chance later
<Kinnison> Kamion: right
<Kamion> stewart: if that's what the installer gave you by default, I'd like a bug report against apt-setup with your /var/log/installer/syslog attached, please
<stewart> OK so why are the commented lines listed without machine/domains was it like that before?
<Kamion> note that you will need to use root privileges to read /var/log/installer/syslog
<stewart> I'll check my backup to make sure
<Kamion> oh, also /var/log/installer/cdebconf/questions.dat
<stewart> OK my bad
<stewart> originals are as youd expect
<stewart> deb http://security.ubuntu.com/ubuntu dapper-security main restricted
<stewart> I uncommented
<stewart> deb http:///ubuntu/ dapper universe
<stewart> which obviously as you point out has not machine/domain name doh
<stewart> are you putting the commented universe links in without machine names deliberately (for legal reasons)?
<Kamion> er, no
<Kamion> I'm extremely surprised that the commented versions differ, because the code generating them uses the same variable name
<Kamion> although security.ubuntu.com doesn't count, that's different code
<Kamion> 17:34 < Kamion> stewart: if that's what the installer gave you by default, I'd like a bug report against apt-setup with your /var/log/installer/syslog attached, please
<stewart> OK do you want me to attach the original sources.list_backup file
<stewart> run me through what you want and I'll send in
<Kamion> I want precisely what I asked for above :)
<Kamion> plus /var/log/installer/cdebconf/questions.dat
<Kamion> I guess your sources.list might be useful, just in case there's something odd in it, but it's not required; your summary of the problem is enough
<stewart> so a copy of the syslog
<stewart> questions.dat
<stewart> and original repos list?
<Kamion> yes, please
<stewart> sent where?
<Kamion> https://launchpad.net/distros/ubuntu/+source/apt-setup/+filebug
<stewart> grr firefox is hanging
<jdub> maswan: dude, you're on osnews :)
<Kamion> stewart: there is an e-mail interface if you need it
<stewart> its OK Im sorted now
<Kamion> ok, thanks
<mdke> jdub, have you got a minute?
<jdub> mdke: yo
<stewart> do you want me to paste those files intothe comments?
<mdke> jdub, *points at #ubuntu-doc*
<Kamion> stewart: no - file the bug, then you'll get an "Add Attachment" link or similar down the right-hand side
<stewart> cheers
<Kamion> stewart: (I've also filed https://launchpad.net/products/malone/+bug/30856 requesting that the bug tracker be improved with respect to filing bugs with attachments)
<Ubugtu> malone bug 30856 in malone "would like to be able to add attachment(s) while filing the bug" [Normal,Unconfirmed]  
<stewart> cool although the system dosent look bad
<stewart> a little counter intuative but functionaly good
<pitti> Diziet: no CVEs in firefox changelog? *sniff*
<Kamion> counterintuitiveness is good to fix too. :)
<Kamion> stewart: Feb  2 16:39:01 main-menu[2041] : WARNING **: Configuring 'choose-mirror' failed with error code 134 
<Kamion> stewart: that's "Aborted" - are you low on memory, or did you notice anything weird happening earlier on in the installation?
<Diziet> pitti: Ah, damn.
<Diziet> Sorry, I got distracted by everything else.
<pitti> Diziet: well, it won't be the last dapper upload I suppose :)
<Kamion> indeed, mirror/http/hostname is empty
<Diziet> I'll retrospectively include them in the next one.
<Mithrandir> Kamion: it's the same I saw in London, remember?
<pitti> Diziet: that's fine, thanks
<Kamion> Mithrandir: oh, good point
<Kamion> Feb  2 16:28:54 cdrom-detect: Detected CD 'Ubuntu 6.04 "Dapper Drake" - Alpha i386 (20060115)'
<Kamion> so ok, it's a choose-mirror crash due to a buggered templates file
<stewart> yeah I noticed that kam
<stewart> I think I didnt have the network up when installing
<stewart> it was clean intall from CD
<Kamion> yeah, choose-mirror is used to select the mirror that will be used anyway, though
<stewart> Im running 1GB mem
<Kamion> even if it's only the country default (as it is in most cases)
<Kamion> Mithrandir's right, it was the buggered choose-mirror debconf templates file that we fixed in London
<Kamion> (probably)
<Kamion> stewart: if you see it with a current CD image, though (from about today onwards), do file a bug
<stewart> I may have been up and down the install process (stage wise) a couple of times
<Kamion> er, reopen that bug
<Kamion> it's always worth checking these things out
<stewart> yup
<stewart> anything helps you guys make this is worth my time
<stewart> that said what i the machine name to universe :-)
<Diziet> Am I supposed to be able to see how my builds are coming along in soyuz ?  https://launchpad.net/distros/ubuntu/dapper/+source/firefox/1.5.dfsg+1.5.0.1-1ubuntu1 is rather gnomic.
<Diziet> (... try #launchpad says everyone)
<mjg59> ogra: The RSS screensavers don't appear in gnome-screensaver
<Kamion> hmm, theoretically yes, maybe it doesn't link the build logs to source packages until they complete or something?
<ogra> mjg59, known, i have bugs open about it 
<ogra> mjg59, screensavers need to have .desktop files to appear in g-s-s
<maswan> jdub: dude, neat!
<mjg59> ogra: They have .desktop files, they're just wrong
<mjg59> (for this purpose)
<Kamion> kind of a LACK OF SEARCHING on +builds
<ogra> i didnt look into rss-glx yet ... buit its on my list
<maswan> jdub: apparently, /. is more picky about what junk it posts. ;)
<mjg59> ogra: Cool, thanks
<jdub> maswan: haha
<Diziet> `No builds for firefox in Ubuntu Dapper.'
<Diziet> I'll try #launchpad and report back :-).
<dholbach> mdz, Kamion: I'd like to sync gutenprint from sid - they have a new release candidate (for gutenprint5), which (accord to the NEWS file) supports a 100 more printer models and fixes a bunch of other bugs - you want to have the ChangeLog diff?
<ogra> mjg59, electricsheep has the same prob
<Kamion> Diziet: eventually they should appear in the "Builds" portlet on the right-hand side, but that may not be until they're finished
<Diziet> Yes.
* sivang goes to try his luck with threading and python
<Kamion> dholbach: just looking through it now
<dholbach> Kamion: thanks a lot.
<Burgwork> sivang, ah. Is that the sign of hacking on a backup program?
<mjg59> ogra: Ah
<sivang> Burgwork: indeed :-D
<Burgwork> sivang, yay!
<stewart> I can say my bttv car did just work
<stewart> as did sound
<stewart> you guys are good
* sivang hopes he will make it in time to not disappoint Burgwork 
<Kamion> dholbach: yes, looks sane to me - mostly new printer support and some bug fixes, looks fairly safe
<Kamion> go ahead
<dholbach> Cool.
* dholbach hugs Kamion
<Burgwork> sivang, given my current lack of any Ubuntu work, I don't think I have a leg to stand on
<mdz> dholbach: yes, changelog please
<mdz> Diziet,Kamion: I think the build links appear as soon as they are pending
<Kamion> mdz: (I just looked at the gutenprint changelog myself)
<dracflamloc> hello. is there a channel for those running the test versions of ubuntu?
<Kamion> but doesn't do any harm to have an e-mail record I guess
<mdz> Kamion: that's fine then; I hadn't read far enough to see that yet
<dholbach> mdz, Kamion: if you want, I'll write a mail and include James in the conversation - that's no problem.
<Kamion> Diziet: it's got as far as listing them all as "Needs building" now
<Diziet> kamion: Oh, so it does.  Good :-).
<Diziet> I wonder why it waited.  `Date requested:  2006-02-08 18:29:02 UTC'
<Kamion> Diziet: I'm guessing, but I suspect that new build jobs are only fed to buildds when the publisher finishes, and it's a cron job that runs at :00 every hour and takes 20 minutes or so
<Kamion> :29 is a not-too-implausible time for that to kick off, I think
<elmo> it's publisher + sequencer and the sequencer scans every 10 mins I believe
<elmo> and as kamion said publisher is currently taking 20 mins
<Diziet> Ahhh.
<Diziet> Fair enough.
<LaserJock> elmo: did you get my irc message about removing ruby-gnuplot from universe?
<elmo> LaserJock: yes, I'll get to it when I can, I'm a little swamped atm
<LaserJock> elmo: np, I just wanted to make sure it was on the list ;-)
<Keybuk> seb128: ROFL
<Keybuk> do you know, that combination never occurred to me
<jag_fsf> howdy -- i'm jag, sysadmin for the fsf -- i need to pm with one of the ubuntu project folks if any of you are around...
<jag_fsf> mako? you here?
<jag_fsf> or jdub?
<Keybuk> jag_fsf: it's almost exactly the wrong time for everyone, it's either dinner or lunch time
<Keybuk> what's up?
<jag_fsf> can i pm?
<Keybuk> sure
<seb128> Keybuk: should I open a bug on initscripts assigned to you about the /tmp /var issue? :)
<Keybuk> sure thing
<mvo> elmo: the regression with --print-uris in apt you reported yesterday is fixed in my arch branch btw 
<Treenaks> On which package do I file a bug about interfaces/their #names?
<triceratops> I just see that gnome-session-properties uses /usr/share/autostart but not /home/user/.../autostart anymore. Thats _very_anoying due to the fact that now all this KDE stuff is started in a gnome session...
<Treenaks> BenC: (you might want to disable a debug message in sdhci: my log is being spammed now: [4297493.878000]  mmc2: DMA end
<Treenaks> BenC: (but sdhci now works!) (and smart batteries too!)
<triceratops> I noticed this as a problem when I started a gnome session and a lot of KDE apps where started. 
<seb128> triceratops: it has already been reported, use a stable version of Ubuntu if you don't want to face working branch stuff
<seb128> triceratops: complain if bugs beeing very annoying on that chan is of no use
<triceratops> seb128:  Im asking here to fizzle what app might be responsible for this, not for complaining. Asking such questions on #ubuntu will give no answer
<triceratops> seb128: You may have noticed that I always ask on #ubuntu first, and if I don't get an answer I repeat my questions here...
<seb128> triceratops: I'm not on #ubuntu
<seb128> there is already a malone bug from today about that, should be easy to spot before asking if you have a look :)
<seb128> and what to blame?
<seb128> KDE apps to not declaring to the .desktop that the stuff are KDE specific
<seb128> and gnome-session probably to no exclude KDE specific too (I had a quick look on that, if it's bugged I'll fix it tomorrow)
* mvo prepares for bedtime
<HiddenWolf> seb128: I guess some people might want /some/ kde stuff to start, if/when it's useful
* mvo makes the sign to protect against evil
<sivang> hehe
<seb128> HiddenWolf: they can save them to their session so
<triceratops> seb128: If it's easy to spot... So please tell me how to do so. Having a look at https://launchpad.net/distros/ubuntu/+milestone/dapper doesn't show this bug to me. 
<seb128> because it has no dapper milestone
<seb128> https://launchpad.net/distros/ubuntu/+bugs?field.searchtext=&orderby=-datecreated&search=Search
<seb128> 30849. Kde desktop applications started by gnome-session 
<seb128> that's middle of the page
<triceratops> Thak's a lot, noticed this for the future.
<seb128> np
<seb128> BTW when you want to ask where to report a bug or if it's already know
<seb128> no need to start by saying it's "_very_ anoying"
<seb128> that makes it look like some whining about stuff beeing worked
<seb128> the change has been made today, a bug has been opened, it's going to be worked and fixed ... that's how stuff work :)
<seb128> if you do hourly dist-upgrade you have to live with that sort of annoying cycle
<triceratops> seb128: OK, you are right. It was useless noise saying so.  But it was anoying... :-)) *grins*
<triceratops> seb128: But I think it might be interesting to have some kind of bugreporters school, like the motu school. I will bet there are a lot people who might be interested in becoming propper bug reporters / testers.
<seb128> there is #ubuntu-bugs, a whole set of wiki pages on the topic, and regular bug days for that :)
<seb128> dholbach has planned one for next week again afaik
<triceratops> Arrgl, another channel. The list is becoming longer and longer, 12 ubuntu related entries so far. But I noticed it for the future. EOT
<mjr> anyone know if X.org nowadays does hw acceleration for remote GLX calls?
<mjg59> mjr: No
<HiddenWolf> mjg59: hi
<mjg59> HiddenWolf: Hi
<HiddenWolf> mjg59: got a minute?
<mjg59> Sure
<HiddenWolf> mjg59: it's been bugging me that when I'm watching a movie in totem, my screen goes to standby.
<HiddenWolf> mjg59: seb says it's not totem, pitty doesn't know
<HiddenWolf> I've told g-p-m not to send the screen to sleep, and it's still happening.
<mjr> mjg59, ack
<mjg59> HiddenWolf: Probably a gnome-screensaver issue
<Drac[Server] > Is there ny way I can get Ubuntu to see this old ISA ethernet controller card?
<HiddenWolf> mjg59: I talked to upstream yesterday, and they closed the bug in minutes.
<mjg59> HiddenWolf: If the screen is turning off, it's because X is turning it off. The only thing that's telling X when to do that is gnome-screensaver, unless you have xscreensaver installed
<HiddenWolf> mjg59: so what about g-p-m
<HiddenWolf> It has a setting to send the screen to standby
<mjg59> Yes
<mjg59> But it's gnome-screensaver that actually does that
<mjg59> g-p-m just writes the gconf keys
<HiddenWolf> ok
<HiddenWolf> and something is broken.
<HiddenWolf> I just set g-p-m timeout to 1 minute for send the screen to standby
<HiddenWolf> didn't blank
#ubuntu-devel 2006-02-14
<mjg59> Right
<mjg59> Well, it's almost certainly a gnome-screensaver issue
<HiddenWolf> Hm.
<HiddenWolf> great, now I have to look nice at seb128 again. :/
<HiddenWolf> mjg59: well, thanks anyway.
<Drac[Server] > Is there ny way I can get Ubuntu to see this old ISA ethernet controller card?
<Drac[Server] > any*
* Drac[Server]  waves.
<infinity> Drac[Server] : ISA doesn't hotplug, so you need to modprobe the driver manually (or list it in /etc/modules), that's all.
<HrdwrBoB> the best thing to do is to go to #ubuntu
<HrdwrBoB> and tell them you threw it out
<HrdwrBoB> any movement on this
<HrdwrBoB> https://launchpad.net/distros/ubuntu/+source/glibc/+bug/29768
<Ubugtu> malone bug 29768 in glibc "Australian timezones incorrect for 2006" [Normal,Confirmed]  
<wasabi_> So is anybody doing anything at all with trying to hammer XGl together enough to provide dapper packages?
<Burgwork> wasabi, mjg59 has talked about it
<jsgotangco> hey Burgwork nice seeing you again :)
<xhaker> Burgwork: do you happen to know anything about gksu bindings for python?
<xhaker> i can't even find what module to load
<Burgwork> jsgotangco, I was away on business for a few days, then moving. Still don't have internet at home
<jsgotangco> oh
<infinity> Ugh.  The gnome-power-manager icons are really quite hideous, compared to the old power applet.
* jsgotangco has yet to see that (currently updating)
<HiddenWolf> infinity: I rather like the menu icon.
<HiddenWolf> infinity: then again, i'm using tango.
<infinity> The menu icon is cute, it's the applet icons I object to.
<infinity> I guess the clean and simple icons of old aren't cool anymore in the new world order.
<HiddenWolf> hm
<HiddenWolf> try checking out the nautilus icon on the splash screen when logging in. ;)
<infinity> The network applet changed icons to something much fuzzier and less clean looking too, which I'm not keen on.
<whiprush> infinity: did you get any good feedback on the madwifi-ng testing?
<infinity> HiddenWolf: The shell icon that occasioanlly pops up, but not always?... I think that's a poorly-thought-out easter egg, or something.
<infinity> whiprush: Some.  Not sure if we have enough feedback to push forward with it.
<whiprush> ah.
<HiddenWolf> Hm, I get it for 99% of the time, and it's damn ugly. :)
<whiprush> add me to the "it's broken for me list"
<infinity> whiprush: Especially since many people claim to use madwifi on amd64, where we currently KNOW it's broken in the -ng branch. :/
<whiprush> ah
<whiprush> :-/
<infinity> whiprush: Which was broken for you?... -ng?
<whiprush> yeah
<infinity> whiprush: Shame.
<whiprush> that l-r-m package you posted the other day
<whiprush> indeed.
<infinity> I think we'll probably be stuck shipping madwifi-old one last time (for dapper), then switching to -ng as soon as dapper+1 opens and trying to shake out the bugs.
<infinity> But time will tell.  We may end up with a convincing reason to force the switch.
<infinity> (The biggest reason was network-manager...)
<whiprush> I am picking up an ipw2200 just in case.
<infinity> madwifi-old + network-manager = B-R-O-K-E-N
<whiprush> yeah.
<tseng> whiprush: once you go intel, you dont go back
<tseng> or something
<whiprush> I thought it was fine until my neighbors got an AP
<infinity> madwifi-old insists on dropping your association before scanning for networks.  thpethul.
<whiprush> now I always get stuck on theirs
<whiprush> tseng: maybe I can make this to be an excuse to pick up an X60
<tseng> whiprush: i wont stop you
<infinity> I keep trying to come up with valid excuses to pick up a T60.
<infinity> I think I just need to find someone in .au willing to buy my T43 without taking a terrible loss, then I can justify it.
<whiprush> still waiting for a Z series to come in to work
<whiprush> they're very backordered
<tseng> how do you guys use a thinkpad with such a retarded Ctrl key
<tseng> if i could swap Ctrl and Space i think i would
<whiprush> tseng: map caps lock to ctrl. It's the way God intended anyway
<tseng> whiprush: my hero
<tseng> whiprush: is that possible in $otheros
<HiddenWolf> Why is it that everyone is so raving about the ibm laptops?
<HiddenWolf> specially since they're not IBM anymore?
<whiprush> tseng: I believe so actually.
<tseng> HiddenWolf: they werent "IBM" in that sense for a long time aiui
<tseng> HiddenWolf: but they use premium components
<tseng> whiprush: i could just get another HHK for work and move on
<whiprush> I have 2 myself
<HiddenWolf> Hm.
<tseng> lite2?
<whiprush> yeah
<HiddenWolf> I guess the components are good, but I don't like the screen sizes.
<tseng> rock
<tseng> only complaint is the hub is usb1
<tseng> this isnt 1998
<whiprush> heh
<tseng> good enough for a mouse
<tseng> but not a usb key
<infinity> HiddenWolf: What's wrong with the screen sizes?.. Do you demand a 17" monster?
<glick> excuse me...the nvidia drivers, is there any benefit gained by installing them if you have to disable the RenderAccel option?
* infinity is actually going to downgrade screen size...
<tseng> i care more about resolution than physical size
* lakin wants a smaller laptop too
<infinity> I find my 15" on the T43 makes the whole thing a bit too large, so I'll drop to a 14 inch T60.
<tseng> more pixels for the pushing
<HiddenWolf> infinity: no, but i'm used to 1920x1200, and I don't think I can take 1024x800
<infinity> HiddenWolf: Mine's 1400x1050
<tseng> HiddenWolf: 1440x1050 is "just right"
<tseng> HiddenWolf: if you are a widescreen dude
<HiddenWolf> tseng: i've got a 24" widescreen at home, I'd guess so.
<HiddenWolf> infinity: how much did it set you back?
<infinity> glick: The only benefit in the binary drivers is OpenGL accel (and some fancy dual-head stuff). If you don't care about either, stick with the free driver, it's more stable.
<glick> infinity, will it speed up my x rendering and redrawing apps on the screen?
<infinity> HiddenWolf: 2GHz Pentium M, 2GB of RAM, 15 inch 1400x1050, many other bells/whistles, about 2K USD.
<HiddenWolf> infinity: that's what I was afraid of.
<whiprush> infinity: so is it safe to assume that you'll be sticking with -old for dapper?
<infinity> Yeah, IBM isn't cheap.  OTOH, I've had a very good track record with them.
<whiprush> ie. if I had to make a safe bet?
<HiddenWolf> infinity: I'd gladly take a 1.3ghz, 512 of ram, with the 1400x1050 screen. :)
<infinity> whiprush: It seems most likely at this point.
* whiprush nods.
<infinity> HiddenWolf: Their slowest 1400x1050 offerring is a 1.86GHz Pentium M, ringing in at 1650 USD.
<HiddenWolf> infinity: feel my hurt. :)
<glick> infinity, ?
<infinity> HiddenWolf: Well, that's if you want the portability of a T series.  The R series stuff is cheaper.
<infinity> glick: I've not noticed the binary driver being particularly speedier in 2D than the free driver.
<infinity> glick: It used to be, but the free driver has had a lot of good work put into it.
<glick> cause i dont really run 3d apps
<HiddenWolf> infinity: I still feel nvidia driver is snappier by a bit, but I could just run into cairo/fontconfig/gtk slowless and blame the driver.
<glick> although being able to use some of the xmms visual plugins would be kinna nice
<infinity> glick: If you don't do 3D, do yourself a favour and use the free driver.  Really.
<tseng> the free driver flickers around the edges at high resolutions
<HiddenWolf> tseng: high refresh rates maybe
<HiddenWolf> tseng: did 1920x1200x60hz with it for six months without issue. 
<infinity> tseng: Is there a bug filed about it at fd.o?
<tseng> infinity: dunno, ive noticed it for years
<tseng> its not constant, you notice it occassionally when moving a window or something
<tseng> you get a bit of artifacting along the edge
<infinity> tseng: I've not noticed it at all, so bugs are nice. :)
<tseng> it goes a few times until it bothers me enough to switch drivers
<HiddenWolf> tseng: well, moving a window gives a lot or artifacts with whatever you do these days.
<tseng> "nvidia" or "ati" are smooth as silk for me
<tseng> at least wrt what im talking about
<HiddenWolf> tseng: nvidia is closed, ati is open
<HiddenWolf> tseng: fglrx is the ati closed one.
<tseng> ok?
<tseng> (yes, I knew that)
<tseng> not sure that has anything to do with a driver having flickering or not
<seth> if the new ndiswrapper is showing my wlan0 as eth1 and refusing to bring it up, is that a bug, or something that I have set wrong?
* seth is wondering whether to report it
<crimsun> in 2.6.15-15.20?
<seth> yep
<seth> it didn't even insert the module before -15
<seth> now the module loads, and eth1 is listed as my wireless interface
<seth> but it won't ifup
<seth> it used to be called wlan0
<seth> but knowing me, it could be something set wrong instead of a bug
<seth> so I wanted to check before filing a bugreport
<crimsun> (see #ubuntu)
<pitti> hey
<glick> scuse me any idea why my w and who commands are acting strange all of a sudden?
<Treenaks> 'strange' ?
<glick> Treenaks, as in not displaying logged in users
<glick> showing users as 0
<Mithrandir> doko: I played a bit with the experimental ooo packages and they seem to not work very well.  Problems opening OOo documents, etc.
<JaneW> **Reminder** Dapper Dev Status Update Meeting in #ubuntu-meeting in +- 15 mins.
<dholbach> good morning
<JaneW> Lathiat: ping -> #ubuntu-meeitng
<JaneW> meeting I mean
<JaneW> sivang: ping-> Dapper meeting
<pitti> Kamion: does germinate already support automatic seeding of -dev/-doc/-dbg?
<JaneW> hi BenC
<Kamion> pitti: no, not yet, sorry
<BenC> hey
<pitti> hi BenC 
<pitti> moin seb128 
<seb128> hey pitti
<JaneW> ajmitch: ping
<BenC> pitti: hey
<doko> Mithrandir: OOo docs, or only MS docs?
<Mithrandir> doko: OOo docs.  Not very complicated ones either.
<Mithrandir> doko: either fails to open or gives garbled docs
<doko> hmm, that would be worse than with previous snapshots
<freeflying> doko: my OOo keep crash when I try open file have chinese content
<Mithrandir> doko: I'm sorry that it's not very useful as a bug report.  I can prod it around a bit more, but my gut feeling is that ooo-amd64 isn't ready
<pitti> seb128: on current ppc/live, I only have an evo icon in the panel, no more yelp and ffox - is that intended?
<seb128> yelp is intended, firefox is not
<seb128> is that a laptop or desktop profile?
<pitti> seb128: it's my laptop, not sure what you mean by 'profile'
<seb128> so that's a laptop :)
<seb128> gnome-panel has a desktop and a laptop profile for the default panel config
<seb128> one has battstat the other hasn't it
<pitti> oh, I didn't know that - so far they always looked the same on my two boxes
<pitti> ah, right
<pitti> seb128: but I don't have a battstat here
<seb128> the gnome-panel-data.postinst has that:
<seb128>     if [ -x /usr/sbin/laptop-detect ]  && /usr/sbin/laptop-detect; then
<seb128>         echo "laptop configuration"
<seb128> ...
<seb128> anyway I'm not sure that the liveCD uses the same profile, Mithrandir?
<Mithrandir> seb128: it calls reconfigure on gnome-panel-data and chroot /root /bin/sh -c 'gconftool-2 -t bool -s /apps/panel/global/disable_l
<Mithrandir> ock_screen true'
<seb128> pitti: do you have a file:///usr/share/applications/firefox.desktop ?
<pitti> it's in the menu, let me check
<pitti> yes
<pitti> seb128: laptop-detect returns with 0, so that seems to work
<pitti> Mithrandir: logout on the live CD doesn't work, it just makes the desktop hang; known?
<Mithrandir> pitti: not really.
<Mithrandir> pitti: any idea what's hanging?  (You have shells on tty1-6)
<pitti> bah, now it worked of course (it's my second session, I killed the first one with ctrl+alt+backspace)
<pitti> Mithrandir: will investigate later
<Mithrandir> thanks
<pitti> Mithrandir: it's back, let's do that after the meeting; it seems that it hangs when a terminal is opened
<seb128> pitti: https://launchpad.net/distros/ubuntu/+source/gnome-applets/+bug/30038 ... what package is to blame?
<Ubugtu> malone bug 30038 in gnome-applets "SmartBattery load level not shown" [Normal,Unconfirmed]  
<pitti> seb128: iz hal bug, but that requires a wholly new device class (reading i2c devices)
<seb128> k, reassigning to hal so, thank you :)
<doko> ogra: the schooltool developers promised to fix schooltool for 3.2 before feature freeze
<ogra> doko, yes, i talked to jinty yesterday ...
<ogra> but i'll have to take schooltool out temporary for the CDs to be installable :/
<ogra> and schooltool will have less testing through that ... which is kind of worrying me
<Kagou> hi
<sivang> Riddell: keep is the name of the tool?
<pitti> Kamion: no daily/current for ppc - is that a transient problem or a bug somewhere?
<ogra> kernel transition ? 
<Kamion> please don't speculate
<Kamion> I need to make the logs public so that people can look
<Kamion> Running tools/boot/dapper/boot-powerpc 1 /srv/cdimage.no-name-yet.com/scratch/ubuntu/daily/tmp/dapper-powerpc/CD1
<Kamion> cp: cannot create directory `powerpc/cdrom': Permission denied
<Kamion> make: *** [/srv/cdimage.no-name-yet.com/scratch/ubuntu/daily/tmp/dapper-powerpc/bootable-stamp]  Error 1
<Kamion> hmm, odd
<ogra> ouch
<Riddell> sivang: yes, it's on revu
<Riddell> sivang: it uses rdiff-backup
<Riddell> sivang: http://jr.falleri.free.fr/keep
<Kamion> impressive, somehow stuff ended up as group warthogs
* Kamion runs a big chgrp -R
<Kamion> pitti: should be cleared up in a bit, thanks for the report
<ogra> hmm, why are all changes mails from <user>@drescher... suddenly ? 
<pitti> Kamion: thanks
<Kamion> ogra: see #canonical and https://launchpad.net/products/launchpad-upload-and-queue/+bug/30938
<Ubugtu> malone bug 30938 in launchpad-upload-and-queue "manual source accepts from new result in bizarre mails" [Normal,Unconfirmed]  
<Kamion> it's not all, it's only manual source accepts from new
<pitti> seb128: if that firefox icon on live CD works for you, how can I debug it?
<ogra> ah :)
<ogra> somehow my mind always drops the @ in the addresses .... looks like we're a big family now ... ian drscher and daniel drescher etc :)
<seb128> pitti: I don't know if it works, I've not tried a liveCD for some weeks now. But that part has not changed for ages, does it do the same on a ppc installation?
<seb128> pitti: if it works on an installation that's a liveCD bug, I don't know what they change
<Kamion> 'apt-get source casper', not hard to find out ...
<pitti> seb128: I wait for the current ppc/install, then I'll reinstall my laptop again to find out
<pitti> I want to do a new test-install anyway
<seb128> oki
<lucas> hi
<lucas> what's the policy regarding uploads to breezy-updates for universe packages ?
<lucas> who does the reviewing ?
<pitti> mvo: can you please ping me when you have some minutes to discuss desktop files in g-a-i?
<mvo> pitti: sure, will /msg you
<seb128> feel free to talk on #ubuntu-desktop about that :)
<pitti> ok
<seb128> lucas: good question, what do you want to upload?
<lucas> librmagick-ruby
<lucas> to fix LP bugs 1299 and 4636
<Kamion> lucas: currently mdz and I are the only reviewers for -updates
<Kamion> not that uploading to -updates really works at the moment with the soyuz migration - please hold off a bit on that until we have a process in place
<lucas> ok
<lucas> any approximative timeline ?
<mdz> lucas: that'd be a #launchpad question; I'm not sure
<lucas> ok
<mdke> lucas, see the launchpad-users list there was an update about it yesterday
* lucas really should subscribe to launchpad-users
<Kamion> seb128: I think you typoed the bug number when duplicating #30904
<seb128> bug #30904
<Ubugtu> malone bug 30904 in eog "Can't open the Win shared pictures" [Normal,Unconfirmed]  http://launchpad.net/bugs/30904
<seb128> right, I used the bugzilla number
<seb128> Kamion: thanks for pointing it
<seb128> fixed
<Kamion> np
<carlos> pitti: hi, do you have some minutes for me?
<pitti> carlos: yes
<carlos> pitti: could you provide me a build output with your new strip translations script?
<carlos> pitti: I need it for testing purposes
<carlos> I suppose it would be a pmount build
<carlos> I suppose it would be enough with a pmount build
<pitti> carlos: 'new' - you mean the one which adds the tarball to the .changes?
<carlos> pitti: yes
<pitti> sure, no problem
<carlos> so we can add some tests for that before moving it into production
<pitti> do you also need the built source tree?
<carlos> pitti: the .deb, sources and any output it generates
<pitti> or only tarball and changes?
<pitti> ok, I'll just tar up the complete dir
<carlos> well, I suppose it's enough with only the files referenced by the .changes file
<carlos> but If you give me the whole output I'm sure I don't need to ask you anything else later ;-)
<carlos> pitti: thanks
<janimo> pitti, did the firewall work turned out to be too much to finish for dapper?
<janimo> is carsten working on it but takes time?
<pitti> janimo: exactly
<pitti> Mithrandir: I think I found the root cause of the logout/shutdown hang, will take this up with mvo
<pitti> Mithrandir: update-notifier hogs the CPU again and thus does not want to shutdown properly
<janimo> pitti, as for deferring the printer autoconfig is cups being followed up to the 1.2 release in dapper?
<janimo> I read they plan to add something similar to hal+cups upstream, ie not redhat patch
<pitti> janimo: we are past version freeze, but I'll watch the weekly snapshots
<pitti> janimo: as long as they are safe, I'll update
<janimo> do they have other lists besides cups-devel and general? those are pretty incactive besides some release notifications
<Mithrandir> pitti: ah, ok.  Not a live cd thing, then
<janimo> is there a common printing list where cups/gnome/kde are together?
<pitti> Mithrandir: it probably just triggers the right actions on the right time, or sth like that :)
<pitti> carlos: do you want source+binary or a binary-only build? the latter would be closer to a buildd output
<carlos> pitti: then, the later
<Riddell> janimo: in theory desktop-printing on OSDL would be it
<janimo> Riddell, thanks
<Riddell> lists.osdl.org
<janimo> let's see if gmane has it
<pitti> carlos: http://people.ubuntu.com/~pitti/tmp/pmount-build-distaddfile.tar.gz
<janimo> not on gmane, upstream mail archive down
<carlos> pitti: cool, thanks
<dooglus> if I find a possible security problem with a ubuntu package, who should I tell?
<pitti> dooglus: security@ubuntu.com
<dooglus> thanks.
<pitti> dooglus: or open a malone bug with 'keep private' enabled
<pitti> dooglus: unless it's already publicly known
<dooglus> I did that.  but who's going to see it, since it's private?
<pitti> dooglus: I will :)
<dooglus> ok
<pitti> seb128: bah, current ppc/daily doesn't install due to kernel transition; I will try this tomorrow
<Kamion> pitti: meh?
<Kamion> is that the build I just did?
<pitti> Kamion: yes
<pitti> it could not install linux-image-powerpc
<Kamion> the kernel transition is supposed to be done
<Kamion> really linux-image-powerpc, or linux-powerpc?
<Kamion> huh, the CD is still on -14
<Kamion> what is going on
<ogra> Kamion, http://cdimage.ubuntu.com/edubuntu/daily/current/report.html says its trying -14 as well 
<Kamion> yeah, just sort of figured it out
<Kamion> it's breakage from the concurrent-install/live-CD-build work I did yesterday
<Kamion> don't ask and I won't have to explain the sheer complexity of exactly why :-/
<carlos> pitti: hmm, are the changes to support .desktop translation updates included with dapper?
<pitti> carlos: yes, for quite a while already
<carlos> oh!, didn't know that
<carlos> pitti: which approach did you take?
<pitti> carlos: for .directory as well :)
<carlos> use gettext directly?
<pitti> carlos: .server will follow shortly
<carlos> cool
<pitti> carlos: yes, that worked just fine; see the benchmarks on the spec page
<carlos> cool
* carlos goes to the spec
<pitti> carlos: performance impact is below the measurement error range
<carlos> so we are not caching anything
<pitti> no, no need to
<carlos> pitti: are you going to ask upstream to include it?
<pitti> carlos: I should probably
<carlos> pitti: please, add me to the CC of that email then
<pitti> I will
<Kamion> ah, I see the bug, fixing now
<Kamion> pitti: thanks for the report
<pitti> thanks, you rock :)
<ogra> Kamion, can you wait a second with the edubuntu builds 
<Kamion> although best not to assume that CD bugs are kernel transitions without checking with me first :)
<Kamion> ogra: I was going to anyway, you can rebuild those yourself later if you like
<ogra> i just removed schooltool temporary, waiting for the seeds to sync
<Kamion> you will need to upload edubuntu-meta then too
<ogra> ok, i need some guidance the first time 
<ogra> yes, waiting for the change to show up in the seeds
<Kamion> ogra: read and follow /srv/cdimage.no-name-yet.com/secret/README
<pitti> the amd64 CD seems ok, so I'm going to do amd64 live+install tests now
<ogra> Kamion, thanks
<Kamion> pitti: all architectures have the same problem
<Kamion> ogra: then read the "Day-to-day operation" section of /srv/cdimage.no-name-yet.com/README
<pitti> Kamion: oh? at least the 15 packages seem to be on the CD
<ogra> hmm, little still asks me for a password
<Kamion> ogra: summary: 'for-project edubuntu cron.daily' builds a normal Edubuntu install CD
<Kamion> ogra: oh, you probably can't log in then
<ogra> yes
<Kamion> dapper-install-amd64.list:/pool/main/l/linux-source-2.6.15/linux-image-2.6.15-14-amd64-generic_2.6.15-14.19_amd64.deb
<ogra> i thought elmo had added me 
<Kamion> pitti: that's the only one on the current amd64 CD
<ogra> elmo, ping ? 
<pitti> Kamion: oops, right, the 15 packages are just the udebs
<pitti> thanks for the warning
<pitti> nevertheless, time for live cd testing
<pitti> bbl
<pitti_> Kamion: just trying 'check cd for defects' -> nice :)
<ogra> hmm, looking at the seeds ...
<ogra> wasnt gstreamer0.8 supposed to be gone ? 
<pitti_> ogra: what's still left?
<ogra> all
<Kamion> I don't think anybody's ever edited the seeds for that
<ogra> ogra@edubuntu:/mnt/devel/seeds/dapper$ grep gstreamer0.8 *|wc -l
<ogra> 33
<Kamion> the current oversizedness might have something to do with that, I guess ;-)
<ogra> no wonder my CD overflows 
<ogra> hrm :(
<pitti_> seb128: ok to kick gst 0.8 out of the seeds?
<seb128> pitti_: it's on my list for this week, I just wanted to get serpentine using gst0.10 first
<seb128> I can do that now if you want
<pitti_> oh, not specifically for me
<ogra> seb128, would save me a lot of headache with edubuntu 
<pitti_> just about ogra's question aboce
<ogra> the CD in constantly overflown
<seb128> ogra: I'll drop serpentine from the desktop for now so :/
<ogra> fine with me ... you know my opinion about serpentine :)
<seb128> I'm still waiting for upstream for having a version using gst0.10
<Kamion> (BTW, "is overflown" sounds weird in English, although it *might* be technically correct. I'd use "is overflowing" or "has overflowed" instead.)
<seb128> ogra: we need to add it back then
<ogra> seb128, i'll put a note on my desktop ...
* Lathiat thinks "is overflown"
<Kamion> "flown" is the past participle of "fly", not "flow"
<Kamion> wrong verb
<Lathiat> so what, flowed?
<Kamion> yes
<Lathiat> hrm, point
<Kamion> "in the past the river has flowed past this house"
<Kamion> or some better example
<pitti_> Kamion: is there a prefered action what to do after the cd consistency check? I just rebooted
<Kamion> pitti_: there's a bug open saying it should prompt and then reboot
<pitti_> ok, good
<ogra> the river was flowing ? 
<Mithrandir> pitti_: it should reboot after a keypress, but usplash doesn't support that yet.
<pitti_> ogra: let's sing that on the next conference :)
<Mithrandir> pitti_: I need to write the code to support that.
<ogra> or did it flee the house :P
<pitti_> ok, just making sure that everthing is in malone
<Kamion> ogra: again, wrong verb. The past participle of "flee" is "fled".
<ogra> gah ...
<ogra> i'll never get english grammar right :/
<Kamion> fly -> flown, flow -> flowed, flee -> fled. consider this revenge for all the learning of German irregular verbs I had to do ;-)
<ogra> hehe
<ogra> but as Keybuk pointed out ... no matter how much you f*ck it up, people will still understand you which is not the case in german
* Lathiat woudl be curious to talk to someone who implements speech recognition and how lax in syntax english is compared to other languages
<pitti_live> seb128: ok, on amd64 live the firefox icon does not appear as well (desktop)
* ogra bets you can even write sane poems with broken english grammar
<Kamion> well German has practically the same set of verbs there - fliegen -> geflogen, fliessen -> geflossen, fliehen -> geflohen
<seb128> does it on an installation?
<Kamion> although I had to look most of those up
<Kamion> I guess the construction is a bit more regular
<Kamion> anyway, back to work ...
<pitti_live> seb128: no idea, my current install cds are broken, will try tomorrow
<WaterSevenUb> kamion, F1 working now... ${MEDIA_TYPE} can be CD-ROM +... ?
<WaterSevenUb> kamion, because of the gender of the word in the translation....
<pitti_live> meh, wrong resolution on the live CD
<pitti_live> Mithrandir: would it be possible to go back to asking about the screen resolution instead of just assuming 1024x768?
<Kamion> WaterSevenUb: afraid it's substituted in in a kind of nasty way at the moment - can be "CD-ROM", "netboot image", "bootable drive", "boot image", "floppy"
<pitti_live> Mithrandir: breezy live/install just asked me (debconf)
<Mithrandir> pitti_live: no.
<Mithrandir> pitti_live: however, I'm going to fix ddcprobe to work on amd64.
<Kamion> WaterSevenUb: not sure how to deal with making that translatable
<pitti_live> Mithrandir: even better :)
<Kamion> pitti_: CDs fixed
<Mithrandir> pitti_live: I have it working for the VBE stuff, but it segfaults in the DDC probe section
<pitti_live> \o/
<ogra> pitti_live, it should fall back to ask for weird rundetectable resolutions though
<ogra> i.e. on my amd64 lappie it always asked, since the display doesnt throw out anything in ddcprobe ... or it falls back to 1024 ...
<Kamion> sorting out ddcprobe should deal with most of that
<Kamion> the new live CD will never ask for anything though, and has no infrastructure for asking anything any more
<pitti_live> oh, and the language will certainly be transfered to the desktop environment, right?
<ogra> how do you sort out ddcprobe if the display doesnt answer anything ... 
<pitti_live> I chose 'German' at the gfxboot screen, but get English so far
<pitti_live> Kamion: ^ how will ppc handle that?
<Mithrandir> pitti_live: you should have a german locale?
<Mithrandir> ogra: there's no infrastructure for asking about anything.
<pitti_live> Mithrandir: no, I have en_US
<pitti_live> .UTF-78
<pitti_live> erm, -8
<Mithrandir> pitti_live: weird.
<ogra> then i'm doomed to 1024 on the liveCD with this machine i guess 
<Kamion> pitti_live: for the moment we just have to make sure that it's easy to change the language/keymap after boot
<Mithrandir> ogra: if your hardware is broken, you need to reconfigure X by hand, yes.
<pitti_live> Mithrandir: let me try that again, I might not have set it back on my second boot
<ogra> (which looks very odd on a 1280x800 display btw)
<Kamion> since powerpc has no gfxboot-a-like at the moment
<Mithrandir> pitti_live: you won't get the correct _keymap_, but language should be set.
<pitti_live> yes, that's why I asked
<Kamion> pitti_live: check /proc/cmdline after boot, too
<pitti_live> Mithrandir: ok, I'll try it again right now
<Mithrandir> pitti_live: what does /proc/cmdline look like?
<Kamion> it should have debian-installer/locale=de_DE.UTF-8 or similar in it
<pitti_live> BOOT_IMAGE=/install/vmlinuz boot=casper initrd=/install/initrd.gz ramdisk_size=1048576 root=/dev/ram rw quiet splash --
<Kamion> so either you didn't select it or gfxboot-theme-ubuntu is a bit b0ren
<Kamion> b0rken
<Mithrandir> doesn't look like you set in the bootloader, then.
<pitti_live> I selected it, but that might have been at the time when I chose integrity check
<pitti_live> it's probably that
* pitti_live reboots to find out
<pitti_live> bbl
<pitti_> so, now I definitively selected it
<Mithrandir> and it's not on /proc/cmdline?
<pitti_> still booting...
<pitti_> Mithrandir: ok, it's there now, and I have de_AT.UTF-8
<Mithrandir> pitti_: woo
* pitti_ waves to Austria
<pitti_> Mithrandir: ok, sorry for the noise then
<Mithrandir> pitti_: np
<pitti_> Mithrandir: any plans to include country selection? I don't mind being regarded as an Austrian, but some Taiwanese/Chinese folks might care :/
* Mithrandir sends pitti_ an ICMP REDIRECT to Kamion :-)
<Lathiat> Mithrandir: heh
<Kamion> pitti_: no, but note that gfxboot-theme-ubuntu lists Taiwanese and Chinese separately
<Kamion> also Portuguese and Brazilian Portuguese
<Kamion> I believe those are the only two cases where it makes a really big difference
<Kamion> well, for Taiwanese and Chinese read Traditional Chinese and Simplified Chinese, but whatever
<pitti_> Kamion: true, that's a nice solution
<Kamion> Austrian is not the best default for de though
* Kamion redirects back to Mithrandir, I think I just pass debian-installer/locale=de
<doko_> Kamion: we once even had Luxemburg
<pitti_> Kamion: I remember talking with Tollef about that, I think right now it just picks the first one it can find
<Kamion> maybe I could scrape a better list of defaults out of localechooser though
<Mithrandir> pitti_: it does.
<Kamion> yeah, I guess it's easier for me to do that in gfxboot-theme-ubuntu
<pitti_> Kamion: we can also just reorder /usr/share/i18n/SUPPORTED
<Kamion> nah, would rather figure out the installer's defaults
<Kamion> somebody please file a bug for me on gfxboot-theme-ubuntu and I'll get to it
<pitti_> I will
<Kamion> thanks
<pitti_> although it doesn't really matter much for de in particluar
<Kamion> makes more difference for fr I guess, fr_CA < fr_FR
<Kamion> or en_GB < en_US for that matter
<Kamion> (though we never pass debian-installer/locale=en so don't hit that particular case)
<pitti> ok, filed
<jdub> fabbione: ping
<fabbione> jdub: pong
<rod_> could someone please host xgl-svn_100.tar.bz2  ?
<Treenaks> rod_: uh.. just wait for it :)
<rod_> thnx Treenaks, I'm waiting
<rod_> Treenaks, ?
<Treenaks> rod_: hm?
<rod_> Are you prividing a link or...?
<Diziet> Bah, my ff from yesterday didn't build.  I'm sure I tested it.
<ogra> mvo, gksudo says "Bitts das passwort eingeben" ...
<Mithrandir> uh, there's something _funky_ in the current live cd.
<Mithrandir> "can't open perl script "-e": No such device or address"
<Mithrandir> uhm
<mvo> ogra: anything wrong with that?
<Mithrandir> my /dev/null is c 0,259
<mvo> ogra: apart from the fact that it should be uppercase
<ogra> mvo, last time i wrote Bitte it had an e in the end ;)
<mvo> ogra: new spelling *cough*
<mvo> ogra: fix it yourself in rosetta ;)
<ogra> heh
<Rod_> Can someone provide me a working link for http://freedesktop.org/%7edavidr/xgl-svn_100.tar.bz2 , please?
<mjg59> Rod_: Here? Probably not
<ogra> Rod_, see topic, this is not a support channel
<mdz> dholbach: new HelpingWithBugs/* looks much better, thanks
<Rod_> mjg59, not sure where else to go
<ogra> try #ubuntu
<mjg59> Rod_: And it's all been put in CVS, anyway
<mjg59> Rod_: #freedesktop or #xorg are better bets
<dholbach> mdz: super
<Rod_> ohh okay, thanks mjg59  will try there
<Lathiat> Preconfiguring packages ...
<Lathiat> /tmp/x11-common.config.25151: line 28: laptop-detect: command not found
<Lathiat> does x11-common need to pre-depend on laptop-detect?
<Lathiat> i think that exists
<mdz> Mithrandir: 259?
<Mithrandir> yes, a "slightly odd" number, I agree
<mdz> I thought minors were 8 bits
<Mithrandir> 259 is 1 << 4 + 3, so it should correspond to 1,3
<Mithrandir> if I run makedev again, it works
<mdz> very strange
<mdz> Lathiat: pre-depends aren't fulfilled for .config
<mdz> laptop-detect is pre-installed by the installer, though, so unless you remove it explicitly, it's OK
<Lathiat> mdz: thats with pbuilder
<Lathiat> mdz: if it doesnt affect the isntaller then i guess its ok
<Lathiat> just thought i'd mention it
<mdz> it's harmless in any case
<StevenK> 1 << 4 + 3 != 259
<mdz> StevenK: 1 << 8 + 3, he meant
<StevenK> Ah
<Mithrandir> well, yes.
<Mithrandir> I suck at maths
<Mithrandir> or something. :-)
<ogra_live> Mithrandir: no network interfaces on the livecd ?
<ogra_live> and /sbin not in path ...
<Kamion> Lathiat: indeed, doesn't affect the installer, and is harmless as mdz says
<Mithrandir> ogra_live: you have an outdated live cd
<Kamion> next time I'm bored (haha) I'll make it check for the presence of laptop-detect before trying to run it
<ogra_live> Mithrandir: oh, then edubuntu wasnt built ? i just rsznced 10 min ago from the 20060209
<Kamion> ogra_live: check the logs
* ogra_live grrs at the en keyboard
<Kamion> http://terranova.buildd/~buildd/LiveCD/dapper/edubuntu/latest/ from chinstrap
<Mithrandir> ogra_live: what arch?
<ogra_ibook> i386
<Mithrandir> ogra_live: it seems to have built.  What's the version of casper in the live image?
<ogra_live> 1.28 it seems
<Mithrandir> that's old
<ogra_live> hmm, k
<ogra_live> so it needs a new livefs build i guess 
<ogra_live> it boots and works fine though :)
<Mithrandir> Get:961 http://ftpmaster.internal dapper/main espresso-casper 1.29 [10.3kB] 
<Mithrandir> that's from the latest
<Mithrandir> so something went wrong in the live image build.
<ogra_live> ah
<ogra_live> hmm, it also has the -15 kernel and wasnt oversized, strange 
<Kamion> ok, for your comfort and convenience, http://people.ubuntu.com/~cjwatson/cd-build-logs/
<ogra> ah, thanks ...
<zakame> ooh!
<Kamion> I may fiddle with the directory structure there at some point
<ogra> lynx is nice but a bit hard to use :)
<Kamion> no this is not livefs build logs, you still need to go to chinstrap for those
<Kamion> this is ISO image build logs which you've previously needed a login to little to see
<Kamion> intention being that people other than me can figure out what might have gone wrong with CD builds
<ogra> ah
* Kamion adds to DeveloperResources
<Kamion> mind you it might not be *too* hard to figure out how to publish the livefs logs too
<Kamion> FATAL: Could not load /lib/modules/2.6.12/modules.dep: No such file or directory
<Kamion> infinity: any idea what that's doing in current dapper livefs build logs?
<ogra> Get:975 http://ftpmaster.internal dapper/main casper 1.29 [22.9kB] 
<ogra> hmm
<Mithrandir> something using uname -r ?
<Kamion> could be
<ogra> seems to be there as well 
<Mithrandir> ogra: the md5sums of i386.squashfs on little and terranova are different, so I presume they're different images
<ogra> strange ...
<ogra> seems the livefs was built fine though ... could that be a race ? 
<Mithrandir> can somebody else please try to boot the current live cd with break=mount ; when you get a prompt do find_cd ; setup_cow unionfs $(get_backing_device /cdrom/casper/filesystem.squashfs) /root ; ls -l /root/dev/null /rofs/dev/null ; ?
<Seveas> random thought: if espresso is going to be ported to kde/kubuntu, should't the KDE version be called kappucino?
<Riddell> :)
<Riddell> no way
<jdub> Seveas: you're not drilling deep enough into your head, maybe get a bigger drill bit.
<Seveas> jdub, hehe, ok how about: why reboot after the single stage install? Won't some mounting tricks+chroot work too? :)
<jdub> Seveas: -> Kamion 
<sivang> Diziet: should I install autodebtest or autopkgtest ?
<jdub> (who thinks that rebooting is an important test of installation success, and rightly so)
<Seveas> jdub, it was just a random thought from the dark areas of my brain :)
<Treenaks> Seveas: Lelystad must be crack heaven
<Seveas> Treenaks :)
<dholbach> Kamion: woohoo - gparted upstream says "actually i should take a couple of days and try to get this in HEAD" about the installer patch! :-)
<dholbach> Kamion: ... which will getting gparted 0.2 into Ubuntu easier (it has a bunch of other changes we'd really want)
<Kamion> sivang: autodebtest is obsoleted by autopkgtest
<Kamion> dholbach: woo, thans
<Kamion> thanks, even
<dholbach> Kamion: I didn't reach danielk for the mount point magic yet.
<ogra> Kamion, Mithrandir, so any hint why it didnt pick the right livefs to build the image ? 
<Kamion> for your further comfort and convenience, http://people.ubuntu.com/~cjwatson/livefs-build-logs/
<sivang> Kamion: k, thanks
<ogra> Kamion, wow, cool :)
<Kamion> note that files never get deleted there, and current and latest aren't symlinks, which might make their contents a bit odd sometimes
<Kamion> ogra: not offhand, but you now have all the information easily available ;-)
<pitti> Diziet: firefox is ftbfs, if you upload a new version, may I humbly remind you about the CVEs?
<Lathiat> anyone got a source for debain changelogs?
<Kamion> ogra: today's edubuntu live CD built five hours or so before the most current edubuntu live filesystem, that's all
<Kamion> want a fresh build?
<ogra> yup please ...
<Kamion> on its way
<ogra> since i dont know if or when elmo will show up for my little access
<ogra> thanks :)
<Kamion> ogra: you're in the cdimage group already ... looks like an oversight I guess
<ogra> yup
<ogra> (i wouldnt guess it was intentional ;) )+
<pitti> ogra: wrt sound on ppc, I played with the alsamixer levels like mad, and suddenly it worked
<ogra> pitti, i spent hours on my alsamixer already ...
<pitti> I only needed 2 minutes
<ogra> i fear having broken it ... but slomo has the same prob
<pitti> everything appeared to be right by default
<pitti> I just reinstalled from scratch, and after playing with alsamixer it worked
<pitti> I wasn't able toget it workin with the gnome mixer
<pitti> something in alsa-utils seems broken
<ogra> can you run: amixer > amixer.out and post that anywhere ? 
<pitti> right, I should have done that from the beginning for diffing
<ogra> since you have it working, we have a reference :)
<Kamion> ogra: new edubuntu live published
<ogra> Kamion, ta
* ogra rsyncs
<pitti> http://people.ubuntu.com/~pitti/tmp/amixer.out
<pitti> ogra: ^
<ogra> thanks
<ogra> YAY !!
<ogra> amixer sset 'PC Speaker' off
<ogra> that did it :)
<pitti> odd
* pitti checks
<pitti> ogra: I can enable PC speaker, and it still works
<ogra> it was the only difference ... apart from volume settings ...
<pitti> ogra: I'll check that on the next boot
<pitti> ogra: we can disable it by default if it helps
<ogra> whoo, shocking, m xchat beeps again ....
<ogra> argh ... ppc live is 714MB ? 
<ogra> (edubuntu) 
<jsgotangco> doh
<ogra> the former was only 701 ... what the hell was added there to make it this big ? 
<delire> now we're getting somewhere. very nice mockups and right inline with the Ubuntu bare desktop approach: http://desplesdadotcom.nfshost.com/?p=75
<jsgotangco> hmmm
<jsgotangco> delire, that's a -desktop/-artwork thing
<ogra> *shudder* blue 
<jsgotangco> yeah
<ogra> but the name somehow implies that :)
<delire> jsgotangco: agreed..
<delire> that said a few new useability innovations are introduced.
<seb128> doko: why is PROMPT_COMMAND commented by default now?
<doko> seb128: it's in .bashrc, having it in /etc/bashrc forces it unconditionally
<pitti> what's bad about having it by default?
<seb128> so it works only for people who don't have their .bashrc for ages, ie: new install
<tepsipakki> omg, gnucash-1.9.0 released
<seb128> GTK2?
<tepsipakki> yes
<seb128> ah, nice
<doko> seb128: do we care?
<ogra> yay
<seb128> doko: without it, no path as window title for g-t
<seb128> doko: that sucks to have 15 command line open with the same title
<doko> seb128: sure, but you cannot have both
<seb128> both what?
<seb128> I would just like to have that feature working out of the box
<pitti> (like it was in hoary)
<seb128> I had to edit my .bashrc to get it working
<seb128> and I'm pretty sure 90% of the users will not figure that they need to do that
<doko> seb128: it _is_ working out of the box, upgrades are not "out of the box"
<ogra> we could put a message in the terminal that shows up until you edited .bashrc :P
<seb128> doko: so you break upgrades, which is not nice
<seb128> it was working for me
<seb128> and it doesn't after upgrading
<seb128> that's a regression
<doko> is .bashrc sources in your .bash_profile?
<torkel> seb128: it is commented in breezy too
<seb128> doko: yep
<seb128> doko: but .bashrc is a custom stuff I've for ages now
<seb128> and it had no PROMPT_COMMAND
<doko> seb128: it does. watch /etc/skel/.bashrc
<seb128> doko: my .bashrc comes from my previous Debian installation probably
<seb128> not from the skel
<doko> so you're not the typical user to call it a regression ;-P
<seb128> I didn't say I'm the typical user
<seb128> but some people around have a custom .bashrc probably
<seb128> anyway, no big deal, let's wait for the next bug about that
<seb128> I played with that because we got a bug on g-t
<doko> seb128: the reason to have it uncommented is to be able to set the title from an xterm invocation to something completely different
<seb128> doko: the user config take over the default one no?
<Lathiat> seb128: xterm -t "x" is just overwritten when bash sets it
<seb128> if you have something to /etc and user customize it again with his .bashrc the second version is used no?
<Lathiat> err not -t
<Lathiat> somethign else, that sets the title string, i forget what it is :)
<Lathiat> -title <string> :)
<Kamion> seb128: both are run; the user's .bashrc would have to explicitly unset PROMPT_COMMAND
<doko> seb128: yes, but a user can overwrite it in his own .bashrc
<seb128> Kamion: right, it makes it possible for an user to do so
<freeflying> doko: hi
<seb128> I don't get the issue with having it by default to /etc/bashrc
<seb128> it's working for everybody so
<freeflying> doko: we still can not type ,paste ,or open chinese file 
<seb128> and users are free to change it or unset it
<doko> freeflying: sure, nothing did change
<doko> seb128: please show a way to have it uncommented in /etc/bashrc and xterm -t still working
<seb128> doko: dunno about xterm, but the default command line is g-t no?
<seb128> we break the default component to support an another one ...
<doko> seb128: please show a way to have it uncommented in /etc/bashrc and g-t -t still working ;-P
* seb128 man
<seb128> what does -t do?
<azeem> Set the terminal's title to TITLE.
<Lathiat> tektronix mode
<Lathiat> -title sets the title
<seb128> yeah, I've figured
<seb128> doko: ok, you just break the standard feature to allow other usecase
<seb128> fine with me, but I would prefer having the default installation working correctly :)
<doko> seb128: no, I just break seb128's historic .bashrc
<seb128> no points to argue for hours about that
<seb128> doko: and some users' too, I started looking on that because we got a bug about it
<doko> seb128: it's a feature, not a bug. it's not broken for new users. If we have the choice to enable something which didn't work before, we should do that. you can argue about enabling bash_completion in the same way (enabling it in .bashrc, not /etc/bashrc)
<seb128> doko: yeah, gotcha, makes sense :)
<Chipzz> doko: did you have time to take a look at my patch? ;)
<doko> Chipzz: the rlimit stuff?
<Chipzz> doko: the scp bash_completion thingie ;)
<doko> Chipzz: ahh. no, we'll have a bash_completion update later, just forwarded it upstream
<Chipzz> doko: I allready sent it upstream ;)
<Chipzz> doko: no reaction yet though :/
<doko> Chipzz: to Ian?
<tepsipakki> kamion: umm, the daily netboot-images are still at 2.6.15-13, for a reason?-)
<Chipzz> doko: jups
<Kamion> tepsipakki: dailies haven't been built since we switched to soyuz. use installer-*
<tepsipakki> ah, ok
<Kamion> tepsipakki: in general you should always use whichever of installer-* and daily-installer-* is newer
<Kamion> that's what the CD image build process does
<Chipzz> doko: btw, sorry to bother you with this kind of question, but do you know when ! should be quoted in "" in bash?
<Chipzz> I read the manpage but couldn't quite make sense of it
<tepsipakki> kamion: yeah, sure. haven't been installing for awhile, so didn't spot this earlier
<Kamion> Chipzz: always, unless you want it to perform history expansion
<Kamion> Chipzz: although make sure you know the difference between ' and "
<Kamion> ' is perfectly fine to quote "; I generally only use " when I actually want variable expansion within the quotes
<Kamion> er: ' is perfectly fine to quote !, I mean
<Chipzz> Kamion: the thing is, can't use '', since I have to have ' inside ''
<Kamion> '\''
<Chipzz> chipzz@Vector:~$ echo '\''
<Chipzz> >
<Chipzz> doesn't work
<Kamion> 'foo! bar! foo'\''s bar!' => foo! bar! foo's bar!
<Kamion> Chipzz: does if you're actually inside ''
<Kamion> close quotes, single backslash-escaped ', reopen quotes
<Chipzz> nasty :)
<Kamion> but sure you can use "..." if that's more convenient due to needing to have ' in the quoted text, just make sure you know the effects
<Chipzz> If enabled, history expansion will be performed  unless  an  ! appearing in double quotes is escaped using a backslash.  The backslash preceding the !  is not removed.
<Chipzz> ??
<Chipzz> The  backslash  retains  its special meaning only when followed by one of the following characters: $, `, ", \, or <newline>.
<Kamion> ah yes
<Kamion> $ set -H; echo "!"
<Kamion> -bash: !: event not found
<Kamion> use '' to quote !
<luloy> or \!
<Kamion> I forgot because I always run with set +H
<Kamion> hate historical history expansion
<pitti> yay, CD burning with n-c-b works again
<pitti> hm, write error *damn*
* pitti digs deeper
<Chipzz> Kamion: you see where my confusion comes from? :)
<Kamion> Chipzz: yeah
<ogra> pitti, i get that if its mounted before writing ...
<pitti> right
<pitti> I fixed the capacity reading so far
<ogra> (which always happens if i use a RW)
<pitti> now I got a little further
<Chipzz> chipzz@Vector:~$ set +H
<Chipzz> chipzz@Vector:~$ echo "\!"
<Chipzz> \!
<Chipzz> chipzz@Vector:~$ set -H
<Chipzz> chipzz@Vector:~$ echo "\!"
<Chipzz> \!
<Chipzz> grmbl
<Chipzz> nasty :/
<Chipzz> :(
<pitti> ogra: oh, I had gnome-mount installed, you too?
<ogra> nope
<pitti> ogra: it's just a local package on my disc which I never uploaded
<Kamion> Chipzz: just use ' and you'll be fine
<ogra> i wont touch such evil stuff :)
<pitti> ogra: odd
<Kamion> alternatively, "foo"\!"bar" as luloy suggests
<ogra> pitti, i just noted i only have two speeds in n-c-b for my dvd writer ...
<pitti> ogra: are you sure that it didn't complain about an insufficient capacity?
<ogra> cat write below 15X
<ogra> yup
<luloy> echo \!
<luloy> aha
<seb128> ogra: lshal | grep write_speeds
<ogra> i already burned and tested a x86 liveCD today ...
<seb128> ogra: lshal | grep write_speeds | grep cdrom
<ogra> seb128, no output
<ogra> ah, write_speed works
<seb128> is hal bog
<seb128> what do you get?
<ogra> but hal only has two speeds 
<seb128> that's why n-c-b has two
<ogra> so n-c-b is right
<seb128> is hal bog
<ogra> yup
<pitti> seb128: lol, no matches for volume.disc.capacity in the hal source code :/
<seb128> pitti: what did change between .6 and .7?
<pitti> seb128: hal 0.5.7 you mean? I think .7 will have volume.disc.capacity
<pitti> seb128: but it's not yet released
<seb128> pitti: have you read the upstream bug I pointed?
<pitti> seb128: I just replied to the upstream bug, btw (gnome bug 328494 )
<pitti> seb128: oh, I didn't see your pointer, I just found it myself
<seb128> k
* pitti looks at Ubugtu
<pitti> Ubugtu: *poke*
<seb128> "With HAL 0.5.7 we will get the size from HAL so it won't matter that it is
<seb128> busy."
<pitti> seb128: that's the O_EXCL thing, I fixed that already
<seb128> cool
<pitti> but that bloody thing doesn't unmount the CD
<seb128> good luck with that :)
<pitti> what's wrong with ubugtu?
<pitti> gnome bug 328494
<Treenaks> *cough*Seveas*cough*
<pitti> gnome bug 328494
<pitti> interesting
<pitti> replies to that go to #ubuntu-desktop
* ogra hands Treenaks some cough syrup
<Seveas> @quit
<Seveas> INFO 2006-02-09T16:32:12 Bugtracker.bugSnarfer called by
<Seveas>      pitti!n=pitti@ubuntu/member/pitti.
<Seveas> I think the zilla was just slow :)
<ogra> or the pitti was to fast :)
<pitti> Seveas: but why do replies go to #u-desktop?
<pitti> Seveas: and it tried to get the malone bug
<Seveas> they don't....
<pitti> they did for me
<pitti> gnome bug 328494
<pitti> Seveas: look in #u-desktop
<pitti> still happening
<Seveas> nothing...
<pitti> -Ubugtu- Error: Error getting Malone bug #328494: Bug does not exist
<Seveas> that's a notice :)
<Seveas> notices only get send to the user that caused them
<pitti> ah, I see
<pitti> xchat bug, then
<Seveas> if it shows up in #u-d, slap your irc client
<Seveas> but it should not try to get the malone bug
<seb128> pitti: should I drop gstreamer0.8 from supported too?
<seb128> pitti: I guess it's a "yes" but just to be sure :)
<pitti> seb128: yes, please
* ogra wonders if dholbach slowly turns into an advertisement mailbot :)
<seb128> thank you
* dholbach strangles ogra slowly.
<ogra> heh
<dholbach> ogra: I even advertised it in the Dapper Flight 4 release notes. :-)
<ogra> :)
<ogra> where are these ? JaneW wanted to copy them for edubuntu flight 4
<seb128> pitti: no need to list the stuff which are Depends of apps like plugins-good, right?
<pitti> seb128: no, that would be actively bad
<pitti> seb128: ideally it shouldn't appear at all
<dholbach> ogra: http://wiki.ubuntu.com/DapperFlight4
<ogra> JaneW, ^^^ 
<pitti> seb128: but I guess there might be some tools which aren't dependency, but which we ant
<dholbach> ogra: that's not really unexpected URL, is it? :)
<pitti> s/ant$/want/
<seb128> pitti: desktop: gstreamer0.10-alsa gstreamer0.10-esd gstreamer0.10-plugins-base-apps, supported: gstreamer0.10-doc gstreamer0.10-plugins-good-doc
<ogra> dholbach, nope, not really ... but i'm busy with CD stuff ... no time to look up wiki stuff
<JaneW> ogra: reference not copy ;)
<dholbach> ogra: I'm busy too. :)
<ogra> JaneW, right 
<pitti> seb128: g-control-center already needs -alsa
<JaneW> ogra: may turn out to be the same thing tho...
<ogra> dholbach, hey, you have time for running bugdays :P
<ogra> yup
<pitti> seb128: totem, too
<hno73> Who do I complain to when kubuntu takes over my gnome desktop? Riddell :)  After the latest update and reboot, both start at once :-(
<pitti> seb128: the rest looks fine
<seb128> pitti: g-c-c Suggest it, totem has alsa | audiosink
<ogra> hno73, there are plenty complaints in -users already
<ogra> its also the other way around 
<pitti> seb128: that's why I wouldn't explicitly put it into desktop
<hno73> ogra: ok, that's fine then :)
<ogra> heh
<hno73> I'll just wait and update in a while
<seb128> pitti: but we want it installed by default, no?
<pitti> seb128: we will anyway
<seb128> pitti: so it should be listed by desktop
<pitti> seb128: as I said, lots of packages depend on it
<seb128> pitti: there is an issue, -good Provides -audiosink
<seb128> and packages do Depends on alsa | audiosink
<hno73> In the meantime I have to report on some more serious breakage in at-spi (in malone)
<seb128> pitti: so if -good if installed, alsa will not be
<pitti> seb128: well, ok, just add it then
<pitti> doesn't matter much anyway
<seb128> pitti: I'll work with the Debian maintainer to fix that but I add it for now
<seb128> we can still fix it later
<pitti> seb128: please also merge your changes to {k,edu,server}buntu
<dholbach> hno73: breakage? at-spi?
<seb128> pitti: I've to learn to do that :)
<Seveas> <pitti> gnome bug 328494
<Ubugtu> gnome bug 328494 in cd-burner "Burning of CD-RWs stopped working" [Normal,Unconfirmed]  http://bugs.gnome.org/show_bug.cgi?id=328494
<hno73> dholbach: yes, it completely breaks my X
* pitti applauds Seveas, thank you!
<dholbach> hno73: oh?
<hno73> after installing at-spi and restarting X it won't start, cycles through the startup process 6 times and gives up
<dholbach> hno73: Ugh!
<hno73> I'm using the nvidia drivers, perhaps I should try without
<hno73> so I can't test gok or gnopernicus
<dholbach> Yeah maybe that makes it better.
<hno73> OK, I'll try that to start with
<hno73> I'm assuming I can just unistall the nvidia driver and it will fall back to nv?
<ogra> you need to revert your xorg.conf manually
<hno73> ah, lovely :)
<freeflying> pitti: hi
* pitti waves to freeflying 
<freeflying> pitti: We want modify ttf-arphic-uming for displayy chinese better , is that ok ?
<freeflying> s/displayy/display
<pitti> freeflying: sure, go ahead :)
<freeflying> pitti: we prepare put the configure file into /etc/fonts/conf.d/
<Riddell> hno73: what happens?
<ogra> Riddell, kicker starts on gnome desktops
<ogra> and gnome panel on kde desktops ...
<ogra> according to ubuntu-users
<Riddell> cool :)
<ogra> heh
<Riddell> but should be fixed in the updates I uploaded this morning
<hno73> classic cross-marketing ploy ;)
<jsgotangco> hiya hno73 
<hno73> jsgotangco: hi
<ogra> Riddell, hno73, https://lists.ubuntu.com/archives/ubuntu-users/2006-February/066772.html
<jsgotangco> best bug ever
<ogra> "...is Canonical going for something new and exciting?" 
<dholbach> something new and exciting! :)
<ogra> hehe
<Riddell> I'll reply to him
<Tm_T> =)
<jsgotangco> yeah reinvent bluecurve will ya
<Tm_T> Riddell: indeed lovely bug =)
<ogra> jsgotangco, but without the theme :)
<jsgotangco> oh its getting fixed? and i was really enjoying the moment that kicker konquered the desktop
<ogra> oh, another dholbach ad in -motu :)
<dholbach> ogra: you have too much time to read the mailing lists, if you ask me
* ogra sees dholbach with one foot in the marketing team already :)
<ogra> dholbach, prolly ...
<ogra> but in the end i have just a working mail notification that notifies me about mail from important people ;)
<dholbach> ogra: I was just referring to your lack of time :)
<seb128> Riddell: no objection if I drop the gst0.8 stuff you commented from kubuntu seed?
<seb128> Riddell: I just dropped them for ubuntu and since you already commented them for kubuntu
<blueyed> Since yesterday I cannot start wine on dapper. It just says "killed". Should I open a bug on malone (with strace output) or is it supposed to be fixed with new package uploads anyway?
<dholbach> blueyed: you might want to ask \sh_away
<dholbach> blueyed: which version is it?
<blueyed> dholbach: both with 0.9.5 from dapper and 0.9.7 from sf.net
<dholbach> blueyed: hm, you might have more luck with an upstream bug report then.
<blueyed> dholbach: hmm, but it worked yesterday. Must have been some dapper update.
<Riddell> seb128: go ahead
<seb128> Riddell: do you want the gst0.10 listed but commented?
<Riddell> seb128: yeah, please
<seb128> k, doing that now
<dholbach> blueyed: Sorry, I have no idea, what could have broken it - in any case: file a bug report.
<Diziet> sivang: You should install autopkgtest; it has a higher version number.  Just as soon as it's through NEW in both places I'll ask for autodebtest to be removed.
<blueyed> dholbach: Ok. Thanks. Should I ask sh also to add 0.9.7 instead of 0.9.5, because of at least one ugly bug where icons do not show up? File a malone report for that, too?
<dholbach> blueyed: That has a different process - we're in UpstreamVersionFreeze at the moment.
<dholbach> blueyed: https://lists.ubuntu.com/archives/ubuntu-motu/2006-January/000177.html has more information on it.
<MisterN> hi
<WaterSevenUb> kamion,in which inbox do u want to receive a fresh .po ?:)
<mvo> Riddell: did kuser recently traveld from main to universe?
<Riddell> mvo: yes
<Riddell> it's old and not really maintained
<Riddell> and we use guidance now
<mvo> Riddell: it's fine, just confirming 
<blueyed> dholbach: is \sh the maintainer of the wine package? Should I ask him to send you the required info for the UVF exception?
<gicmo> hey hey
<dholbach> blueyed: he more or less took care of it, yes.
<dholbach> blueyed: shouldn't hurt to talk to him. :-)
<WaterSevenUb> Kamion, the debian-installer one.
<gicmo> Kamion, there .. I have been told you are the guy to talk to about (I c&p)  so the problem we have is that we want to ship a ubuntu cd with notebooks and we also want to ship an additional cd with e.g. speical drivers or software that should get additionly installed
<sivang> yo gicmo :)
<gicmo> hey hey sivang 
<gicmo> sivang, how is it going?
<seb128> k, seeds updated for gstreamer0.10
<seb128> pitti: thanks for the help on that :)
<pitti> seb128: you're welcome
<ogra> Mithrandir, ping
<ogra> Mithrandir, amd64 live has a broken xserver for me ... fails with "sh: getconfig: command not found"
<Mithrandir> ogra: the live cd is broken, I said a few hours ago.
<ogra> ah, dmaned, missed that
<ogra> *damned even
<ogra> all arches ? or doesn it make sense to test the others ? 
<ogra> *does
<sivang> gicmo: fine, fine, busy , what about you?
<Mithrandir> squashfs is broken, so unless you're _really_ bored it doesn't make any sense to test them.
<Mithrandir> your /dev/null is broken in static /dev in the squashfs which makes the xserver-xorg configure script exceedingly unhappy
<ogra> ok
<mvo> ping Diziet
<mvo> infinity: I got a conffile prompt for /etc/mkinitramfs/initramfs.conf today during test breezy->dapper upgrade. is this a known issue?
<mvo> Diziet: firefox asks me conffile questions during breezy->dapper upgrade for /etc/firefox/firefoxrc (and a bunch of others)
<seb128> mvo: did you had the details area open?
<seb128> mvo: I got my conffile double prompt issue on that conffile :p
<mvo> seb128: no, that was with the dist-upgrade tool
<seb128> ah ok
<mvo> pitti: tetex-bin has a failed postinst. didn't we looked into that in london?
<pitti> mvo: still? darn
<mvo> pitti: I have a change from 24.1, other than that there seems to be no new version in dapper
<pitti> mvo: I didn't change tetex-bin, just xmltex
<mvo> pitti: oh, ok. checking the error now 
<pitti> which was the culprit IIRC
<mvo> pitti: hm, xmltex is not installed and wasn't installed during the upgrade
<pitti> any recipe for reproducing?
<mvo> dist-ugprade from breezy to dapper ;) 
<pitti> mvo: I can take a look at it later/tomorow, but I'd like to finish repairing n-cd-burner
<mvo> no, not yet
<mvo> take your time, I will have a closer look in the meantime
<mvo> (well, for a bit, I will leave for hockey later)
<ogra> seb128, i'm updateing the edubuntu metapackages, do you want me to do that for ubuntu too ? 
<seb128> to change what?
<ogra> to pull in the seedchange
<seb128> ah, the packages according the seeds change
<seb128> yeah, feel free to do it
<ogra> oki
<ogra> nice trade ... 20 removals for 3 additions :)
<sivang> is anyone running vmware on breezy 64bit successfuly ?
<mvo> pitti: fun, after the first failure, it installs fine on the second run. so maybe just a missing predepends 
<pitti> mvo: eek, predepends
<pitti> mvo: I'll try it again in my pbuilder
* mvo goes to play some hockey now
<Diziet> Ah, good, my ff has built this time.  Silly me for yesterday's.
<pitti> yay
<Kinnison> Diziet: always good :-)
<Diziet> pitti: And yes, I put your CVEs in this time too. 
<pitti> saw it, thanks 
<LaserJock> dholbach: I really liked you Hug Day annoucement. I would really like to get a handle on science bugs for MOTUScience
<dholbach> LaserJock: cool! Add something to wiki.ubuntu.com/UbuntuBugDay
<LaserJock> dholbach: I will, I am wondering though how MOTU Teams should handle bugs? I like they way the desktop team has https://launchpad.net/people/desktop-bugs/+packagebugs
<LaserJock> dholbach: but should MOTU teams be listed as bug contacts?
<dholbach> LaserJock: they could
<dholbach> LaserJock: that's something we maybe should decide on in a MOTU meeting
<LaserJock> dholbach: I am worried that MOTU as a whole would start missing bugs if a MOTU Team is the bug contact
<dholbach> LaserJock: at the moment they are all assigned to 'motu', no?
<LaserJock> dholbach: that is why I liked the idea of MOTU Teams in LP being a subset of MOTU
<dholbach> (apart from some, which are assigned to subteams)
<dholbach> But you're right, we need to find a better way.
<LaserJock> dholbach: right, but I would like to change the bug contact to MOTUScience for science related packages for instance
<dholbach> (More people first.) :)
<dholbach> Yeah, sure.
<dholbach> If you have a list of packages, you can simply do that.
<LaserJock> dholbach: but then I also want to make sure that universe-bugs gets emailed to
<LaserJock> dholbach: I have a list of ~450 source packages for MOTU Science
<dholbach> That's some work, then.
<LaserJock> dholbach: do you know how many desktop has?
<dholbach> I can't tell exactly.
<dholbach> https://launchpad.net/distros/ubuntu/+source/<source package>/+subscribe   is the way
<LaserJock> dholbach: the problem especially is that right now tritium is our only member with Universe upload rights :(
<dholbach> You'll move on and have more members soon. :)
<LaserJock> dholbach: so I we need the rest of the MOTU involved as far as uploading our patches, etc.
<dholbach> Yeah, subscribe 'motureviewers' to those bugs.
<dholbach> I'm off for some time now - or did you want to talk about something else?
<LaserJock> no, I just wanted to say that I'll be looking forward to the Hug Day ;-)
<dholbach> Yeah! Woohoo! :-)
<dholbach> I'm happy to be seeing you there. :-)
<dholbach> *wave*
* LaserJock hugs dholbach
<LaserJock> one for the road ;-)
<Treenaks> BenC: does linux-source-2.6.15_2.6.15-15.21 fix the 'mmc2: DMA end' log-spam for sdhci too? or should I file a bug for that?
<jbailey> mdz: ping?  Can you take a look at bug 29768?  We've solved the problem for dapper, but I need guidance on previous releases.  To update these means a whole glibc upload.  Not a horrible thing, but something that I tend to like to avoid.
<Ubugtu> malone bug 29768 in glibc "Australian timezones incorrect for 2006" [Normal,Confirmed]  http://launchpad.net/bugs/29768
<jbailey> Ubugtu: thanks.
<ogra> jbailey, youre very friendly to the bugbot :)
<Burgwork> ogra, he is canadian. It is unavoidable
<ogra> lol
<Treenaks> ogra: You never know.. it might save his life when the Robot Revolution comes :)
<ogra> hehe
<jbailey> ogra: When they get smart enough and make us their slaves, I want them to always remember this.
<ogra> its logged, you can always point them there, true :)
<jbailey> ogra: I suspect google will be the brain behind it all.  I'm sure they'll remember, sort of like a child remembers from the age of 2 that licking the light socket was a bad idea.
<ogra> LOOOL
<Treenaks> jbailey: you mean you can upload new glibcs to googlenet? :)
<jbailey> Treenaks: Nah, with hct and bzr branch tracking, they won't need me to upload it.
<Treenaks> true
<mdz> jbailey: I have no objection to a glibc upload to *-updates to fix it
<mdz> with the customary caution
<jbailey> mdz: 'kay.  warty, hoary and breezy?
<soumyadip> can anyone tell me how to bring up scim language menu in dapper ?
<mdz> jbailey: yes
<ogra> siretart, there is no "when battery is low" mode in g-p-m
<siretart> ogra: but there is a slider in the 3rd tab, where I can define a limit for 'battery is low'
<ogra> it shall only prevent you from running out of battery and preform actions if the battery is critical
<siretart> whats this slider for?
<Treenaks> siretart: it shows a notification
<Treenaks> siretart: 'YOUR BATTERY IS CRITICAL! SHUTDOWN NOW OR LOSE!'
<ogra> Treenaks, they are different (low vs critical)
<siretart> Treenaks: interesting. this did not happened for me, it just shut down for me without any chance to save my posting
<ogra> low should pop up a warning 
<ogra> and critical performs an action 
<ogra> (low doesnt)
<ogra> the action is selectable in the options tab
<siretart> ogra: how can I debug hal the most painless way?
<Treenaks> ogra: there is no action 'nothing'
<ogra> huh ? which version are you running Treenaks ?
<ogra> there is a "Do Nothing" action
<Treenaks> ogra: there wasn't yesterday, it might be better today
<Treenaks> ogra: hm, ok, I was thinking of the wrong selector
<ogra> there was no change to the UI since weeks ...
<Treenaks> ogra: the hibernate/suspend thingy
<ogra> siretart, hald has a debug option ... but its probably easier to run dbus-monitor --session and check the dbus traffic
<siretart> ogra: thanks. will investigate this and search for the bug
<siretart> there is no point in filing a bug that it crashed for me and there must be a bug somewhere
<siretart> yet ;)
<ogra> siretart, it did crash ? 
<ogra> you didnt say that 
<siretart> ogra: it crashed my notebook. 
<ogra> it shut down your notebook ... thats not a crash
<siretart> mom
<ogra> s/shut/shot/
<siretart> phon
<HiddenWolf> Hm, I just accidentally made my system suspend.
<HiddenWolf> System went black right away, without any indication, and I could not get it out. :/
<Treenaks> That's 2 bugs: unsuspending should work, and the system shouldn't suspend accidentally
<siretart> ogra: I think there was a very very short lived message box about my session beeing saved. 
<ogra> Treenaks, thats only one bug ... note the "I just ... made" 
<HiddenWolf> Treenaks: I have the suspend key set up in gnome-keyboard as my "lock screen" key
<HiddenWolf> it didn't lock, but suspended
<ogra> siretart, whats your "Running on batteries" slider set to ? 
<siretart> ogra: on the next boot, my session was restored however. so g-p-m didn't really crash. it 'just' shut down my laptop without any warning
<HiddenWolf> And yes, I just filed that.
<ogra> especially the "put computer to sleep after" one ?
<siretart> ogra: put display to sleep after 5 mins, put computer to sleep after 20mins
<ogra> so i guess you worked 20 mins =
<ogra> ?
<ogra> before that happened ? 
<siretart> ogra: about that time, I was writing my email in the shell. I was about 20mins without AC, I think
<ogra> yup... and i guess your sleep type is hibernate ? 
<ogra> (in the options tab)
<siretart> no, it is suspend, because of bug 29634
<Ubugtu> malone bug 29634 in linux-source-2.6.15 "usb dead after hibernate/resume on Thinkpad R40-2772-B3G" [Normal,Confirmed]  http://launchpad.net/bugs/29634
<ogra> hmm, then thats a bug, but the rest of the behavior was perfectly right according to your settings ... i guess we need a default that sets both sliders to "never" to not surprise users 
<HiddenWolf> ogra: hm, gpm seems not to respect my wishes on those settings
<HiddenWolf> ogra: setting the monitor setting to 1 minute nothing happens.
<ogra> HiddenWolf, but you have gnome-screensaver installed and running ? 
<HiddenWolf> ogra: yes
<ogra> and your display is dpms enabled ? 
<ogra> note that g-p-m only cares for dpms ... 
<HiddenWolf> ogra: it's a dell 2405 lcd, from last year.
<HiddenWolf> ogra: it should be.
<ogra> does it ususally shut down the display power ? 
<HiddenWolf> yes, after a time.
<HiddenWolf> I've been having issues with it since dapper.
<HiddenWolf> it shutting down the monitor while watching a movie over the last few days.
<HiddenWolf> not today, for some freak reason.
<HiddenWolf> but g-p-m seems to have no effect.
<ogra> totem works fine with gnome-screensaver, it shouldnt save the screen if you watch a movie ...
<siretart> ogra: thats a great idea
<ogra> other movie players miss the necessary fixes to talk to the screensaver yet 
<siretart> ogra: I mean to put both sliders to 'never' by default
<HiddenWolf> ogra: I used totem-xine
<HiddenWolf> ogra: and it sure as hell did. Made me get off the couch every half-hour. :)
<ogra> HiddenWolf, and it saved the screen anyway ? 
<HiddenWolf> ogra: yes.
<HiddenWolf> ogra: of course, today it seems to work, sorta.
<ogra> hmm ... that shouldnt happen
<siretart> ogra: I have another problem with gnome-screensaver: if I wake up from sleep, my screen is not locked any more. Is this a known problem? is this in acpi-support or gnome-screensaver?
<ogra> its based on the g-s-s default setting ...
<ogra> if you dont have lock checked, it wont lock ...
<ogra> and we changed it to nopt lock at all on pittis request
<HiddenWolf> ogra: I've got my monitor setting to 1 minute now. and it didn't send it to sleep. I'll put it to 30 minutes like it was, and see if it does.
<HiddenWolf> ogra: that might be it.
<siretart> ok. lets retry
<siretart> ah, you're right. now it is locking correctly
<siretart> thanks
<siretart> ogra: last thing for today: is xscreensaver going to be demoted to universe?
<ogra> its doing all the right things for you itr seems, just the defaults are a bit insane :)
<ogra> the binary, yes
<ogra> the hacks will stay in main ...
<siretart> why? is it that big crack?
<ogra> nope, but we dont need to support two binarys of the same app
<siretart> ah, ok, I understand
<ogra> and g-s-s is essential for g-p-m
<siretart> ogra: then g-p-s needs a depends on g-s-s, no?
<ogra> nope 
<siretart> but you just said it was essential!
<ogra> you can use g-p-m without g-s-s ... it just doesnt do the display tasks (and doesnt show display UI elements)
<ogra> but you cant use g-p-m with x-s-s 
<siretart> ogra: so it should be at least in Recommends, no?
<ogra> so its essential for display stuff ... but not for the functionallity ...
<ogra> even a suggests i think 
<ogra> but not a hard dependency
<siretart> ogra: anyway, would it be possible to change the depends for ubuntu-desktop from 'gnome-screensaver' to 'gnome-screensaver | xscreensaver'? I think about users who have universe enabled and want to use xscreensaver and no g-p-m at all
<siretart> and have ubuntu-desktop installed for upgrade convinience
<ogra> thas not how the metapackages work ...
<siretart> what point did I miss?
<ogra> but i could think about something like totem does
<ogra> the metapackages accept no "or" in dependencys
<siretart> they do not? why not?
<siretart> (I really like to understand this point)
<ogra> because the seeds dont accept them ... i didnt write this setup ... 
<siretart> ah. I see
<ogra> but you can do an additional metapackage ... like totem 
<_ace> hi
<ogra> which indeed brings further maintenace work ...
<_ace> ogra: am i disturbing you??
<ogra> and i'm not sure if x-s-s justifies that 
<ogra> just to prevent -desktop from getting removed ...
<ogra> which is really no biggie 
<ogra> _ace, nope, why should you ...
<siretart> ogra: well, x-s-s offers a lot more options/preferences a user can tweak. ubuntu will be blamed for trading x-s-s with g-s-s. 
<ogra> _ace, oh, i didnt see the query ... i have about 50 tabs open ...
<siretart> heh
<ogra> siretart, but its no prob to install x-s-s
<siretart> ogra: perhaps we can have a meta-package in universe, which provides/conflicts gnome-screensaver but depends on x-s-s
<siretart> ogra: having both installed is, well, confusing at least. so if I want to use x-s-s, I'd like to remove g-s-s. And now ubuntu-desktop get's deinstalled, with big potential to break upgrading to the next release
<ogra> having both installed does break 
<siretart> dholbach: (moving discussion from -motu here, lucas is here as well): how do I check if dmix is enabled for me?
<dholbach> https://launchpad.net/distros/ubuntu/+source/gnomemeeting/+bug/22488
<Ubugtu> malone bug 22488 in gnomemeeting "When gnomemeeting is running no other programs can play sound" [Normal,Unconfirmed]  
<ogra> doesnt ekiga just use gstreamer ? 
<siretart> dholbach: ok, then dmix works  for me, but bug 30578 is still valid
<Ubugtu> malone bug 30578 in ekiga "Ekiga uses ALSA layer, but sound card is blocked by esd" [Major,Confirmed]  http://launchpad.net/bugs/30578
<siretart> ogra: no, it seems to use alsa directly
<ogra> ouch
<ogra> tahst bad if your audiosink is esd indeed
<dholbach> It'd make sense to follow up on the upstream bug (lucas found) with the information of the bug.
<siretart> where to choose the default audio sink?
* dholbach is out for a dogwalk.
<dholbach> bbl
<dholbach> *wave*
<siretart> cu dholbach 
<dholbach> cu siretart
<ogra> dholbach, thats pretty pointless if it doesnt use gstreame though ... the autosink pitti wrote is pretty uniqe and does expect that everything uses gstreamer
<dholbach> ogra: hm?
<ogra> go for your dogwalk ... 
<ogra> we can talk later about bugs ...
<siretart> ogra: do you really expect every program to use gstreamer? there are so many legacy apps out there which use alsa directly
<dholbach> ogra: I have no idea, what you are talking about and I didn't suggest much apart from following up on the upstream bug. :)
* dholbach walks the dog.
<ogra> dholbach, which i said is pointless if ekiga doesnt use gstreamer at all ...
<ogra> siretart, yes, but we dont expect apps to use esd if possible ...
<dholbach> ogra: which upstream bug do you refer to?
<siretart> ogra: does esd support recording at all?
<ogra> siretart, i think there are client tools in esound-clients to do that  ...
<ogra> dholbach, nevermind, i'm up to long already, i read "Ekiga uses esd, but sound card is blocked by ALSA"
<ogra> sorry ...
* ogra stops for today
<dholbach> ogra: don't worry - i just didn't get it :-)
<siretart> ogra: no, it is the other way round. ekiga doesn't work because esd blocks the soundcard
<ogra> siretart, yes
<lucas> the upstream is only similar, it's not the same bug
<Kamion> siretart: honestly I think it would be better for users in the long run to make xscreensaver and gnome-screensaver cooperate better with each other so you can have both installed
<Kamion> siretart: that way if different users on the same system prefer a different screensaver program, they can have it
<siretart> Kamion: thats right. 
<Kamion> this conflicts business is just a pain in the arse
* siretart ponders how they could cooperate nicely
<siretart> first problem is that there are 2 screensaver entries in the Settings menu. this is really confusing
<siretart> next, how to choose which screensaver should be active, and how to prohibit that the 2 don't run at the same time
<seb128> GNOME starts gnome-screensaver by default and try xscreensaver if the first is not installed
<siretart> seb128: so gnome-session needs to be enhanced so the user can choose which screensaver he wants to use, right?
<seb128> "need" no
<seb128> but you could do that probably yep
<seb128> patches are welcome
<siretart> well, in order to make the two screensavers cooperate nicely, that is
<seb128> I don't think upstream or desktop team is going to work on that
<seb128> they do cooperate nicely
<siretart> sure. wouldn't this be a nice bounty? ;)
<seb128> xscreensaver is ignored if gnome-screensaver is installed
<seb128> no
<seb128> it's not useful enough to be a bounty
<siretart> j/k
<seb128> and it's probably an 1 hour work for any contributor which knows how to code a bit
<pitti> hi again
<seb128> wb pitti
<siretart> wb pitti 
<ubijtsa> good evening..
<ubijtsa> who would be the right person to talk to about /etc/security/limits.conf ?
<mdz> this channel or the ubuntu-devel mailing list
<ubijtsa> ok, lesse if anyone bites... I had a mail exchange with someone off LKML, about the cdrecord debacle..
<ubijtsa> there is a setting, RLIMIT_STACK, that can be tuned through /etc/security/limits.conf
<ubijtsa> would it be an idea to set a default on that perhaps?
<ubijtsa> it was suggested that 512kB would be a better setting than the default 8MB
<ubijtsa> I have done some light testing this evening, and the memory usage drops not an unsignificant amount for a Gnome or KDE desktop
<ubijtsa> it's just an idea...
<mdz> how are you measuring memory usage?
<ubijtsa> Log out and back in and the VSZ of your desktop apps should drop
<ubijtsa> dramatically...
<ubijtsa> bummer
<ubijtsa> scratch that line
<ubijtsa> Just looking at the overall memory consumption of the system using System Monitor
<ubijtsa> The blue part of the graph shrank back noticably. I will leave running and will test with different applications if any adverse effects.
<mdz> VSZ isn't a good indicator of memory usage
<mdz> I don't know what the system monitor uses
<ubijtsa> Okay. I can save the data from /proc/meminfo, with it enabled and disabled. That should give some idea of specific numbers.
<mdz> even if the process maps an 8M stack, the memory isn't allocated unless it's actually used
<ralph_> mvo: I heard you are the one to talk to about a dist-upgrade
<ubijtsa> mdz: let me collect stats on my box for the session I use. if I can say how much % difference it makes it may be better.
<mvo> ralph_: yes
<ralph_> Just tried an upgrade from 5.10 to dapper.
<ralph_> apt-get update, apt-get upgrade, apt-get dist-upgrade
<mvo> ralph_: we are writing a tool for this
<ralph_> no errors
<mvo> ralph_: no errors? nice :) so everything worked fine?
<ralph_> Now I tried to reboot and the system stops the boot process somewhere. I want to contribute and post the bug somewhere. What do I do.
<ralph_> (at least I got the consoles to work with)
<mvo> ralph_: so no X ? or problems mounting root
<mvo> that is, problems mounting the root fs?
<ralph_> no x but all the consoles. Can't change the inits, can't check alt-f8 to look at the messages.
<mvo> ralph_: can you please send me a copy of your initramfs
<ralph_> I'd like to, but how do I do that?
<MisterN> n8
* mvo goes to bed
<dholbach> night mvo
#ubuntu-devel 2006-02-15
<dholbach> whiprush: thanks for fridge-ing
<jsgotangco> mr. fridge!
<jsgotangco> lol my interfaces switched names
<jdub> roflcopter
<jsgotangco> wonder why it did that
<jsgotangco> (after an update)
<Seveas> just to piss you off ;)
<jsgotangco> lol
<jsgotangco> at 8am? yeah it was successful
<Seveas> it's keybuks way to say PNAH! ;)
<Seveas> jsgotangco, https://lists.ubuntu.com/archives/dapper-changes/2006-February/006062.html
<jsgotangco> "nclude support for renaming of network interfaces."
<Burgwork> jsgotangco, append to that "at random, just for fun"
<jsgotangco> it sure did  start my day with a WTF
<Seveas> the other part of that one may just have silved the bug I had today trying to install it on a vmware guest
<Seveas> so I'm waiting for the daily install cd to pop up :)
<squinn> Question. I'm a regular user, but I think y'all will know this better than those over in #ubuntu.
<squinn> I recently went back to Ubuntu. Today, actually. In the process of not having Ubuntu, my email was hacked and the password was changed. So I created a new Launchpad account, but it won't let me edit the Wiki to redo my bio.
<squinn> Anyone know why?
<raphink> squinn: why not ask in #launchpad rather?
<squinn> Didn't know it existed. Thank you.
<raphink> :)
<Mez|ZzZ> mdz ping
<jelkner> can i ask a question here about setting up zope3 instances for developement in a user's home directory?
<jelkner> i tried asking on #ubuntu, but that is a useless channel
<Mez> anyone from core-dev here?
<Mez> I need to ask a question
<Mez> and would appreciate some input from a more experienced dev
<raphink> jelkner: do you think anyone wants to answer people who are as friendly as ` i tried asking on #ubuntu, but that is a useless channel` ?
<raphink> jelkner: please be respectful to _volunteers_ who give their time on #ubuntu to answer your questions
<jelkner> raphink: my apologies, but it is
<raphink> jelkner: for many things it is not
<raphink> but #ubuntu is not a paid hotline
<jelkner> raphink: i'm not in any way disparaging the volunteers, who have my utmost respect
<raphink> and is to be treated as what it is : a communauty help channel
<raphink> s/communauty/community/
<raphink> ok
<jelkner> but in all honesty, the system is overloaded and not very effective
<jelkner> there were 600+ people there
<raphink> there are lots of other specialized channels
<raphink> for specialized questions
<jelkner> *a lot* of noise
<raphink> yes I know jelkner 
<raphink> ;)
<jelkner> and very difficult to get help
<raphink> jelkner: I often talk to people in pv to solve hard pbs
<raphink> ;)
<jelkner> so forgive me for expressing my frustration
<raphink> because #ubuntu is too hard to read
<jelkner> but i'm trying to be an effective volunteer myself, and i can't get the info i seek
<raphink> jelkner: iirc ajmitch is our zope specialist here
<raphink> :)
<raphink> ping him
<infinity> Mez: Fire away.
<jelkner> ajmitch: would you be so kind as to answer a zope3 question for me?
<Mez> ah :D lol - I just msgd you
<Mez> infinity: at the moment - scim in breezy is tragically broken.
<Mez> a lot of people are requesting a backport.
<Mez> now - usually this wouldnt be possible - due to C++ ABI transitions
<jelkner> raphink: i'm thinking of filing a bug report, which might be the simplest way to address this problem?
<Mez> however-  from recent work on the KDE backports - we've worked out a way to replace the control file for breezy
<Mez> so - it would be possible to backport scim and make a lot of people happy
<raphink> jelkner: might help
<Mez> however - this would mean causing a delta between ubuntu and debian solely for backporting this package
<Mez> should I go ahead and make the changes and request a backport? or is creating the delta not worth it
<jelkner> raphink: are all bugs in malone these days?
<infinity> Mez: I don't like the sounds of that.  Can we not find out WHY it's "tragically broken" in breezy and fix it?
<raphink> jelkner: iirc yes
<raphink> hmm celestia crashes with nvidia card here :s
<Mez> infinity, apparently it's just an old buggy version.
<raphink> very badly
<Mez> since then theres been a lot of work on scim because they've had data to work from etc etc.
<infinity> Mez: Not to mention that rewriting control during build is hopelessly sketchy.
<Mez> infinity, true - but not that hard to do - it's working for KDE backports
<Mez> (depend on base-files - check lsb_release for version - and then replace control file as neccessary)
<Mez> It's really only to replace the package name changes for the c++ ABI transition
<infinity> Oh, I know HOW to do it.  That doesn't make it any less wrong.
<jelkner> raphink: what does iirc mean?
<Mez> infinity, I know it's wrong... 
<raphink> jelkner: if I remember well
<Mez> infinity, but well - we're not allowed to do manual backports
<jelkner> thanks!
<Mez> hmm
<Mez> unless I can convince mdz to let me build a package for -updates
<infinity> Well, can we get a handle on what "tragically broken" means?
<Mez> one sec
<Mez> lemme get a user who can explain
<Mez> freeflying - care to explain ?
<freeflying> Mez: I don't think scim broken in breezy at all 
<Mez> o_O
<Mez> going completely against what I've been told by lots of other people :D
<freeflying> Mez: as u know the changes in dapper is just the renanme of binary package 
<Mez> freeflying, yes - but from what I've heard - the breezy version of scim crashes nearly all the time
<freeflying> and we have test that scim-1.4.2 can works fine in breezy 
<Mez> freeflying, I'm on about whats wrong with the version currently in breezy
<Mez> not the one in dapper
<freeflying> Mez: the changelog of scim-1.4.4 have pointed that up-to-date release havs fixed some bugs 
<Mez> infinity from what I can gather - it causes problems with firefox and a few other packages
<freeflying> Mez: sure 
<freeflying> Mez: like acobat , realplay using libstdc++5
<Mez> what other problems does it cause?
<freeflying> Mez: and the version is too out-of-date in breezy 
<infinity> freeflying: Out of date versions aren't really a concern, I want concrete bugs.
<Mez> what do you mean by "too out of date"
<infinity> So far, I see this one: https://launchpad.net/distros/ubuntu/+source/scim/+bug/2565
<Ubugtu> malone bug 2565 in scim "[Breezy Colony 5] scim refuses to start, scim-setup segfaults" [Critical,Needs info]  
<freeflying> scim in breezy is 1.0.2 , and upstream release now is 1.4.4
<infinity> And if I had to guess, I'd bet that could be fixed with some reasonably small updates.
<infinity> But... <shrug>
<infinity> Mez: If you want to do the control hack and request a backport, go ahead.  I won't stop you.
<infinity> Mez: It seems easier at this point to do that than to do a proper bugfix upload to -updates.
<Mez> infinity, I'd rather you said that you'd approve :D
<Mez> infinity - or a "backport" to -updates
<Mez> lol
<Amaranth> infinity: _anything_ is better than "doesn't work at all and makes all my apps die"
<infinity> Mez: A "backport" to -updates is out of the question.
<Mez> infinity, i can understand that
<infinity> Amaranth: It works for some input methods, and some others break.  That's not "broken for everyone, OMG, update it now!"
<mdz> Mez: ?
<Mez> mdz: was pretty much the above that was just discussed with infinity - though I'd like your opinion on it too
<mdz> what's your question?
<Mez> (control hack for scim to make it backportable so people with scim problems (seems to be a lot)) have a working version of scim
<mdz> do you have a diff for review?
<Mez> mdz: I will in a few moments
<mdz> ok, mail it to me and I'll have a look
* infinity -> lunch.
<wasabi> During the last update... something changed...
<wasabi> that caused kicker to start when I logged into gnome.
<nekohayo> I'd like to know, there is an "espresso" package in the repositories and an "ubuntu-express".. which one is the "good" one?
<nekohayo> was ubuntu express renamed to espresso?
<Mez> mdz: debdiff or just package?
<mdz> debdiff please
<Mez> no probs
<Mez> emailing to mdz@ubuntu.com
<Mez> mdz: winging it's way to you now
<mdz> infinity: how did the security builds go?   everything running smoothly now?
<mdz> Mez: it would be simpler to leave the control file alone on dapper, and only overwrite it for breezy
<mdz> I assume control-dapper is identical to the current control
<Mez> yes
<mdz> and use lsb_release -c rather than grepping /etc/lsb_release
<infinity> mdz: Ish.  Still need some work on drescher to process the uploads, but they're getting that far now..
<infinity> mdz: Mail has been sent to the LP folk responsible.
<Mez> mdz:         cp debian/control-dapper debian/control
<Mez>         -grep -q breezy /etc/lsb-release && cp debian/control-breezy debian/control
<Mez> grr
<Mez> damn klipper
<Mez> lsb_release -c | cut -f 2 | grep dapper && cp debian/control-breezy debian/control
<infinity> Mez: lsb_release -c -s
<infinity> Mez: No need to cut.
<Mez> ah :D just grep then :D
<Mez> cheers
<infinity> Mez: [ `lsb_release -c -s` = "breezy" ]  && cp ...
<infinity> Mez: That seems more readable.
<Mez> mdz: with those changes am i fine to upload ?
<Mez> infinity - cheers
<mdz> Mez: yep
<Mez> cool :d nice to hear
<Mez> and finaly we'll be able to backport it
<Mez> minghua will be happy
<jsgotangco> yay
<atie> jsgotangco, I'm here.
<freeflying> atie: hi
<jsgotangco> Mez, atie can also help you
<jsgotangco> (Korean Team)
<atie> freeflying, hi.
<Mez> lol - well it seems to be approved anyways :D
* Mez just checks it builds properl
<Mez> y
<Mez> elmo: would it be possible to set the Changed-By in backports to the backports mailing list - this means we'll get katie (soyuz) output to the list when things are built - which'd be nice
<atie> freeflying, I asked Riddell about two skim icons - one for user and another for sudo(or kdesu), but he pointed you. Can for sudo one be hided from panel?
<freeflying> atie: I haven't found anyway for that 
<Mez> freeflying, surely they're just .desktop files?
<freeflying> Mez: atie mean two icons in system tray 
<Mez> oh
<Mez> kk
<atie> Mez, two scim processes are running while sudo executed. 
<freeflying> atie: if you set XMODIFIERES=@im=XIM,  there will be only one icon in system tray  , :)
<atie> freeflying, that's true since if I use other XIMs I don't have that problem. But, xim brings a crash at logout.
<Mez> freeflying, your package has no debian/compat
<freeflying> Mez: shall I add it or feedback to maintainer?
<Mez> ah
<Mez> nvm
<Mez> export DH_COMPAT=4
<Mez> strange way to do it
<freeflying> Mez: that was added by Riddell 
<freeflying> atie: I don't if this phenomenon take place in other distro scuh as suse or mdk
<atie> freeflying, two icons? or crash with xim?
<freeflying> atie: two icons
<Mez> freeflying, uploaded
<freeflying> Mez: thx
<Mez> oh
<Mez> crap
<Mez> it's in main
<Mez> whoops :D
<Mez> you'll have to get riddell to upload
<freeflying> Mez: as for the package , no problems ?
<Mez> nope
<Mez> not that I've potted anyway
<LaserJock> is it ok for people who aren't core-devs to close main bugs in Malone?
<crimsun> I don't see any reason against it as long as a legitimate status note is attached
<sls> hey -- check this out!!!! novell gpled their 3d UI suff... 
<sls> http://www.osnews.com/comment.php?news_id=13617
<sls> great for dapper ey???
<LaserJock> crimsun: Malone bug 28197 should be closed I think, what do you think?
<Ubugtu> malone bug 28197 in xmltex "xmltex: new changes from Debian require merging" [Normal,Unconfirmed]  http://launchpad.net/bugs/28197
<crimsun> LaserJock: looks legitimately closeable according to https://lists.ubuntu.com/archives/dapper-changes/2006-January/005617.html
<LaserJock> crimsun: ok, I'll close it with an approriate note
<uenyioha> hi guys 
<uenyioha> has anyone ever had a problem with the recvfrom function call ? 
<uenyioha> it doesn't seem to be populating the client address struct on my ubtuntu server
<fabbione> morning guys
<uenyioha> i tried it on another distro and it works there w/o issue
<jsgotangco> morning fabbione 
<uenyioha> wondering if anyone had experience with this...
<fabbione> uenyioha: nope. if something like that was broken, nothing would probably work
<uenyioha> fabbione: then how come it compiles on another box and works without issue? 
<fabbione> are you using the same gcc, glibc and kernel-headers?
<uenyioha> fabbione: im surprised
<fabbione> are you sure your code is correct? usually these kind of synptoms can show up when the code is almost clean, but not enough
<fabbione> and gcc4 complains more than gcc3
<fabbione> uenyioha: check with gdb what is going on
<uenyioha> fabbione: will do but as far as i can tell i am...
<uenyioha> fabbione: get back to you in a bit
<sanool> hi freeflying we have receive the kubuntu cds that you provided
<JaneW> not exactly what I said.... but http://www.computerworld.com/softwaretopics/software/story/0,10801,108532,00.html
<sanool> look kubuntu is here.http://bbs.lupaworld.com/htm_data/65/0602/15739.html
<jsgotangco> JaneW, if it gets published, i hope to get your authograph someday
<JaneW> jsgotangco: hah!
<ajmitch> jsgotangco: and you don't want her autograph if it's not published?
<JaneW> ajmitch: evidently :/
<jsgotangco> let me rephrase that
* jsgotangco fan of JaneW 
<sanool> help~can anyone connect with freeflying.i should pay him the post fee.
<JaneW> jsgotangco: flattery will get you anywhere :)
<jsgotangco> sanool, just send him a pm
<sanool> thanks~but so sorry that i'm a newer with irc.
<Mithrandir> JaneW: it's moree correct on page 3, though
<sanool> jsgotangco,the pm means the personal message, so funny~. thanks
<JaneW> Mithrandir: yes
<JaneW> Mithrandir: it sounds like I am a spokesperson for the Isle of Man though ;)
<Treenaks> JaneW: you mean you aren't? ;)
<Azerion> hello?
<Azerion> ..?
<Azerion> I have a question
<fabbione> just ask
<fabbione> too late
<JaneW> Treenaks: not for the 'enotire
<JaneW> oops 'entire' country, no ;)
<zakame> ji all
<zakame> er hi
<neuralis> JaneW: ping
<JaneW> neuralis: pong
<neuralis> JaneW: hardware-testing-catalog is incorrectly listed in the latest dev status report
<neuralis> JaneW: basically, i wrote both server testing specs, the owners are now changed to mdy/benc, and mdz requested i move dapper+1 bits into hardware-testing-catalog
<dholbach> good morning
<neuralis> JaneW: so i should have no more goals assigned to me, though you're free to keep hardware-testing-catalog on there as unlikely for dapper
<JaneW> neuralis: oic
<JaneW> neuralis: are you krstic?
<neuralis> JaneW: yes.
<JaneW> aaah ;)
<JaneW> neuralis: ok so hardware-testing-catalog is deferred to dapper+1
<neuralis> JaneW: great, thank you.
<JaneW> neuralis: and mdy and BenC are working on the other 2 portions
<JaneW> ok got it thanks
<neuralis> JaneW: yes, i had a phone call with mdy some days ago and we sorted things out.
<JaneW> neuralis: thanks. The specs all got a bit tangled and it wasn't clear who was doing what for a while ;)
<neuralis> JaneW: yeah, because the BoF discussed the wrong thing, and when this was figured out, i ended up inheriting the specs :)
<JaneW> neuralis: sorry and THANK-YOU
<neuralis> JaneW: not a problem at all. i understood what i was getting myself into, and we did get everything under control.
<makx> are there backports of the R release against breezy?
<makx> googling only come up with forcing sarge backports
<makx> http://ubuntuforums.org/archive/index.php/t-49178.html
<dholbach> makx: you should better write to ubuntu-backports@ and ask the question there.
<makx> dholbach: thanks for the pointer.
<dholbach> makx: they will check if a backport is possible, if it makes sense and make it happen
<makx> dholbach: R is in universe
<makx> so i guess it means to set up a chroot ;)
<dholbach> makx: I'd just let the Backports Team handle it.
<dholbach> makx: If you're in desperate need, you can just grab the Dapper source and build and install it with    debuild && sudo debi
<dholbach> (get the orig.tar.gz, dsc and .diff.gz)
<makx> dholbach: no desperate need but heavy R usage around
<makx> it's on different profs laptops
<makx> our server use debian
<makx> s/server/servers/
<pitti> Good morning everybody
<dholbach> heya pitti
<freeflying> pitti: hi
<pitti> hey dholbach, hi freeflying 
<freeflying> pitti: http://revu.tauware.de/details.py?upid=1721 need review and upload 
<makx> dholbach: mailed
<makx> have a nice day :)
<dholbach> makx: cool
<dholbach> You too!
<pitti> hi mvo
<mvo> hey pitti
<dholbach> hello mvo!
<mvo> hello dholbach!
<tepsipakki> who could take a look at malone bug #30141 ?
<Ubugtu> malone bug 30141 in glibc "nscd needs to start earlier" [Normal,Unconfirmed]  http://launchpad.net/bugs/30141
<Seveas> Anybody tried todays daily?
<jsgotangco> currently installing edubuntu daily
<Seveas> dang
<Seveas> ubuntu daily fails to start in vmware - guess it's a vmware problem :(
<ogra> Kamion, ping 
<Seveas> hmm, deleted VM, created new one, now I get gfxboot :)
<Seveas> and the udev bug that bit me yesterday is gone, go keybuK!
<Kamion> ogra: yo?
<Kamion> Seveas: fails to mount filesystem after first reboot? known bug
<ogra> Kamion, i played with cdimage yesterday, but somehow i dont get it right it seems
<Kamion> affects the particular kind of SCSI driver emulated by vmware
<Kamion> ogra: what happened?
<Seveas> Kamion, and now it hangs at 'Loading pdc202xx_old' during installer boot :(
<ogra> Kamion, as i understood i first run: for-project edubuntu build-image-set daily ?
<Kamion> ogra: did you follow my instructions? it doesn't look like it
<ogra> and afterwards the pubilsh-daily ?
<Kamion> argh, no
<ogra> (didnt run the latter)
<Kamion> ogra: READ and FOLLOW /srv/cdimage.no-name-yet.com/secret/README
<Kamion> do that first
<Kamion> and then you run 'for-project edubuntu cron.daily' - don't run build-image-set by hand
<ogra> gah, missed the secret :(
<ogra> sorry
<ogra> i read the wrong instructions
<Kamion> calling build-image-set by hand will break because CDIMAGE_INSTALL=1 won't be set
<Kamion> you'll effectively get a null CD ;0
<Kamion> ;)
<ogra> so i only run the publish stuff as in the instructions ...
<Kamion> no, don't run publish-* by hand
<Kamion> well, not publish-daily anyway
<Kamion> build-image-set does that for you
<ogra> ah, k
<Seveas> ugh, what is up with this vmware crud :( It hangs at random places
<Kamion> you should only run 'for-project edubuntu cron.daily' and/or 'for-project edubuntu cron.daily-live'
<ogra> oki
<tepsipakki> seveas: workstation or server?
<Seveas> server
<tepsipakki> ok, I'm still waiting for some space on our ESX-server to test the installation..
<Seveas> had to boot it 3 times to get through cdrom detection
<Seveas> and now it hangs while retrieving packages
<Seveas> that's it - rm -rf
<Kamion> last vmware install I did ran perfectly up to the first reboot
<Kamion> that was about a week and a half ago
<Seveas> breezy installed fine yesterday, after a dist-upgrade to dapper first boot failed
<HrdwrBoB> yes
<Seveas> dapper-daily yesterday failed to boot completely
<Seveas> and now it hangs at random places
<HrdwrBoB> it doesn't update module-init-tools
<HrdwrBoB> before the kernel
<HrdwrBoB> which builds a broken initrd
<Kamion> HrdwrBoB: but just about everything that's in the initramfs should call update-initramfs
<Kamion> so even if the first one breaks, you should eventually get a working one
<Kamion> it does mean the initramfs gets regenerated rather a lot during big upgrade
<Kamion> s
<HrdwrBoB> Kamion: well.. I upgraded, and for some reason it didn't update module-init-tools at all
<HrdwrBoB> though I think I was just getting the kernel
<Kamion> that would be a separate problem ...
<HrdwrBoB> which didn't depend on module-init-tools even though it does
<Kamion> only sort of
<Kamion> dependencies from the kernel are always awkward
<Kamion> but actually, I beg to differ ...
<Kamion>  Package: linux-image-2.6.15-15-386
<Kamion>  Version: 2.6.15-15.21
<Kamion>  Depends: initramfs-tools (>= 0.36ubuntu6), coreutils | fileutils (>= 4.0), module-init-tools (>= 3.2.1-0ubuntu1)
<HrdwrBoB> is that the latest version
<HrdwrBoB> it failed with a -Q not understood problem
<Kamion> module-init-tools | 3.2.2-1ubuntu3 |        dapper | source, amd64, i386, powerpc
<Kamion> -Q has been there for a while though, I think
<HrdwrBoB> that'll do it
<HrdwrBoB> well.. the version I had didn't have -Q
<Kamion> ah, 3.2.1-0ubuntu1 didn't
<HrdwrBoB> which I'm pretty sure is breezy
<Kamion> specifically that version - older and newer ones did
<Kamion> module-init-tools | 3.2-pre7-0ubuntu4 |        breezy | source, amd64, i386, powerpc
<HrdwrBoB> oh, haha
<Kamion> -Q was added in 3.1-rel-2ubuntu2
<Kamion> it's not the kernel itself that's calling modprobe though
<HrdwrBoB> true
<HrdwrBoB> but the kernel will never boot correctly without an initrd that'll boot properly which will never boot properly without the right modprobe
<Kamion> that indicates, though, that the dependency should be elsewhere
<HrdwrBoB> yeah
<Kamion> what were you upgrading from? definitely breezy?
<Emerson> btw, running Dapper, only minor issue I ran into was with nvidia-glx ...  
<HrdwrBoB> I'm almost 100% certain
<HrdwrBoB> also, there's no 686-smp? I assume that's deliberate 
<Kamion> see the changelog
<Kamion> -686 does automatic SMP now
<Kamion> breezy's modprobe definitely supports -Q
<Kamion> anyway, I think you should file a bug on initramfs-tools asking that it depend on some suitable version of module-init-tools
<HrdwrBoB> yeah I'll do so
<Kamion> since it uses modprobe -Qb, it should depend on module-init-tools (>= 3.2.1-0ubuntu2)
<Emerson> Kamion: am I wrong but isn't all x86 doing auto SMP now?
<Kamion> Emerson: correct
<Kamion> Emerson: HrdwrBoB asked about -686, not all x86, so I answered the question he asked :)
<Emerson> lol
<ogra> Kamion, cdimage worked fine now, thanks a lot.... one note though, having a known_hosts file prepared for the publishing hosts to just copy in place would be helpful 
<Kamion> it's only a problem once per user, so I've never really had the interest to fix that up
<ogra> yup
<Kamion> but sure, I guess
<ogra> hmm, why is all this lsb stuff failing ...
* ogra goes digging
<WaterSevenUb> Kamion,sent you a pt.po of debian-installer*16.
<Kamion> thanks
<Riddell> Kamion: are we looking to do flight 4 today?
<Kamion> Riddell: no
<Kamion> WaterSevenUb: the way there are XML tags in the translatable text is unfortunate, and one of yours is mismatched ... fixing
<Riddell> ok
<Kamion> Riddell: next week, I imagine - not having my main test machine until yesterday has just thrown me too much out of kilter
<WaterSevenUb> Kamion, ok. thx.
<ogra> is the squashfs stuff fixed for livecds ? 
<jsgotangco> hrmmmm
<ogra> jsgotangco, ?
<jsgotangco> even my ubuntu 64 fails
<Ubugtu> ubuntu bug 64 in pwlib "pwlib: FTBFS: Shared libraries without -fPIC." [Normal,Resolved: fixed]  http://bugzilla.ubuntu.com/show_bug.cgi?id=64
<ogra> heh, go Ubugtu 
<lifeless> Ubugtu: help
<jsgotangco> lsb stuff fails too
<ogra> yup
<ogra> thats what the reports show ...
<jsgotangco> i guess its spread to all arches
<ogra> i'll dig into it once i fixed the inputattach breagake for edubuntu
* jsgotangco goes to enjoy friday...
<tseng> jsgotangco: bye
<jsgotangco> tseng!
<jsgotangco> too early?
<tseng> you said you were leaving :)
<tseng> and yes, it is quite early
<Kamion> ogra: current kernel should fix it, will need new livefs and CD builds obviously following the kernel binaries being accepted into the archive, if that hasn't happened already for you
<jsgotangco> ahh i'll see you later then, good to see you too..cheers
<Kamion> http://people.ubuntu.com/~cjwatson/livefs-build-logs/dapper/ubuntu/20060210/livecd-20060210-i386.out indicates that the current Ubuntu livefs build should be using a fixed kernel
<ogra> Kamion, dunno about the livefs ... infinity ?
<ogra> hmm, probably asleep ...
<Kamion> ogra: the reason I published http://people.ubuntu.com/~cjwatson/livefs-build-logs/ was so that you could check this sort of thing yourself without reference to infinity
<ogra> Kamion, yes
<Kamion> WaterSevenUb: excellent, working great after I made a fix or two
<WaterSevenUb> Kamion, probably I made some mistakes modifying translation of version 15 to version 16, anyway, let me know if you need something else.
<Kamion> there were no changes in translatable text between 20051026ubuntu15 and 20051026ubuntu16
<WaterSevenUb> Kamion, well... my files were slightly different namely in the amount of text per line
<Kamion> so this stuff will look wrong for netboot images, but very few people will actually see it in that case
<Kamion> MEDIA_TYPE will generally be "CD-ROM", which seems to look o
<Kamion> ok
<Kamion> line length of .po files is irrelevant and in fact gets clobbered by msgcat anyway, so I don't care
<Kamion> you should generally run your files through msgcat to produce a version in canonical form though
<Kamion> I'll do that with your file now
<WaterSevenUb> Kamion, yes... majority of cases will be "CD-ROM" and for more complicated stuff the sort of people that do it are used to English.
<infinity> Kamion: What was wrong with http://people.ubuntu.com/~lamont/liveLogs/ ?
<WaterSevenUb> Kamion, in any case if translators add things like "este(a)" when refering to "this CD-ROM" or "this netboot images",respectively, allows feminine and masculin words to follow "this", even if they are in english makes a lot more sense.
<WaterSevenUb> Kamion, of course in English that doesn't matter.
<Kamion> infinity: I didn't know about it and it wasn't on DeveloperResources?
<Kamion> I'll kill my mirror and stick in a redirect, then
<ogra> hmmm.... i should probably add inputattach to the live seed as well ...
<Kamion> ogra: what seed is it in at the moment?
<Kamion> WaterSevenUb: yeah, I realise the current way it assembles sentences is a problem, it's just hard to fix
<ogra> it was pulled in by ltsp-client, but debian asked me to remove the hard dependency
<infinity> Kamion: Fair enough.  I don't think we've pointed anyone at it since Montreal.
<ogra> i just added it to edubuntu-server ... but that wont help in liveCDs
<Kamion> ogra: it seems to me that hardware activation packages belong in minimal or standard or something, not live
<Kamion> or server for that matter ...
<ogra> its not used by default 
<Kamion> but that would require modifying the main Ubuntu seeds, of course
<Kamion> sure, but even so
<Kamion> if it's there, we can point people to it
<ogra> its only for manual working around serial mouse breakage ...
<ogra> yup
<Kamion> I don't think we should be haphazardly adding it to outer seeds
<ogra> will add it to minimal then 
<ogra> its 80k or so ... anyway ...
<Kamion> I think maybe standard
<Kamion> if it doesn't do anything by default, it doesn't need to be in the debootstrapped set
<Kamion> (btw, current Ubuntu live CD works for me)
<ogra> oh, great ...
<ogra> i'll need another build, powerpc isnt there ...
<Kamion> go ahead
<ogra> will do ... 
<ogra> let me update the seeds first ;)
<ogra> so i dont have to do another one :)
<Kamion> infinity: I've changed the URL in DeveloperResources now. Can't put a redirect in until the RT request I've just filed for an Apache configuration change is addressed, though.
<Seveas> WOOHOO
<Seveas> it took a long time, but dapper finally installed and booted in vmware :)
<tepsipakki> duh, mkinitramfs hosed my kernels, they panic on boot because they can't find root.. how to fix that?
<HrdwrBoB> all of your kernels?
<tepsipakki> yes
<HrdwrBoB> nice
<tepsipakki> yes ;)
<infinity> tepsipakki: update-initramfs doesn't act on non-default kernels unless you ask it to.
<tepsipakki> dist-upgrade did, I guess
<infinity> Shouldn't.
<tepsipakki> I already had dapper on this
<infinity> It should only update the initrd for the current kernel.
<tepsipakki> it also installed a new one =)
<infinity> Of course, if you only have one kernel...
<tepsipakki> my root is a real partition, but rest is on lvm.. so it's tricky to fix
* jbailey wonders if launchpad is slow from the pass of other people reporting "Where did my network interfaces go" on udev? =)
<infinity> Anyhow, recent changes were made to udev to "fix" the driver load order, which may have made your root move.  You may want to bug Keybuk about it (I'm heading to bed in about 20 seconds)
<ogra> infinity, could you trigger a livefs build for edubuntu (i suppose the other ones also want inputattach on the liveCD, so probably for all)
<Mithrandir> I can do it
<Kamion> jbailey: not just me who had it renamed to _eth0, then?
<infinity> Mithrandir: Thanks.
<Kamion> ogra: the others can wait for the nightly build, I think
<jbailey> Kamion: Nope.  I'm just confirming and adding a "me too" to bug 31040
<Ubugtu> malone bug 31040 in udev "eth0 has disappeared after recent update" [Normal,Unconfirmed]  http://launchpad.net/bugs/31040
<jbailey> Ubugtu: thanks. =)
<ogra> Kamion, k
<tepsipakki> infinity: thanks, I will
<Mithrandir> ogra: just the live fs or a full cd?
<ogra> Mithrandir, i can build the images myself now ... only the livefs ... i'll care for the rest
<Mithrandir> ogra: running.
<ogra> thanks :)
<tepsipakki> there are no daily-dvd:s for i386?
<Kamion> no, probably broke for the same reason live CD builds for amd64/i386 were breaking until yesterday
<Kamion> the next build should work
<doko> any known problems with the boot process? just tried to start my laptop after I came home, but it fails to mount the root partititon: Device or resource busy
<tepsipakki> kamion: do you know when that build is ready?-)
<Kamion> tepsipakki: 17 12 * * 2,6   for-project ubuntu cron.dvd
<Kamion> ^-- crontab entry
<tepsipakki> cool
<Riddell> seb128: running gnome-settings-daemon changes my font sizes in KDE, any idea what it's doing?
<seb128> Riddell: setting the dpi
<Riddell> xdpyinfo doesn't say anything different
<seb128> it sets the Xft/DPI xsetting
<seb128> Xft/HintStyle Xft/Hinting Xft/Antialias too
<seb128> hum
<Riddell> why does it do that?  and where can I find out what it's set it to?
<seb128> it doesn't that because you can configure the settings from GNOME
<seb128> you might be interested by http://bugzilla.gnome.org/show_bug.cgi?id=104341
<seb128> especially Owen's comments about that
<Ubugtu> gnome2 bug 104341 in font properties "gconf DPI ignores system settings" [Normal,New]  
<Treenaks> Can someone please look at bug 4773? It's breaking my system :(
<Ubugtu> malone bug 4773 in wacom-tools "please update packages" [Major,Confirmed]  http://launchpad.net/bugs/4773
<Riddell> seb128: so essentially gnome always uses a dpi of 96?
<seb128> Riddell: you can change it with gconf key /desktop/gnome/font_rendering/dpi
<seb128> but by default yep
<Riddell> I wonder if we should just set the X server to have that DPI
<ogra> doesnt it default to 96 ? 
<Riddell> ogra: the X server current defaults to whatever the monitor tells it to
<Riddell> which isn't always reliable
<seb128> that's why GNOME use a fixed value
<ogra_> i remember gdm setting the -dpi flag for the X server, but thats long ago i think ...
<Treenaks> Anyone wit ha Mac Mini here?
<Treenaks> with a
<mvo> Treenaks: IIRC Riddell has one
<Riddell> Treenaks: yep
<Treenaks> Riddell: Do you experience bug 29365?
<Ubugtu> malone bug 29365 in xserver-xorg-driver-ati "Broken output on Mac Mini (Radeon 9200)" [Normal,Unconfirmed]  http://launchpad.net/bugs/29365
<Riddell> Treenaks: nope
<Treenaks> hmm
<Treenaks> not even the 'invalid IO allocation' part?
<lemsto> hi there :D
<lemsto> i've a question about dependencies: Why is it needed to install both totem/gstreamer and rythmbox, i mean in debian i could install totem OR rythmbox (or both...)
<Kamion> lemsto: you don't have to keep ubuntu-desktop installed if you don't want to
<Kamion> I mean, it's what we provide and support, but if you don't want all of it then you can remove it
<lemsto> dummy package as ubuntu-desktop and other ubuntu-omething are already removed :p
<lemsto> i wanted to install rythmbox and dependencies oblige to instal totem with
<lemsto> (im using breezy)
<Kamion> that's not the case in dapper any more
<lemsto> ok thanks
<Kamion> the dependency was added due to https://launchpad.net/distros/ubuntu/+source/rhythmbox/+bug/18518
<Ubugtu> malone bug 18518 in rhythmbox "rhythmbox dependancy problems" [Normal,Fix released]  
<Kamion> I think it was before the libtotem-plparser* package was created for the library, so at that point rhythmbox had to depend on totem to get that library
<lemsto> i see
<seb128> exact
<seb128> now it's splitted and we use the lib
<Kamion> presumably it was just an oversight that the dependency wasn't dropped in breezy
<Treenaks> Kamion: A few people are asking for the (not-updated-since-before-hoary) wacom driver to be updated, is there _any_ chance that this might happen, or are we basically stuck until dapper+1 for that?
<Kamion> Treenaks: I have absolutely no idea, I don't have the hardware and know nothing about it
<Kamion> Treenaks: the bug is assigned to mjg59; if he or somebody else wants to update the package, I'm sure that could be arranged as long as it happens soon
<Treenaks> Kamion: ok.. I'll talk to him t hen
<Treenaks> mjg59: ping?
<mjg59> Treenaks: Hi
<mjg59> No time to deal with it right now
<mjg59> After the weekend with luck
<Treenaks> mjg59: ok, sure
* ogra kicks powerpc live ....
<ogra> why the heck are they 70MB bigger ...
<Yagisan> ogra: because they like to be special :)
<ogra> but 70MB !
<ogra> i386 is 634MB big, ppc is at 712 now
<Yagisan> ogra: how does it compare to amd64 ?
<ogra> and powerpc doent even have the gcompris sound packages anymore (~50MB dropped there)
<ogra> amd64 ~ 650MB 
<ogra> (with gcompris)
<ogra> i'm running out of packages i can drop ...
<Yagisan> ogra: hmm, they aren't being built with outrageous cflags are they ? eg unrolling all loops etc
<ogra> they are all built the same way 
<ogra> its just the package selection and package sizes that differ ...
<jdub> ogra: how would you rate the quality of current dapper edubuntu livecd?
<ogra> jdub, no idea, i just built the image ...
<ogra> the last one i tried with an outdated livefs looked fine ...
<jdub> ok thanks
<ogra> jdub, ask again in ~2h ... then i'll have tested the current ones
<Kamion> ogra: er, possibly because you have a huge pile of extra language packs in powerpc?
<Kamion> ogra: try diffing the .manifest files, it makes it pretty clear
<ogra> oh, ok ... i was only looking at seeds
<Kamion>  * Languages: zh bn de fr
<Kamion>  * language-pack-${Languages} [powerpc ia64] 
<Kamion>  * language-pack-gnome-${Languages} [powerpc ia64] 
<Kamion>  * Languages: es hi ar pt ru ja ca
<Kamion>  * language-pack-${Languages} [powerpc] 
<Kamion>  * language-pack-gnome-${Languages} [powerpc] 
<Kamion> ^-- edubuntu-dapper/live seed
<seb128> how much space do we win on the CD with the gst0.8 cleanup?
<Chipzz> seb128: talking about gst0.8 to gst0.10 migration... there are *a lot* of plugins missing in gst0.10 wrt gst0.8 ... isn't that a regression?
<seb128> Chipzz: exageration will not lead you anywhere
<tseng> Chipzz: there are alot of firefox plugins that dont work with 1.5
<tseng> Chipzz: do you think we would be further ahead if we went back to 1.0 for the next 6 months?
<Chipzz> root@Reel:~# dpkg -l | grep gst | grep -c 0.8
<Chipzz> 29
<Chipzz> root@Reel:~# dpkg -l | grep gst | grep -c 0.10
<Chipzz> 12
<tseng> er dude
<tseng> that is a totally bogus number
<Chipzz> you're calling this an exageration?
<Chipzz> I call that a joke
<tseng> 0.10 plugins are bundled into -good
<Chipzz> not it's not
<seb128> Chipzz: lol, we stopped to split the binary packages
<tseng> you are full of it, please do the research
<tseng> and come back
<seb128> your dpkg -l | wc is so wrong
<seb128> that's really funny :)
<Chipzz> hrm
<tseng> the only major plugin that isnt ported is -dvd
<Chipzz> last I checked there wasn't much in gstreamer0.10-plugins-good ;P
<seb128> $ dpkg -L gstreamer0.10-plugins-good | grep .so | wc -l
<seb128> 41
<Chipzz> some plugins must have been added :P
<seb128> sure
<seb128> start whining first, look on what is really shipped then .... :)
<Chipzz> :P
<Chipzz> so why don't we split the plugins anymore than?
<ogra> seb128, looks like edubuntu won only 4MB on the live CD with gst0.10
<seb128> because it was overcomplicated
<seb128> that's not usuful
<tseng> because upstream already split them into logical groups
<seb128> useful
<seb128> that matches better upstream and others distros etc
<Chipzz> seb128: and now we have 1 package with a huge list of dependencies :/
<seb128> no
<seb128> we have splitted stuff with many deps, like -gnomevfs, -x, -alsa, etc
<seb128> we just stopped splitting for tiny libs, like 200k Depends doesn't require a new binary
<jdub> and the old split wasn't always that sensible anyway
<jdub> big x depends when all you want is tcpsink!
<Chipzz> jdub?
<Chipzz> but the list of dependencies looks reasonable :)
<seb128> so what is your issue exactly ? :)
<Chipzz> seb128: I was mistakenly worried about regressions ;)
<seb128> so no issue, cool :)
<Chipzz> the bundling of a lot of plugins in one package *is* a bit confusing though...
<Chipzz> I've been working with debian for a long time, and I was wondering "wtf?" when trying to migrate the plugins from 0.8 to 0.10 ;)
<Chipzz> but I hope that's resolved with dependencies now ;)
<seb128> the issue with too much split was also it makes non-trivial for users to know what to install
<seb128> so most of people were installing everything anyway
<mdke> has anyone else seen some strange behaviour with screen blanking: my gf rang and said that every time the screen blanks on her laptop, it doesn't come back up again...
<mjg59> mdke: Using nvidia drivers?
<mdke> mjg59, no, it has a built-in ati graphics card
<ogra> running breezy i suppose ...
<mjg59> mdke: Ok. No idea, then.
<mdke> ogra, no, dapper. The problem just appeared today apparently
<mdke> mjg59, okay, i'll look when I get home and file a bug
<ogra> mdke, there was no update either in X, screensaver or power manager ... i couldnt imagine anything else causing it ...
<mdke> i think gnome-power-manager was only recently installed
<mjg59> gnome-power-manager doesn't do any screen blanking
<mjg59> It just tells gnome-screensaver to do so
<mdke> hmm
<ogra> mjg59, but we have an evil default in g-p-m i wanted to change anyway ...
<ogra> (put computer to sleep after 20min is default if on battery)
<Chipzz> seb128: hrm, am I mistaken or wasn't serpentine supposed to be migrated to python-gst2.4 ?
<seb128> 2.4?
<seb128> what is that?
<Chipzz> err wait
<seb128> serpentine gstreamer0.10 will be packaged today
<seb128> if that's the question
<ogra> wow, thats a big jump, given that we are at 0.10
<Chipzz> python-gst0.10
<Chipzz> ah ok :)
<ogra> :)
<lemsto> do you need many more dapper testers? (amd64) im asking myself for a week if i should wait to dist-upgrade...
<dholbach> lemsto: there was an announce of the dist-upgrade tool - you could test that.
<lemsto> ok
<dholbach> lemsto: https://lists.ubuntu.com/archives/ubuntu-devel/2006-January/014700.html
<Treenaks> dholbach: when is [hb] ug-day? :)
<dholbach> Treenaks: friday, februrary 17th
<Treenaks> dholbach: hm.. will you be fixing X boogz?
<dholbach> X as in xorg?
<Treenaks> dholbach: as in xserver-xorg-driver-ati :)
<dholbach> No.
<dholbach> I'm concerned about my mental health already.
<Treenaks> hmm.. suckage :)
* mdke nods
* Treenaks will NOT hug dholbach
<dholbach> I'll have to live with that.
* HiddenWolf hugs dholbach instead
<HiddenWolf> Treenaks does not know what's good for him.
<mdke> can someone help me with a "what package is this a bug in" question? My dapper is allround slow, it takes ages to install new packages and the mouse wanders around the screen very jerkily. I'd love to know how to report this properly
<Treenaks> mdke: what does top say?
<mdke> Xorg and "ip" are using about 30-35% cpu
<mdke> update-notifeir 15
<Lathiat> ip is using 35% cpu?
<Lathiat> thats not right
<mdke> notifier-applet another 10
<mdke> what is ip?
<seb128> killall update-notifier
<seb128> that's update-notifier bog, mvo is working on it
<mdke> oh great, so I don't even have to report a bug
<seb128> he just uploaded a new version that may fix it
<mdke> yay, thanks seb128, as usual
<seb128> np
<mvo> mdke: give the new one a try please and let me know. it seems to be very hard to reproduce, what did you do to make the bug appear?
<mdke> mvo, I just booted up, opened a terminal, did apt-get update and dist-upgrade. I think it was slow as soon as I booted, but I can't be sure
<mdke> i'll try the new one when it lands
<pitti> hey Keybuk 
<Keybuk> heyhey
<seb128> hi Keybuk
<ogra> Kamion, did you have network in your liveCD test ? 
<HiddenWolf> Keybuk: hey, is "starting pmcia services" supposed to print "fail" on a desktop?
<Kamion> ogra: 12:10 < Kamion> jbailey: not just me who had it renamed to _eth0, then?
<ogra> i can see eth0 in dmesg coming up if i plug in the pcmcia card, i got it in /proc/net/dev as well, but ifconfig tells me there is no eth0
<Mez> ogra: is it in interfaces?
<ogra> its not renamed or something ... just the networking tools dont seem to see it
<Kamion> ogra: try 'ifconfig -a'
<Kamion> I bet it's _eth0
<ogra> and __eth0
<ogra> funny
<Kamion> there you go, bug 31040 then
<Ubugtu> malone bug 31040 in udev "eth0 has disappeared after recent update" [Major,Confirmed]  http://launchpad.net/bugs/31040
<ogra> ok, i'm fine then 
<ogra> its all Keybuk's fault anyway :)
<Keybuk> hmm, that _eth0 one is kinda interesting :)
<Keybuk> who has that?
<Mez> for some reason - i get a "cannot rename eth1 to eth0 - device is busy" on boot up
<ogra> Keybuk, the current liveCd
<Keybuk> Mez: yeah, that one was a think-o on my part
<Kamion> Keybuk: jbailey and I both do
<Keybuk> Kamion: oh good, could you check you don't have eth0 assigned to SOMETHING ELSE in your /etc/iftab? :p
<Kamion> I'm getting it in a vmware boot of today's live CD
<Kamion> apparently so
<Mez> even though my wireless card dowsnt work anyways
* Kamion blames Mithrandir
<ogra> Keybuk, its assigned to a non existing MAC address here
<Kamion> where the hell does that /etc/iftab come from on the live CD anyway?
<Keybuk> Kamion: that's a good question
<Keybuk> probably Mithrandir's desktop ;)
<ogra> lets just find the MAC ;)
<Kamion> unlikely, no mention of iftab in casper or livecd-rootfs
* dholbach has a _eth0 too :)
<ogra> 00:0d:60:1a:58:ca 
<Keybuk> netcfg writes iftab, but that shouldn't happen for the livecd?
<ogra> and :cb
<Kamion> yeah, same as ogra
<Kamion> Keybuk: indeed
<ogra> who owns that card ?=
<Keybuk> ogra: IBM
<ogra> :P
<ogra> i thought about the last three digits :)
<Keybuk> anyway, yes, if the LiveCD has an iftab that would explain stuff for those bugs
<jdub> mjg59: ping
<fabbione> Keybuk: is there any hope to get the dhcp / resolv.conf bug fixed yesterday?
<Keybuk> fabbione: bug#?
<fabbione> dunno
<fabbione> the same you did tell me about in London
<fabbione> so you know about it
<Kamion> /etc/iftab is in the read-only file system so it's not casper's fault
<fabbione> Keybuk: boottime -> interface up -> resolv.conf is empty
<Kamion> aHA
<Kamion> it's udev
<Keybuk> Kamion: could it be the iftab on the machine that makes the CDs
<Keybuk> fabbione: that's been fixed for a week
<ogra> pitti, i just burned a set of CDs, usually they get mounted after writing the CD ...
<Kamion> Keybuk: your postinst generates an iftab from /sys/class/net/eth* on the buildd
<Keybuk> yeah it does
<fabbione> Keybuk: no it's not.. i rebooted this morning after an upgrade and the problem is still there
<Kamion> Keybuk: can you not do that on initial install, maybe?
<Keybuk> fabbione: then please file a bug
<Keybuk> Kamion: aye, that seems a bit silly to do now ;)
<ogra> pitti, normally on /media/dvdrecorder/ ... but the third burn got mounted as /media/scd0/
<fabbione> Keybuk: do you have the old bug number to reopen?
<pitti> hmm
<Kamion> in fact, maybe just don't do it at all
<Keybuk> fabbione: no, and if there were an old bug, it's fixed -- you must have a different bug
<Kamion> I can't see a massive benefit in doing it automatically
<Keybuk> Kamion: indeed, let's leave that to the installer
<pitti> ogra: that's actually a regression, previous versions of n-c-b ejected the CDs by default
<Kamion> Keybuk: righto
<pitti> ogra: because many drives don't get along very well with immediate mount after burn
<ogra> pitti, it didnt do it yesterday ... thats not what i mean 
<pitti> ogra: does eject/reinstert help?
<fabbione> Keybuk: against what package do you want it?
<Keybuk> fabbione: dhcp3-client probably
<ogra> pitti, to late, already unplugged the writer ...
<ogra> pitti, i just meant the name change of the mount point, that didnt occur to me yet 
<mjg59> jdub: Hi - need to head out to a meeting now, back in a couple of hours
<ogra> (its a usb writer)
<pitti> yes, that's strange
<ogra> i'll keep an eye on it, will test install CDs as well today, so lets see if it happens again ...
<pitti> mvo: tbird locales drive me crazy - they don't work for no apparent reason; I asked the debian maintainer now, before I waste another hour on it
<fabbione> Keybuk: unlikely, but well one to start is like any other
<pitti> mvo: or did you have more luck by any chance?
<mvo> pitti: no, I had exactly the same problem :(
<fabbione> Keybuk: 31057
<Keybuk> fabbione: definitely likely.  the previous bug was simply that /etc wasn't writable at the time
<Keybuk> are you running network-manager, btw?  with a static IP configuration?
<fabbione> Keybuk: no network-manager.
<fabbione> it's a workstation.
<fabbione> just ip assigned by DHPC
<fabbione>  / on lvm
<Treenaks> Keybuk: speaking of iftab/ifrename... my laptop's interfaces switched around, and I need to run /etc/init.d/ifrename start to rename them back to their breezy names
<Keybuk> Treenaks: I'll deal with you in a moment ... ;)
<fabbione> Keybuk: anyway i will do some more appropriate debugging on monday
<fabbione> Keybuk: so don't get headacke for it
<Keybuk> we do need a "Knowledge Base"
<zakame> hello Keybuk 
<fabbione> we need a stable boot process first :P
<Keybuk> we need stable developers for that :)
<Treenaks> Do we need more crack for that, or less?
<fabbione> Keybuk: that will reduce the choise to about.. hmm.. none
<HrdwrBoB> FWIW, ext3 in breezy only supports 32,000 filenames per directory
<fabbione> like all the other ext3 around the world
<HrdwrBoB> allegedly it's unsigned and artificially limited to 32k instead of 64k
<HrdwrBoB> anyway
<Kinnison> to be honest, anyone who wants to put 32k entries in a directory should be shot anyway
<Treenaks> Kinnison: /usr/bin/
<HrdwrBoB> Kinnison: I don't think they planned for having 42,000 accounts when they first  developed the system
<Keybuk> Treenaks: has about 2,000 entries maxmimum
<plb> Anyone know the best way to get in contact with Mark?
<Diziet> -davenant:~> echo /export/mirror/Repository/data-md5/* | wc 
<Diziet>       1  258116 17551888
<Treenaks> HrdwrBoB: /home you mean? just split deeper :)
<Keybuk> sweet:
<HrdwrBoB> Treenaks: no, custom web app - not an option
<Keybuk> $ ifconfig
<torkel> Kinnison: we have had users that had 1M++ files in directories
<Keybuk> ath0: error fetching interface information: Device not found
<Keybuk> oops
<Kinnison> still seems daft not to have a hashing scheme in there
<Keybuk> torkel: use a different filesystem, etc.
<Kinnison> if only for speed of access
<HrdwrBoB> I'm getting some more disks - I'll just make it XFS
<Diziet> hashing scheme> should be done once, well, by the fs, not 100 times, badly, by 100 applications.
<Treenaks> Kinnison: dir_index exists, and I've used it on all my systems since hoary
<Diziet> Also, mkdir is not cheap compared to mknod.
<torkel> Keybuk: on AFS... :-(
<ogra> HrdwrBoB, fabbione, wrong, ext3 supports at least 180000 files per directioy ... i have one holding that much
<Mithrandir> HrdwrBoB: files != directories.  40k files works fine.
<Treenaks> Kinnison: though I agree 'all my systems' don't count as 'a good testcase'
<ogra> Mithrandir, more :)
<HrdwrBoB> sorry my bad
<HrdwrBoB> directories
<Mithrandir> ogra: I didn't say 40k was the limit.  I said it works fine.
<ogra> yup :)
<Treenaks> ogra: 180k files?! WHY?!
<ogra> Treenaks, because it works :)
<Treenaks> ogra: warez-d00d! ;)
<ogra> nah
<HrdwrBoB> what I want to know is why is an unsigned int limited to 32,000 entries
<HrdwrBoB> instead of 64
<HrdwrBoB> oh well
<Diziet> So how evil would it be of me to put an rpath setting in a .pc file ?
<Kamion> (for a factor of two, who cares?)
<HrdwrBoB> it's just a wasted bit for no good reason
<ogra> Treenaks, the only prob with so many files is that ls breaks on them ;)
<Treenaks> ogra: how?
<ogra> it cant take this many files ... ETOOMANYARGUMENTS
<Treenaks> ogra: don't ls *
<Treenaks> right?
<HrdwrBoB> ogra: that's a shell limitation
<HrdwrBoB> not ls
<ogra> yup
<HrdwrBoB> ls . works
<cieffe> hi everybody
<HrdwrBoB> for i in *; do rm $i; works
<Kamion> HrdwrBoB: ... that you know of. (I'm fairly sure I remember there being a good reason, although the discussion was six months ago and I don't remember it offhand.)
<HrdwrBoB> +done
<Diziet> for i in *   works because you never call exec with the huge argument list.
<Diziet> -davenant:~> /bin/echo /export/mirror/Repository/data-md5/* | wc 
<Diziet> bash: /bin/echo: Argument list too long
<Diziet>       0       0       0
<plb> Anyone know how I could get in contact with Mark?
<HrdwrBoB> Kamion: fair point
<Kamion> plb: he's a pretty busy man - what are you trying to get in contact with him about?
<plb> interview for a school paper
<Keybuk> best thing would be to just e-mail mark.shuttleworth@canonical.com
<plb> thanks
<Keybuk> I wouldn't expect an immediate reply though as he's in Asia at the moment
<plb> alright thanks
<ogra> jdub, current edubuntu live CDs are all fine (apart from the known bugs)
* mvo is away for a bit
<jdub> ogra: thanks
<jdub> ogra: a friend will be demoing it to a local school
<ogra> hmm ...
<jdub> Kamion: is NEW processing not happening?
<jdub> ogra: mostly because their laptop doesn't run breezy ;)
<Keybuk> "everything's fine, except for when it's not"
<ogra> jdub, i guess you've see the former discussion here about broken network interfaces
<jdub> doko_: where does debian python policy live?
<ogra> (which affects all liveCDs currently)
<jdub> ogra: no, but that is very intersting ;)
<jdub> doko_: n/m :-)
<ogra> somehow /etc/iftsb has a fixed MAC eth0 and eth1 mapping currently ...
<doko_> jdub: the doc is included in python-defaults
<ogra> tsk
<ogra>  /etc/iftab
<Kamion> jdub: only when I get round to it, why?
<jdub> Kamion: seen libapache2-mod-annodex on its way through?
<Kamion> jdub: processing
<jdub> Kamion: pyannodex coming your way, too
<Kamion> jdub: that's a dreadful package description, tells me nothing about what Annodex or CMML actually are
<Kamion> and temporal => temporary I suspect you mean
<jdub> no, very much temporal
<Kamion> time-based? ok
<jdub> i'll improve it for the next release :-)
<ogra> the apache time traveller module .... phear !
<ogra> "see how your website will look tomorrow !!"
<jdub> naw, means you can link into temporal media, like audio and video
<jdub> and the server will do the right thing
<ogra> ah :)
<jdub> when i say into, i mean *into*
<Lathiat> heh, nice
<ogra> ahh, like link to timecode 17:24 ?
<Kamion> source accepted
<jdub> ...?t=0:52:13.000 -> fifty-two minutes, thirteen seconds into the stream
<jdub> Kamion: thanks
<ogra> cool
<Kamion> I'm really not paying much attention to NEW at the moment though, too much code to write
<jdub> Kamion: can't your gimp do it?
<Kamion> also FWIW the only place the word "lesser" appears in pyannodex is in debian/copyright; the source is really under the Library GPL
<Kamion> I know they're basically the same thing but you should probably be consistent with the licence the author actually used
<jdub> hrm, yeah
<doko_> Diziet: please add a conflict for firefox for the next upoad: Conflicts: mozilla-browser (<< 1.7.12-1ubuntu7)
<Diziet> doko: No, I'm going to reorganise the files instead.
<Diziet> And I'm going to file a bug against mozilla saying it shouldn't have /usr/lib/libxpcom.so either.
<Mez> Keybuk: ping
<Diziet> Unless you think that's a bad approach ...
<Diziet> From your << it sounds like you've already changed mozilla ?
<doko_> Diziet: yes, removed the symlink
<Diziet> It was a symlink ?  Joyous :-).
<Keybuk> Mez: 'sup?
<Mithrandir> bounce
* Mithrandir bounces.  A lot.
<ogra> bouncer
<Keybuk> Mez: 'sup?
<mdz> Mithrandir: where is/are your casper bzr branch(es)?
<Mithrandir> mdz: p.u.c/~tfheen/bzr/casper/trunk is the trunk.
<mdz> http://people.ubuntu.com/~tfheen/bzr/casper/ ?
<mdz> ok
<Mithrandir> mdz: I just got ddcprobe working on amd64.
<ogra> Mithrandir, any package i could try on my laptop ? 
<mdz> Mithrandir: nice!
<Mez> Keybuk: apparently theres a bug in mysql you've caused?
<Mez> somehting to do with tmpfs
<Keybuk> dunno, not looked at that one yet
<janimo> mdz, Kamion have you got/read my xfce UVF exception request in mail? (sent Wednesday)
<Mez> Keybuk, basically /var/run/mysql is being set as 750 not 755
<fabbione> Keybuk: your request for info on the bug was sort of hmm "overhead" :) specially after we did talk here on irc, but i still love you :P
<Keybuk> Mez: then it's not a bug I've caused, but a bug in mysql's init script
<Mez> ah fair enough
<Mez> ah yes
<Mez> umask=077
<Keybuk> fabbione: dude, I have almost zero memory for IRC conversations ... if information isn't in the bug, it's not that useful to me
* fabbione hands some more RAM to Keybuk 
<mdz> janimo: yes, but it isn't very specific
<Mithrandir> ogra: given that I just got finished the code, it hasn't hit my local bzr repo, even
<Keybuk> fabbione: do you have resolvconf installed?  what are the permissions on /etc/resolv.conf?  is your dhcp server returning DNS information?  etc.
<ogra> Mithrandir, ping me if you need testers ... i'd love to have 1200x800 on the liveCD on my laptop :)
<ogra> 1024 looks weird :)
<mdz> janimo: not only is it a new feature branch, but it's an unreleased development branch with no release date
<Mithrandir> ogra: I also need to unbutcher the build system
<janimo> mdz, a vague release date actually :)
<fabbione> Keybuk: i think i do have resolvconf installed.. something keeps pulling it in. 4 -rw-r--r-- 1 root dhcp 50 2006-02-10 16:29 /etc/resolv.conf
<fabbione> , my dns works just fine
<janimo> but it is stable
<Keybuk> fabbione: Solution: uninstall resolvconf
<janimo> mdz, what would make you more comfortable wrt this?
<fabbione> Keybuk: danke dude.
<mdz> janimo: have you verified that all of these packages build and work with dapper versions of all dependencies?
<janimo> should I contact upstream again and try getting a statement?>
<fabbione> Keybuk: i will test monday.. i am not in the mood for a reboot now
<ogra> Mithrandir, btw, thanks for the first working ppc liveCD, will make many people happy
<mdz> janimo: if you move to the new versions and they don't work, requiring newer versions of some dependencies, you will be in a very unfortunate position
<Keybuk> fabbione: it pretty much does that for everyone ... I've no idea why Debian people seem to like it, every time I've ever had it dragged onto my machine, I've lost DNS
<janimo> mdz, I have been running on the svn version for two months
<Mithrandir> ogra: woo, goodie.
<fabbione> Keybuk: can't we conflict with it?
<fabbione> or something...
<janimo> and have built debs out of them this week so they're closer to what dapper will have
<Keybuk> fabbione: it's in universe
<janimo> mdz, there are 4 libarries and about 6 apps and over a dozen panel plugins
<janimo> besides the plugins I have tested most
<fabbione> Keybuk: yeah i know.. it's make utterly sure it's not installed.. EVER
<mdz> janimo: I know that it's always tempting to bring in the latest features and satisfy user requests, the most important consideration is to produce a solid stable release on time, and there isn't much time left
<ogra> Mithrandir, the usplash timeout should be enhanced for the ppc live version ... i saw the last 5 messages in cleartext ...
<ogra> (but thats trivial)
<mdz> janimo: we are comfortable doing this with GNOME because they have a very reliable schedule. we know that they will be stabilizing at the same time that we are
<mdz> janimo: and we start tracking development right at the start of our release cycle
<janimo> mdz, while xfce don't have a reliable schedule this time their matches ubuntus'
<Mithrandir> ogra: it's 60 seconds.
<ogra> hmm 
<janimo> mdz, at least some apps (thunar file maanger) we already use since it is decouple from the rest of xfce
<Mithrandir> ogra: what's the last message before where it switched?
<ogra> phew, i'll have to re-test ...
<sladen> ogra: get whatever is producing those message to send usplash a 'ping' to reset the watchdog
<janimo> mdz, I understand your concern, but this really does not have bugs at least not many more than the 4.2
<janimo> branch
<sladen> ogra: the timeout should probably be way less than 60seconds otherwise it's an entire minute between an error occuring and the user seeing it
<ogra> sladen, i dont think there was an error 
<janimo> there are 4-5 decoupled apps each written by one developer more or less and not interacting much with the rest
<ogra> it just vanished and continued booting in textmode
<janimo> WM, panel, desktop manager, file manager etc.
<Mithrandir> sladen: it needs to be increased on the live cd.
<mdz> janimo: if it only involves updates to xfce packages, then I'll defer the decision to you.  I just want to be sure that you have considered this carefully and understand the risks
<janimo> mdz, sure as I said it does not affect anything besides xfce packages
<mdz> janimo: we will not be able to delay the release or risk destabilizing Ubuntu proper for Xubuntu
<sladen> Mithrandir: if the it's 60seconds and the timeout has expired, that means the status hasn't been updated for 60seconds, which is a bit frustrating for the user
<ogra> Mithrandir, i've set it to 120 in ltsp to cover even the real slow clients ...
<sladen> Mithrandir: can you send it progress updates for whatever is taking that long
<ogra> it didnt feel slow  ...
<ogra> sladen, it didnt hang or feel slow 
<mdz> janimo: please send me a complete list of the affected packages
<ogra> and it didnt show an error ... 
<janimo> mdz, understood. thank you. I am aware of the risks and I agree taht ubuntu should not be affected at all by xubuntu schedule
<ogra> it just vanished ...
<janimo> mdz, will sent the list
<sladen> ogra: did anything happen on the screen in the previous 60 seconds?
<ogra> sladen, nope
<Mithrandir> sladen: no, I can't.  Pulling adduser off the CD takes about 30 secs.
<sladen> ogra: then that's a major UI bad.
<ogra> i hade the same prob with very slow booting thin clients ...
<ogra> the ui looks and feels ok ... it just times out at some point
<janimo> mdz, the list is basically what apt-cache search xfce gives minus about 3 packages but will send a complete one
<mdz> janimo: please do
<Kamion> UI bad> usplash could display some kind of moving UI element like a spinner to reassure the user that their computer hasn't crashed
<sladen> Mithrandir: just executing adduser?
<Kamion> and probably should
<Mithrandir> sladen: yes.
<Kamion> sladen: it's just the first thing unlucky enough to have to pull in a bunch of stuff.
<Mithrandir> sladen: it needs to pull perl+libs off the CD, and the file system isn't sorted very well.
<ogra> Kamion, like suse does ? 
<ogra> dancing penguins ? 
<Kamion> ogra: I have no idea what SuSE does
<Kamion> that's the bootloader
<ogra> we could adapt that uglyness :)
<Mithrandir> I think we should have dancing penguins in usplash
* Mithrandir hides from Kamion 
<ogra> lol
<ogra> we could make some videos from the next "after conf party" and have dancing developers ;)
<sladen> ogra: there's one of mark in Asia looking like a penguin that ... could be animated...
* ogra was rather thinking of something like this: http://people.ubuntu.com/~ogra/UbzGallery/CIMG0279.html
<ogra> (animated indeed)
<Robot101> the human pyramids we made in Helsinki at Debconf were coolest :P
* Keybuk smashes his mail server
<Keybuk> thought I had it working again this morning, but oh no, today it's not delivering mailing lists
<Keybuk> (that is, mailing list mails to me)
<jdub> Keybuk: time to take out that djb anal probe
<Keybuk> jdub: is pretty much entirely hardware problem
<Keybuk> fucked RAM and drive, a happy server doth not make
<tseng> jdub: DJB: We Rip RFCs a New One
<jdub> tseng: More Bettar!
<ogra> Keybuk, oh, fun... i had this after christmas ...
<Mithrandir> ogra: can you try to build a package out of (bzr) http://people.ubuntu.com/~tfheen/bzr/xresprobe/trunk/ ?
<ogra> yup
<Keybuk> ok... so if people could grab udev 0ubuntu10 and check that if they have multiple interfaces
<Mithrandir> ogra: please do test it on your ppc too, it should work just as before
<mdz> Keybuk: shall we unseed ifrename now?
<ogra> Mithrandir, will do
<Mithrandir> ogra: thanks
<ogra> Mithrandir, it will take a moment, my line is stuffed with wgetting an iso ...
<Keybuk> mdz: have committed the unseed myself; just needs an ubuntu-meta rebuild
<Keybuk> though I deliberately made ifrename not do anything if the udev rule exists
<mdz> Kamion: do we still have that powerpc unionfs bug or no?
<ogra> mdz, ppc live was fine for me 1h ago ;)
<ogra> and i didnt see any oopses 
<Chipzz> Keybuk: where can I grab it? just did apt-get update && apt-get upgrade -y and it wasn't there...
<ogra> (but usplash might have hidden them)
<Chipzz> Keybuk: and yes I have up-to-date mirrors :P
<Kamion> mdz: I have to defer to ogra on this one, I've had too much state on my powerpc to reboot it since I got back
<Keybuk> Chipzz: http://people.ubuntu.com/~scott/
<mdz> Keybuk: hmm, ifrename still provides iftab(5)
<mdz> oh, no it doesn't. wrong machine
<mdz> Keybuk: udev 0ubuntu10 DTRT on my laptop
<Kamion> Riddell: does Qt have anything like Gtk's recursive main loops?
<mdz> mdke: around?
<Keybuk> mdz: yeah, it turns out that launchpad published the wrong upload; so 9 was DTRT on my laptop, but the wrong thing ended up in the archive
<Kamion> Riddell: i.e. if you're a handler that's been called from Qt's main loop and you want to display something (let's say, ask a question) before returning, is there a way to call the main loop again until you get a response to whatever you want and then drop back to the original handler?
<Keybuk> (I uploaded twice, by accident, and didn't get a REJECT)
<Kamion> Keybuk: I filed a bug about that
<Kamion> https://launchpad.net/products/launchpad-upload-and-queue/+bug/31038
<Ubugtu> malone bug 31038 in launchpad-upload-and-queue "two accept messages for different udev 079-0ubuntu9 uploads" [Normal,Unconfirmed]  
<Riddell> Kamion: model dialogues in Qt have their own main loop
<Kamion> Keybuk: I think your second upload got accepted rather than the first?
<Keybuk> Kamion: yeah, and the second had a half-finished patch in it
<Riddell> so they can work even when the main main loop isn't running
<Keybuk> (which I've now finished and uploaded as -10)
<Kamion> Riddell: ok, so that's good for dialogs - what about if it's not a dialog?
<Kamion> as in, if you want to wait until the user hits Next or something
<Riddell> well, you can just disable or ignore anything else?
<Kamion> Riddell: ok, let me back up a second
<Kamion> Riddell: I'm trying to rearrange espresso.debconffilter so that it can be used without having to quit out of gtk's main loop to do so
<Riddell> yep
<Kamion> Riddell: so I've got it so that a handler function in debconffilter is called whenever a debconf-using coprocess (say, partman) calls a debconf function
<ogra> Mithrandir, thunk.c:14:20: error: sys/io.h: No such file or directory
<ogra> Mithrandir, missing dep on l-k-h ? 
<Kamion> Riddell: sometimes that handler function needs to wait for the user to hit Next on the whole page before it can return an answer to the debconf-using process
<Kamion> Riddell: I'm trying to work out if I can say in the handler function "wait until some other handler is called"
<Kamion> (say, the handler for the Next button)
<Kamion> Riddell: or whether I have to invent a way for the handler to drop out and say "actually, just call me back later"
<ogra> ah, no libc6-dev has it ...
<Mithrandir> ogra: install build-essential. :-)
<ogra> Mithrandir, thats in my pbuilder ...
<Riddell> Kamion: is it possible to do a while (next not clicked) {processEvents()} ?
<Mithrandir> libc6-dev: /usr/include/sys/io.h
<Mithrandir> is what I have
<ogra> Mithrandir, in your pbuilder? 
<Diziet> Why oh why oh why doesn't apt provide an interface for `please satisfy this string which is like a Depends field' ?
<Kamion> Riddell: yeah, I suppose that works, although it seems that it would spin on CPU
<Mithrandir> ogra: no, in my dapper system.
<Kamion> (if no UI events are available)
<ogra> Mithrandir, yup ...
<Riddell> I think Qt is quite clever in how it handles that, I've had no problems doing that in the past
<Mithrandir> ogra: just build it. :-)
<Kamion> Riddell: how? :-) processEvents() (or whatever) would surely return when no more events are available to be processed
<mdke> mdz, email is better, I can't hang around irc right now
<ogra> Mithrandir, no way ... same error ... even if i just run make
<Kamion> "Processes pending events, for 3 seconds or until there are no more events to process, whichever is shorter."
<Kamion> Oh, that explains it, I guess ;)
<Mithrandir> ogra: remove libklibc-dev and reinstall libc6-dev.
<Riddell> Kamion: it's just another loop, like the mainloop itself :)
<Kamion> actually, no - if there are no events to process it sounds like that returns immediately
<Kamion> Riddell: yeah, what I want is just another loop that I can cause to quit from a handler
<ogra> Mithrandir, not installed 
<Mithrandir> ogra: just reinstall libc6-dev, then.  It should surely be there.
<Mithrandir> ogra: what kind of system is this?
<ogra> ppc ibook
<Kamion> aha, it *is* possible
<Kamion> QEventLoop::enterLoop() and exitLoop()
<Mithrandir> ogra: hmm, might only exist on i386 and amd64?
<ogra> Mithrandir, nothing in locate either
<ogra> ah
<ogra> let me fire up my amd64 laptop
<Kamion> so as long as I never quit the top-level main loop, I should be compatible with Qt
<Mithrandir> so it needs build fixes for ppc, good to know.
<Riddell> hmm, yes, espresso is teaching lots of new things about the qt eventloop
<Kamion> I haven't quite worked out whether that's the best way though
<Kamion> it's just a pain in the arse to make debconffilter totally reentrant
<Kamion> but if I can, I'll do that later
<Kamion> Riddell: thanks though, would've taken me *ages* to confirm that dialogs could safely be called from handlers
<Mithrandir> ogra: does it work for you?  You might need to run it from the console, I'm not sure.
<ogra> just copying it to amd64 ... wait a sec
<ogra> Mithrandir, breaks on libx86emu.a
<Mithrandir> ogra: how breaks?
<ogra> could not read symbols
<ogra> file in wrong format
<Mithrandir> do a make clean first
<Mithrandir> ah, missing target in the clean target.
<ogra> same
<Mithrandir> just cd into x86emu and do make clean
<ogra> ok
<ogra> it works (kindof)
<ogra> reports the right card but no modes above 1024x786
<Mithrandir> hmm, guess your card sucks, then. :-P
<Mithrandir> anyway, I'm off
<ogra> the card is fine, the display sucks ;)
<dholbach> have a nice weekend
<shaya> wondering if anyone has managed to get xgl/fglrx/dapper to play nice?
<Keybuk> dholbach: how much dog-walking are you doing over yours?
<dholbach> Keybuk: I'll do a lot of apt-get.org reviewing, I guess.
<ogra> Keybuk, the dog has to pull the car to berlin ;)
<Keybuk> heh, mine would probably do that; or at least try
<Keybuk> it'd have to be a very small car though
<ogra> mine would break down with a heart attack after 100m
<ogra> even with a matchbox car
<Keybuk> we should so be allowed to bring dogs to sprints :)
<dholbach> :)
<ogra> i couldnt bring mine ... he hardly can move :/
<ogra> but we could do a sprint here in summer ;)
<Kinnison> siretart: ping?
<moew> Hello.
<moew> Anyone around?
<ogra> nope, 170 ppl hiding from you
<Keybuk> * anyone :No such nick/channel
<Keybuk> nope, don't think anyone is online right now
<ogra> nah... its friday #
<jsgotangco> saturday :)
<moew> Well whoever is around please help: I'm having trouble installing an eclipse feature, in fact I'm having this problem installing anything in root dir b/c of the Ubuntu sudo thing. How do I go around it?
<moew> Wow. The sarcasm quotient is high here.
<Kamion> worst case you can always 'sudo -s', surely
<moew> From?
<Kamion> a shell
<Kinnison> ogra: ping?
<ogra> Kinnison, pong
<shaya> or just sudo passwd root :)
<Kinnison> ogra: Can you please join us in ##soyuz1.0 for a bit?
<ogra> ## ?
<moew> I'm saying: I'm running eclipse.
<moew> I want to install a feature.
<moew> It won't install, b/c of permissions in the eclipse directory.
<moew> How would I go around it?
<moew> I can't do sudo, b/c eclipse is installing via gui. I'd like to use the gui.
<shaya> sudo eclipse
<Keybuk> moew: I suggest you try #ubuntu ... this isn't a support channel
<shaya> run eclipse as root
<moew> Oh.
<moew> Ok.
<Kamion> ah, well either (a) eclipse needs to be educated that not everyone has permissions to write to it and have some provision for installing features in your home directory, (b) you'll need to run eclipse as root as shaya suggests
<Kamion> (temporarily, in order to install the feature)
<moew> Ok.
<moew> Thank you.
<moew> I should've definitely thought of that.
<shaya> Kamion: it took firefox a while to learn that
<Kamion> Riddell: my espresso bzr tree's updated with the non-blocking debconffilter stuff now btw - but I haven't updated all component calls yet and I haven't gone on from there to make it only ever call the gtk main loop once
<shaya> or was it still firebird or phoenix then?
<Kamion> Riddell: still, it's an improvement, you might want to look at it and adapt your code, there're a few new callbacks in the frontend you need to implement
<Riddell> Kamion: ok, will look at it
* Kamion is off for the weekend, see y'all
<Kinnison> see you Kamion, have a good one
<pef> hello
<mdz> seb128: is it planned to include sound support in xchat-gnome?
<seb128> mdz: according to upstream SVN has a sound plugin
<seb128> but I've not looked what it does exactly
<seb128> you just want to "play a sound on highlight"?
<mdz> seb128: yes, a sound through gstreamer e.g. where it currently only rings the console bell
<mdz> (which I don't always hear)
<seb128> <cassidy> play a little sound when you receive a pv message or your nick is cited
<seb128> <cassidy> seb128: using libgnome
<seb128> mdz: the SVN does that
<cassidy> seb128: i'm here too ;)
<mdz> seb128: cool
<seb128> ah right, I didn't notice :)
<ogra> mdz, i'll do the ltsp breezy-updates upload soon, to be a guineapig upload for Kinnison is that ok with you ? 
<ogra> (he needs something to monitor goig to -updates )
<mdz> ogra: just the dependency change?
<mdz> if so, ok
<ogra> yup
<ogra> i thought its a good guinea pig ...
<Kinnison> mdz: thanks
<ogra> sadly bzr times out all the time ... :(
<ogra> i'm tempted to just grab the source package 
<elmo> is dapper going to have a background called 'warty-final-ubuntu.png' too? :-P
<Amaranth_> lmao
<jdub> elmo: maybe :-)
<ogra> hmm, whats the versioning policy for -updates with native packages ?
<ogra> x.xx.1 ?
<elmo> is janew updating a table of death in the wiki to track specs like breezy, or is that in LP/somewhere else now?
<seb128> lp
<elmo> seb128: thx
<seb128> elmo: https://launchpad.net/distros/ubuntu/dapper/+specstable
<seb128> np
<jdub> mjg59: what do you think about gamma fades for usplash up and down?
<mjg59> jdub: I think they'd possibly end up looking ugly
<mjg59> jdub: But we *really* need flat colours for usplash. The dithering just looks nasty
<jdub> mjg59: yeah, working on that
<mjg59> I'll try taking a look at gamma fades this weekend and see if they can be done fast enough to be smooth?
<Treenaks> I did them back in my DOS days
<Treenaks> leet demos etc.
<ogra> mjg59, if you implement that, please make it configurable ... i have usplash running on 300Mhz 64MB thin clients at users ...
<jdub> mjg59: is it harder doing them in usplash environment than X (cf. xscreensaver)
<jdub> ogra: i bet those machines do X screensaver gamma fades without any problems
<Treenaks> ogra: believe me, I've made fast fades at 640x480x8bit :)
<mayco> we are in upstream version freeze right? does that mean that there will be no new version of notification-daemon in dapper? (because the new upstream version contains a X-close button, and has a much cooler theme ( http://www.galago-project.org/news/archives/2006/02/notificationdae_3.php ))
<mjg59> jdub: I'm not sure. With luck it's just a matter of reprogramming the palette, but I'm not sure how much of an issue that is with vga16
<Keybuk> isn't the fade-out the tricky bit, you have to fade-in to X, which enjoys a blank screen for several seconds
<ogra> jdub, yup ... even gksudo works reasionably bearable 
<jdub> Keybuk: not sure it's worth fading out the boot up usplash
<Treenaks> Keybuk: the fade-out is easy.. the fade-in to X is hard (because with mode switches, you lose palette state)
<jdub> Keybuk: but worth it for shutdown usplash
<mjg59> Fade out before cutting power/rebooting?
<jdub> X starts up black anyway
<Keybuk> the problem with that kind of fade-out is that you don't know your machine hasn't switched off  :)
<Keybuk> it might be sitting there with an error message you've drawn in black
<jdub> mjg59: bonus points for random, extremely rare millennium falcon failure noise
<ogra> jdub, currently it starts blue :P
<Treenaks> Keybuk: I think they mean 'Fade from X to black; then fade from black to usplash which is doing the shutdown stuff'
<jdub> ogra: no, X starts black, then gdm starts, then during login it's blue
<ogra> ah, yes ... 
<Treenaks> jdub: yeah, and that's sucky ;)
* ogra was testing liveCDs all day)
<Treenaks> because my background is _brown_ :)
<jdub> Treenaks: easy fix, seb'll get to it
<Treenaks> jdub: whoo :)
<jdub> Treenaks: no, i meant fade out usplash right before shutdown
<jdub> mostly interested in the very start of boot and very end of halt
<Treenaks> jdub: then you don't know when your shutdown is complete, unless you happen to be watching the LEDs
<ogra> jdub, we have no usplash at shutdown yet
<jdub> ogra: suck! well, when that happens... etc.
<Keybuk> ogra: dude, we have no shutdown yet
<Keybuk> if you click the buttons in gnome, it just hangs
<HiddenWolf> talking about shutdown, has it been slow for anyone else lately?
<jdub> Keybuk: wfm
<Treenaks> Keybuk: Sending the TERM signal....
<Keybuk> jdub: doesn't for me
<Treenaks> [wait 5 minutes] 
<Treenaks> reboots
<Keybuk> Treenaks: *shrug* you're probably running something rude
<Treenaks> that's what it does for me
<jdub> Keybuk: with the gnome-session Thing, or the gnome-panel dialogues?
<Keybuk> jdub: panel dialogs
<HiddenWolf> Keybuk: nah, I have a near default gnome session, and it hangs with term for a few minutes
<HiddenWolf> Keybuk: long enough to go to the bathroom and put on tea, actually.
<Keybuk> HiddenWolf: same :)  didn't say whether that rude thing was in the default install or not
<HiddenWolf> :)
<ogra> i'm still for magically saving states in the background and just force power off ;)
<Keybuk> yeah, dapper+1 is time to remove the shutdown sequence
<Keybuk> and just "sync disks, unmount, off"
<jdub> Keybuk: was jsut about to ask that :)
<HiddenWolf> Keybuk: ehm, is that possible?
<Treenaks> Keybuk: so 0s boot, AND 0s shutdown?
<Keybuk> HiddenWolf: sure, why not?
<Treenaks> Keybuk: well, you mgiht want to tell some stuff to save their stuff :)
<jdub> HiddenWolf: aside from very particular daemons, absolutely
<Keybuk> Treenaks: like?
<Keybuk> database and mail servers probably care, but apache certainly doesn't
<Treenaks> Keybuk: true..
<Keybuk> and even those I'd contend should cope with the power going
<Treenaks> Keybuk: some gconf cruft might
<HiddenWolf> Keybuk: hibernate and suspend tend to fail quite horribly for me, I've never seen it work in any os.
<Keybuk> so should just restore from a crashed state on boot
<jdub> Treenaks: desktop stuff would be logged out
<ogra> HiddenWolf, Keybuk already took our /var/run away ... 
<Treenaks> jdub: nicely, I hope :)
<ogra> so just poweroff is nearer
<jdub> yeah
<jdub> once Keybuk is done
<jdub> you won't even need to boot to turn your computer off
<jdub> in fact
<Treenaks> But I want Xgl shiny FIRST!
<jdub> you won't be able to
<jdub> it will just be off
<jdub> by default
<ogra> dapper+1 will be so much fun :)
<jdub> for eternity
<Treenaks> ogra: yeah ;)
<Keybuk> jdub: then we won't need Malone ;)
<jdub> Keybuk: our work here is done.
<Treenaks> Keybuk: and you can keep the diffs VERY small ;)
<ogra> cool
<HiddenWolf> *chuckle* I saw that someone got xgl working. With a black background and white windows. Some X bug somewhere, apparantly. :)
<Treenaks> HiddenWolf: enough time to fix that before dapper+1
<Keybuk> I want X to go away and die
<HiddenWolf> Treenaks: I'm guessing it'll take a tad longer, driver shit and such
<Treenaks> HiddenWolf: I hope it'll at least be an _option_ in dapper+1
<Keybuk> it's a huge monolithic lump of crud that serves simply to get between you and the hardware you need to talk to
<Treenaks> Keybuk: sure, but it LOOK~S cool
<Treenaks> s/~//
<HiddenWolf> Keybuk: heh, that's putting it crudely
<Keybuk> wouldn't it be nice if you just had GL ttys
<shaya> anyone understand dpkg-divert here?
<jdub> Keybuk can
<jdub> he also enjoys it
<jdub> almost as much as "my pet goat"
<jdub> tell us a story, uncle Keybuk!
<Keybuk> Keybuk is too busy debating the relative merits of the local takeaway houses
* jdub has a nap
<mayco> we are in upstream version freeze right? does that mean that there will be no new version of notification-daemon in dapper?
<mayco> (because the new upstream version contains a X-close button, and has a much better theme ( http://www.galago-project.org/news/archives/2006/02/notificationdae_3.php ))
<slomo_> mayco: mvo is work on it afaik
<mayco> oke, thanks
<mvo> mayco: it's in dapper already
<Burgwork> mayco, close buttons are a bad idea
<HiddenWolf> Burgwork: notifications had them for ages.
<HiddenWolf> and clicking on them closes as well
<Burgwork> HiddenWolf, yes, but it forces pepole to hit a smaller target
<slomo_> mvo: it is? hmm... i only have 0.3.2-0ubuntu1 and the one on the pictures is 0.3.4
<HiddenWolf> Burgwork: people might complain that there is no way to close it - if they don't find out that clicking on the notification itself will close it too 
<Keybuk> it doesn't
<Keybuk> it makes them aim at a smaller target, but doesn't penalise them if they miss
<Keybuk> while making it obvious they can be closed/vanished
<HiddenWolf> Keybuk is obviously better with words than I am. :)
<Burgwork> hmm. Not really something worth losing sleep over
<mvo> slomo_: right, strange. I uploaded it a couple of days ago
<slomo_> mvo: hm, upload it again ;)
<mvo> slomo_: yep, my changelog was probably too long ;)
<Keybuk> mvo: can't see it on -changes
<slomo_> mvo: do you know if the dbus interface has changed between 0.3.2 and 0.3.4?
<sladen> jdub: gamma fades work for vga16 but not on vesa consoles (the new palette colour isn't used until the pixel is actually redrawn...)
<mvo> Keybuk: noticed that as well, I apparently haven't got a confirm mail. but my upload file said all fine. I tried again
<mvo> slomo_: I don't think it has
<Keybuk> mvo: lost in launchpad?
<sladen> jdub: it doesn't even need usplash changing, it can be done as a 99 script that sends the correct escape sequence to the console
<mvo> Keybuk: probably :)
<mdke> mjg59, about that problem with the computer shutting down when the screen blanks, i've had a look and it appears to be going to sleep after a few minutes, even on AC power. Sleep doesn't work on that machine, so it doesn't come back again
<slomo_> mvo: ok, good :) so i don't need to patch s-d-a again ;)
<mjg59> mdke: Hrm. Anything in the g-p-m preferences?
<mdke> mjg59, i'll boot it up again and have a look
<mdke> it should be all default tho
<mvo> slomo_: what was s-d-a again :) ?
<slomo_> mvo: service-discovery-applet
<mvo> slomo_: ah :) dosn't that one speak to n-d via libnotify?
<slomo_> mvo: nope... via dbus as there are afaik no python bindings for libnotify
<mvo> slomo_: ah, right. there has been talk about writing some, but noone steped up yet
<slomo_> using it with dbus is easy enough in python imho :)
<mdke> mjg59, AC: computer_sleep=never, display_sleep=30min, BATT: computer_sleep:20mins, display_sleep:5mins. 
<mvo> slomo_: the advantage of writing a wrapper is that if protocol changes happen it only needs to be fixed in a single place. but it's really not that much of a issue currently
<mdke> mjg59, i'll stick it in a bug report. Off to dinner now, but let me know what I can usefully include in the bug
<slomo_> mvo: well... i see no reason why the dbus API should change and the libnotify API doesn't ;)
<slomo_> mvo: still no n-d on -changes... or didn't you retry it yet?
<mvo> slomo_: I uploaded it 30min ago
<mvo> very strange
<slomo_> interesting...
<slomo_> mvo: hmm... can you upload it somewhere else? let me try to sign and upload it
<mvo> slomo_: I'll ask the launchpad team about it first, maybe it's some real bug
<mdke> mdz, i'm around now if you are still here
<mdz> mdke: I wanted to chat about the flash demo
<mdke> me too
<mdz> we're on a very tight timetable and the content developers need to start immediately if we're going to get this done in time
<mdke> right, they said
<mdke> I've started putting down some rough ideas today, I wanted to clarify what you are looking for quickly
<mdke> mdz, first up, is the demo going to be the same for ubuntu and kubuntu?
<mdz> mdke: we only have time for one demo, so we'll do ubuntu
<mdke> so we can do gnome-specific things
<mdke> ok
<mdz> were you CCed on Mark's email with his requirements?
<mdke> yes
<mdz> ok
<mdke> i copied them to a wiki page and started brainstorming
* mdke gets url
<mdke> https://wiki.ubuntu.com/GreatFeaturesOfUbuntu?action=show
<mdz> this looks great
<mdke> i was wondering whether to send out some calls for ideas to the community in general, or just to finish that off
<mdke> I asked jeff to have a look at it
<mdz> we can't wait for a lot of feedback
<mdke> yeah, i figured
<mdz> but certainly it's welcome
<mdz> I think this is enough of a starting point that we can get the flash guys going
<mdke> ok the last thing was, do we just get some words together, then pass it on to them?
<mdz> we need to finalize, say, 5 items and send them off to them
<mdz> we need a sort of storyboard for each
<mdz> e.g., screenshot of the application showing this and that action
<mdz> ideally you could send them existing screenshots from the docs
<mdke> we don't have many screenshots tbh
<mdke> certainly none that are update to dapper gui
<mdz> I can show them how to make screenshots in vmware or something
<mdke> ok, so on that page I should include instructions about how to do the described feature? Like "open x prog, do this, etc"?
<mdz> but they will need to know what actions they should be demonstrating
<mdz> yes, that would be a great help
<mdke> right, ok
<mdke> last last thing.
<mdke> is the gui frozen now?
<mdke> if not, we should probably try to identify things for them to start on which won't change
<mdke> if the artwork is going to change, it will make things a bit tricky
<Burgwork> gai might be a good starting point
<mdz> it's not frozen until UI freeze
<mdz> the artwork will definitely change
<mdke> yeah
<mdz> mdke,Burgwork: what time zones are you guys in?
<mdke> how are we going to handle that?
<mdke> utc +0
<Burgwork> mdz, same as you
<mdz> would you mind having a phone call with todd/bryan?
<mdke> not at all, he has both our numbers now
<mdz> I think it would greatly accelerate things if we had a conference call and talked this out as a group
<mdz> ok
<mdz> and mine
<mdz> please email some possible times for early next week
<mdke> ok, sure
<mdz> and we'll do that
<mdke> Burgwork, do you wanna get together over the weekend and build up that wiki page?
<Burgwork> mdz, I already spoke with bryan yesterday. He and I are going to chat some more today
<mdz> bryan may be able to talk with you over the weekend, though I'll be unavailable
<mdz> Burgwork: oh, good
<Burgwork> mdke, sure, but we have to plan now, as I don't know if I will have internet at home or not
<mdke> Burgwork, sure thing, I'll be around on/off for the next few hours
<mdz> mdke: the translations item should highlight help->translate
<mdz> or maybe break it into two, one about the language selector and one about rosetta
<mdke> right, yeah.
<Burgwork> we want about 10 animations?
<mdke> that's the idea
<Burgwork> mdz, how long is espresso expected to take?
<Burgwork> the actual install
<Burgwork> also, how big are the animations going to be?
<mdz> Burgwork: unknown as yet; Kamion will have the best estimate
<mdz> probably on the order of 10 or 15 minutes?
<Burgwork> ok, so 10 animations at a minute and a half seems reasonable
<mdz> big as in pixels, or bytes?
<Burgwork> pixels
<mdz> they'll make them whatever size we want, I imagine
<mdz> I think a minute is probably too long for most of the segments; we should keep them short and snapy
<mdz> and we can play as many as will fit during the installation
<Burgwork> however it is somewhat constrained by the actual screen size and what else needs to be displayed
* mdke thinks the tech guys can see to that, but we need to get the subject matter sorted asap
<Burgwork> the actual size of the final animation does change what we put into it, imo
<mdz> say 320x240
<Burgwork> ok good
<mdke> Burgwork, how about you have a go at that wiki page in the next few hours, then I'll take a look this evening and try and sort out some storyboarding, since I'll have some time tomorrow/sunday
<Burgwork> mdke, already editing
<mdke> great stuff
<mdke> ok I'll be back in a bit then
<mdke> thanks Burgwork/mdz
<mdz> thanks
<Burgwork> does rb do cd burning now?
<HiddenWolf> Burgwork: it should open serpentine
<Burgwork> HiddenWolf, ah, ok
<HiddenWolf> That, or nautilus
<HiddenWolf> Used to be serpentine, now looks like nautilus
<mvo> slomo_: notification-daemon finally uploaded, my upload was broken, but lp didn't send a mail about that. so now I uploaded a fixed version and lp will send mails about this in the future
<slomo_> mvo: ok, cool :)
<Burgwork> mvo, you still awake?
<mvo> Burgwork: yes
<Burgwork> mvo, where is gai with regards to its UI?
<zyga> mvo: new n-d?
<zyga> mvo: the one from galaga/
<mvo> zyga: yes
<mvo> Burgwork: unless I get a override by the UI team I think the gui is pretty much what we want for dapper
<Burgwork> mvo, ok
<mvo> Burgwork: is this about the "woah, we are cool" project :) ?
<Burgwork> mvo, the flash one? yes
<mvo> Burgwork: nice :) I need to ask mpt and mark for review of the new gui, but the only change that we probably get is a All category on the left
<mdke> will g-a-i be able to install all programs, or just some?
<mvo> mdke: what do you mean with that :) ? It will be able to install everything that it displays
<mdke> mvo, i mean, will it be able to display everything in the archive, or just some things?
<mdke> for example, will I be able to install gstreamer plugins
<mvo> mdke: no, it will only display stuff with a desktop file currently
<Burgwork> mdke, gstreamer is covered by https://wiki.ubuntu.com/DesktopTeam/CommonInstallHook
<mdke> mvo, and will that improve by april?
<Burgwork> mdke, no
<mdke> :(
<mdke> that's a shame, from a documentation perspective it's tricky: we have to say "to install X, open Y program, do a search, if you can't find it, open Z program"
<Burgwork> ya
<Burgwork> the idea with commondesktop hooks it to make the documentation useless
<Burgwork> because it will just install it
<mdke> then the user says "why on earth don't I just use Z program"
<Burgwork> if they use mplayer,etc?
<mdke> i mean, the user will say "if there is a program which can install anything, and one which can't, why shouldn't I just use the first one all the time instead of looking in both places?"
<Burgwork> yes, a few users will say that
<Burgwork> most will be happy to just have it install automatically
<mdke> you can't install everything automatically tho. But if that is implemented it would be an improvement, yeah
<Burgwork> yes, for dapper we are still stuck
* mdke plays with the idea of just using synaptic in documentation
<mvo> mdke: it's a tricky problem. if we want to display everything, we need to tell the user the concept of packages and dependencies
<mdke> mvo, how about not displaying everything, but having everything accessible in the search option
<mdke> so, if a user reads the documentation and sees he needs gstreamer-plugins-bad, he can search for it and install it
<mdke> even though it isn't in the categories on the left
<mvo> mdke: in our current g-a-i a search is really a filter (like in epiphanys bookmarks or in rythmbox, so that won't work unfortunately
<mvo> I agree with you that it's supoptimal to have two applications for the same task
<netdur> did you set epyphany as default browser for dapper?
* mdke nods
<mdke> netdur, yes
<mdke> netdur, argh, I mean, I personally did
<mdke> ubuntu didn't
<mvo> mdke: for selected packages (like the gstreamer stuff), we could add a pseudo package for that
<mdke> mvo, the search can't be expanded, maybe for dapper+1?
<netdur> mdke, would be wise choose for ubuntu too!
<Amaranth> ubuntu won't, afaik
<netdur> I know
<mdke> netdur, yeah
<mdke> mvo, problem is, I was just using gstreamer as an example, there must be loads of things that a user might look for
<mvo> mdke: I think so, yes. we'll switch to smart most likely and that means we need to rework our tools anyway
<mvo> mdke: *nod*
<mdke> mvo, what do you think we should suggest to users for documentation? use synaptic all the time, or use gai, then try synaptic if they don't find it?
<Amaranth> switch to smart?
<HiddenWolf> mdke: gai is/was quite limited, introduce them to searching in synaptic would be my suggestion
<mdke> mvo, by the way, gai goes to sleep when I try searching for "gstreamer", have you got a bug like that already?
<mvo> mdke: did you typed it into the search field and pressed enter?
<mdke> yes
<HiddenWolf> mvo: wow, i take it back
<HiddenWolf> gai looks good
<mvo> mdke: yes, known. I'll upload a fixed version in a couple of minutes
<mdke> yeah the look is awesome now
<mdke> mvo, heh, great service, thanks
<HiddenWolf> mvo: while searching the interface should not go grey
<mvo> HiddenWolf: thanks :)
<mdke> mvo, any thoughts on the documentation question?
<mvo> mdke: it's a hard one. I *think* you should point them to synaptic for the "complicated" stuff
<mvo> I mean, g-a-i should be pretty self-explaining
<mdke> ok, i think we'll have to do that
<mvo> it has very few buttons nowdaydays
<HiddenWolf> mdke: gai invites to click on the sections
<mdke> each thing to install should say whether to install it with gai or synaptic
<HiddenWolf> mdke: they might be discouraged if they don't find it in the right section or something.
<mdke> it's a lot of work to check them all though
<mvo> mdke: you mean, you search, it finds gstreamer-bad and says it should be installed with synaptic?
<mvo> mdke: or do you mean in the current documentation?
<mvo> mdke: where is that located?
<mdke> i mean in the documentation
<mdke> System -> Help -> Ubuntu Desktop Guide
<mdke> we need to upload a new version of that, it's a bit out of date with our repo
<mdke> up to date version is at http://doc.ubuntu.com
<mvo> mdke: ok, thanks. what do you think about making the stuff that is in the guide available via g-a-i ? the codecs etc? 
<mdke> mvo, we could do some of the major stuff, that would rock
<mvo> mdke: could you please file a bug, wishlist but with dapper as target and assign it to me? that would be great
<mdke> okies
<mdke> mvo, while I'm at it, another bug is that the entry in the menu for gai is too long and can't be read
<mvo> and please point to the documentation in it too :)
<Burgwork> mvo, can you have a .desktop file that doesn't display any menu entry
<mvo> Burgwork: it will need some tweaks in the code, currently not
<Burgwork> mvo, cause they you could install a .desktop file in the codecs
<mvo> Burgwork: yeah, as I said, it will need some tweaking in the code, but shouldn't be too hard. I will probably need some discussion how to do it in the gui
<Burgwork> I think it is too late to do this kind of installation for dapper
* mdke tends to agree
<mdke> if anyone with main upload access and 3 spare minutes could fix bug 30694, that would also be lovely
<Ubugtu> malone bug 30694 in xmms "unfriendly menu entry for XMMS" [Normal,Unconfirmed]  http://launchpad.net/bugs/30694
<Burgwork> why is xmms in main?
<Amaranth> yeah, that doesn't seem to make sense
* mdke has no idea either
<mdke> i originally just assumed it was in universe
<dw_> anyone with any idea on whether the current daily is ok?
<Burgwork> nothing in seeds or xmms changelog about why it is in main
<mvo> Burgwork: it is there since warty :)
<mdke> lol, my default editor appears to be vi, rather than nano as it was before
<mvo> there was some talk about demoting it
<Burgwork> yes
<mvo> Burgwork: because of the new code that may break etc?
<Burgwork> mvo, yes, and feature freeze is just around the corner
<Burgwork> plus mdz would take my head off if I convinced you to do that over your other dapper goals
<mvo> yeah, agreed. it's this "it can't be hard to add and is so nice" syndrom. but I should overcome it I think
<mvo> anyway, bedtime for me
<mdke> night mvo
<mvo> night everyone 
<Mirv> hi.. are update-manager and gnome-app-install going to be back at the cvs.gnome.org anytime soon? are the sources currently in any svn/cvs?
<Burgwork> Mirv, they are currently in bzr
<Mirv> Burgwork: that is.. Bazaar-NG? sorry, but how do I access the source? addresses like https://launchpad.net/products/gnome-app-install just point to the gnome.org cvs
<sloncho> hi. as it's related to the kernel, and looks like noone on ubuntu channel can help: how do I prevent a kernel module from loading (pcnet32). I added it in /etc/hotplug/blacklist, I deleted pcnet32.ko from all instances under /lib/modules, and still when I boot, it is loaded. I do not know why.
<Burgwork> Mirv, bzr is bazaar-ng. baz is bazaar 1
<Mirv> okay via https://launchpad.net/distros/ubuntu/+source/gnome-app-install I can at least access the latest releases, though still no sight of an actual repository
<Burgwork> email ubuntu-desktop and ask about it and ask mvo to fix it
<Mirv> okay, so basically it's just that mvo is developing furiously and has not had a time to set up a repository access? fine for me, it's just hard to find the latest code
<Burgwork> no, it is that the bzr repos are not listing on lp
<Burgwork> they exist somewhere
<Mirv> ah, ok.
<Mirv> I will send an e-mail to the list
<Burgwork> http://people.ubuntu.com/~mvo/bzr/
<Burgwork> Mirv, ^
<Mirv> Burgwork: interesting. thanks anyway for your help.
<Burgwork> Mirv, that should be the lastest bzr sources
<Mirv> though not for update-notifier
<Mirv> oh, I didn't ask about it yet :) anyway, it was the third on my list.
<Mirv> https://oops.ghostprotocols.net/repos/upgrade-notifier/ has something updated this year, but not the most recent
<jdong> ouch.... that kernel update hurt
<Amaranth> *boggle*
<Mirv> oh it is the most recent
#ubuntu-devel 2006-02-16
<cogumbreiro>  does anyone know how to update the update the filetype database (under gnome)?
<cogumbreiro> i've installed my application which registers MimeType=audio/x-scpls;audio/x-mpegurl;
<cogumbreiro> but I see no association in nautilus
<MisterN> n8
<crimsun> hmm.
<zul> heylo
<Drac[Server] > I'm going to install isapnptools. Once I do that, how will I use it to make Ubuntu use my ISA ethernet adapter?
<HiddenWolf> anyone here use evolution?
<TheMuso> n/c
<shadeofgrey> okay guys
<shadeofgrey> look
<shadeofgrey> im not a coder
<shadeofgrey> but i really need to talk to the grandpoobah's currently in this channel about updates that were offered as of yesterday to dapper users yesterday...
<shadeofgrey> because it did something rather amazing
<shadeofgrey> it enabled kde and gnome to be running simultaneously
<shadeofgrey> ive got gnome up top, and the kde panel at the bottom
<shadeofgrey> and i didnt request my machine to do so as far as i cvan tell
<shadeofgrey> i didnt even think such a thing was possible
<Drac[Server] > I'm going to install isapnptools. Once I do that, how will I use it to make Ubuntu use my ISA ethernet adapter?
<LaserJock> shadeofgrey and Drac[Server]  : this really isn't a support channel
<shadeofgrey> no i know that
<LaserJock> shadeofgrey: I would look in the gnome sessions and see if the kde panel is in there
<shadeofgrey> im just trying to terll you that something in the update packages from yesterday did something unspeakable to my machine
<shadeofgrey> how do i turn off kde?
<shadeofgrey> i mean, i need some of it because i run k3b
<shadeofgrey> but ive never had to use the whole window manager and panel system before
<LaserJock> I don't think you have all of kde on, just the panel
<shadeofgrey> and id really like to turn it off if its possible
<Drac[Server] > LaserJock, I know, but nobody in the actual support channel knows a goddamned thing about isapnptools.
<LaserJock> Drac[Server] : have you searched wiki.ubuntu.com and the ubuntu forums?
<LaserJock> shadeofgrey: so go into something like System->Preferences->Sessions and look for kde apps
<shadeofgrey> okay
<shadeofgrey> see
<shadeofgrey> thats all i neededto know
<shadeofgrey> and i couldnt get any hgelp out of the people in thd support channel
<shadeofgrey> because all the good guys and girls have gone to bed
<shadeofgrey> now the channels just flooded with people that need help and cant get any a this hour
<LaserJock> shadeofgrey: I understand , I get a headache every time I try to go over there
<lakin> shadeofgrey: and when things are truly broken, use the launchpad to report the bugs.
<shadeofgrey> i dont know what the launchpad is
<shadeofgrey> or how touse it
<shadeofgrey> the problem with the suppoort chaneel in my unhumble opinion is that EVERYBODY wants help right away
<Drac[Server] > LaserJock, I hadn't thought of the forums. There seems to be something quite similar, here. I'll see if it does the trick.
<lakin> shadeofgrey: https://wiki.ubuntu.com/ReportingBugs
<shadeofgrey> and less than 10-% of the people are willing to be polite, patient, and wait their turn
<lakin> Drac[Server] : another secret tool that none of developers tell the users about is google.com  asking it got me to here, which might help? http://www.roestock.demon.co.uk/isapnptools/isapnpfaq.html
<shadeofgrey> thankjs guys
<shadeofgrey> i fixed it
<Drac[Server] > lakin, I don't need help with isapnptools. I just need help getting it to see the card, which it doesn't. pnpdump returns "No boards found" and such.
<shadeofgrey> listen...  before i go i just wanted to say thanks for everything you guys do
<shadeofgrey> without you ubuntu wouldnt exist and id be stuck with windows
<lakin> "I don't need with isapnptools. I just need help getting it to ... "   your definition of needing help with a package is obviously completely differen than mine.
<Toma-> is dapper going to have easier removal of meta-packages...? or is that a question i should direct to the apt team? for instance, some newbie just asked of a way to remove kubuntu-desktop and all its packages, and the only way ( that i know of) is thru debfoster, which in the hands of someone that doesnt knw what theyre doing, can be dangerous...
<LaserJock> Toma-: I really don't have an answer for you but it seems like I remember hearing something about that being some where down the road for apt I think.
<Toma-> ahh k cool
<LaserJock> Toma-: but I think the problem would be the same as is with debfoster
<LaserJock> Toma-: it is hard to make a program that has good judgement ;-)
<Toma-> mmm. is it possible to make a deb that conflicts with everything from kubuntu-desktop, that would make it remove all conflicting files?
<Toma-> :)
<LaserJock> and anti-kubuntu-destkop package? ;-)
<crimsun> you can already use the method(s) outlined in #ubuntu
<Toma-> removing kdelibs4c2?
<crimsun> and libarts*
<Toma-> LaserJock, exactly :)
<Toma-> crimsun, i c. 
<Toma-> im just thinking a noob-friendly synaptic click option maybe to remove a meta-package... maybe with some debfoster integration or something.
<LaserJock> Toma-: well, I think it is a little easier said than done. Users tend to get a little upset when you start removing packages ;-)
<Toma-> yeh... but the whole "you can install a meta-package, but you cant remove it all" is a bit of a pain for the user... not me, but just for the general population
<freeflying> pitti: pig
<hunger> freeflying: Hey, be nice ta pitti:-)
<freeflying> sorry for wrong spelling
<freeflying> pitti: sorry for wrong spelling 
<hunger> freeflying: I shouldn't make fun about typos (or at least avoiding typos while doing so).
<freeflying> hunger: anyway , I'd thanks u for pointing out  that 
<pitti> freeflying: pog :)
<freeflying> pitti: sorry for that spelling errror
<Huahua> hello, pitti
<pitti> freeflying: nevermind :)
<pitti> hy Huahua 
<freeflying> pitti: Huahua is a member of we ubuntu-cn team
<freeflying> pitti: he has some idea about fontconfig
<freeflying> pitti: want cominucate with you 
* sivang hugs pitti 
* pitti hugs sivang
<sivang> pitti: maybe you have an idea why du -sh and nautilus report different directory dizes for my home dir?
<sivang> pitti: nautilus says 8.9G and du says 11G
<pitti> sivang: hm, maybe one counts blocks and one adds bytes?
<neuralis> sivang: apparent size vs. real size, probably.
<sivang> neuralis: I tried with du --apparent-size as well, same result
<sivang> pitti: hmm, maybe. in that case it seems that nautilus counts blocks.
<sivang> ah, also seems dh calcs GB's by / 1000000000
<sivang> s/dh/du/
<freeflying> pitti: I found old ttf-arphic-* still in ubuntu desktop seed 
<pitti> freeflying: yes, mainly due to space constraints, I think
<jeroenvrp> dapper: if I do a apt-get install base-config (to have apt-setup) it conflits with locales (nl and en) and java (j2re1.4)
<mantas_> Hello all
<mantas_> doko, are you online ?
<mdke> mvo
<mdke> whoops, not here
<SteveMyers-Debug> anyone know how long it takes to do the deb_build for the linux kernel? I am debugging the new kernel 2.6.15-15 and it's been running all night. Does anyone know the average time for a kernel degbug?
<SteveMyers-Debug> P.S I'm building the deb at the moment
<zakame> siretart: ping
<siretart> zakame: pong
<mdke> siretart, did they fix breezy-updates?
<ogra> mdke, was something wrong with it ? 
<ogra> https://lists.ubuntu.com/archives/breezy-changes/2006-February/012872.html
<ogra> my upload yesterday was processed fine it seems
<mdke> ogra, you know that something was wrong with it :)
<ogra> it moved to soyuz, but there was nothing wrong ...
<siretart> mdke: I havn't heard any news on that topic :(
<siretart> hm. ogras upload went fine, perhaps it is working already and I didn't notice. 
<ogra> but since the DC is being moved around today anyway ...
<mdke> ogra, soyuz wasn't allowing uploads to -updates, it must be fixed now if you uploaded yesterday
<mdke> siretart, fancy giving it a try?
<siretart> good idea :)
<ogra> mdke, my upload was the guinea pig, yes... but there was nothing broken, it was expected downtime due to the move to soyuz
<mdke> ogra, not so sure it was expected :)
<ogra> and since the DC is being shuffled this weekend you might not see the binarys right away you upload today ...
<ogra> mdke, it was
<mdke> well the soyuz guys seemed surprised that siretart's uploads didn't work
<siretart> ogra: I'm happy if my upload wasn't rejected
<ogra> it was announced that -updtaes and -security wouldnt work ..
<ogra> so i wouldnt call it broken ;)
* siretart searches that bit in the announcements
<ogra> siretart, in this channel ...
<ogra> warty and hoary -updates arent expected to work yet afaik
<siretart> sorry, I don't read this channel 24/7, a notice to u-d-a would have been really nice
<ohoel> could a broken initramfs be related to network interfaces clashing? (eth1, eth1_clashed -> n-m not recognizing wireless eth1_clashed (was eth0))
<ogra> do you really expect a note to u-d-a for every small incident that happens during an announced change in the complete infrastructure ? 
<ogra> ohoel, thats udev breakage ...
<mdke> -updates going down is not small
<siretart> no, I don't expect every small incident reported to u-d-a
<ogra> mdke, a complete build infrastructure change isnt small.... i'd expect the things to take up bit by bit in such a case 
<mdke> ogra, i was simply asking if it was fixed. I'm glad if it is
<ogra> breezy is ... 
<ogra> i'm pretty sure warty and hoary will wait until there is a guineapig to test with first ...
* freeflying is away: go to bed . night all!
<Mithrandir> freeflying: please turn off public away.
<freeflying> Mithrandir:  sorry for bothering  :)
<HiddenWolf> crimsun: ping
<dilinger> mmm
<dilinger> http://www.freedesktop.org/~davidr/xgl-demo1.xvid.avi
<Coyctecm> will xgl be in dapper?
<mdke> Coyctecm, no
<Coyctecm> :(
<hunger> Coyctecm: From the discussion on ubuntu-devel I guess not.
<Coyctecm> well, it's not so necessary. I'll get the job done without it ;)
<mdke> upstream version freeze was a while back
<mdke> maybe you can install it yourself though
<Coyctecm> yep
<dilinger> Coyctecm: i'm hoping dapper+1
<dilinger> Coyctecm: have to bug daniels about it :)
<HiddenWolf> mdke: it's hellish to install currently
* hunger still remembers the "GL is not necessary on the desktop" he got all the time a couple of years back:-(
<dilinger> s/bug daniels/bribe daniels/
<Coyctecm> opensuse 10.1 will have it
<mdke> HiddenWolf, even more of a reason not to include it in dapper
<HiddenWolf> Coyctecm: yeah, duh, they've developed it inhouse, and thus had months to plan inclusion
<mdke> dilinger, is daniels coming back to work on Ubuntu then?
<HiddenWolf> Coyctecm: you can bet it won't be default tho.
<Coyctecm> yes
<dilinger> Coyctecm: suse also was one of the first distributions to include reiserfs, though.  speaks volumes against their judgement wrt stability
<dilinger> mdke: oh, i didn't know he left
<Coyctecm> but as I sayd i think I can live and get the job done without xgl :)
* mdke nods
<HiddenWolf> mdke: has he left, or taken time off?
<mdke> i dunno
<sivang> does anyone know a good intro for threads in python (not threading.Thread) ?
<sivang> I've been googleing around and nothing good came up
<HiddenWolf> Coyctecm: without decent drivers it is pretty useless, so it makes so sense to use it by default. The vast majority of users won't use binary ati/nvidia.
<Coyctecm> HiddenWolf, yes i agree. And it's still waste of resources
<sivang> crimsun: maybe you know a good intro for python threading using the "low level" module?
<sivang> HiddenWolf: how painful is it to set up? 
<HiddenWolf> sivang: painful, apperantly
<HiddenWolf> sivang: friend of mine has been trying for 2 days only to find out that his geforce doesn't support it.
<sivang> HiddenWolf: what type of card was that? (I have GF2 GTX)
<HiddenWolf> sivang: and manually building xorg with cvs mesa/glitz and whatnot is hardly fun for most of us.
<sivang> ah, bah
<sivang> yeah sounds painful
<HiddenWolf> sivang: he has a gf2mx. problem is that the card needs to support pixel shaders
<hunger> someone claimed earlier that xgl works fine with ubuntu's xfree plus a manually build glitz on kubuntu-devel.
<HiddenWolf> he has the cube, and the wobbly windows, but his background is black, with white windows
<HiddenWolf> hunger: my friend is on gentoo. Haven't tried myself, altho I'm dying to try. :)
* sivang joins that
<sivang> hunger: would you know by any chance a good intro to "low leve" threading in python, that is not using threading.Thread ?
<hunger> sivang: No. My python is somewhat rusty:-(
<Coyctecm> I was problems in breezy with pci-e x600 radeon on amd64
<hunger> Coyctecm: Yeah, I have problems, even without the amd64 part:-)
<Coyctecm> but libdri.a hack fixed it :) hope xorg 7 has better support for my cardm i really don't like to use binary drivers
<hunger> Coyctecm: Which hack?
<Coyctecm> hunger: wait a minute...
<HiddenWolf> sivang: http://www.webalice.it/cimi86/gnome/xgl_gray.avi
<HiddenWolf> sivang: gentooers get all the fun. :)
<Coyctecm> hunger: http://ati.cchtml.com/show_bug.cgi?id=198
<hunger> HiddenWolf: Well, they get all the building, too.
<HiddenWolf> hunger: well, so true. :)
<sivang> HiddenWolf: heh , well you recall what mark said, 'stable and boring'
<Coyctecm> i have used linux since 98 but never tryed gentoo
<hunger> HiddenWolf: I hated gentoo when I tried it. And the cool apps were not available either most of the time.
<hunger> Coyctecm: Thanks!
<HiddenWolf> sivang: true, but lots of people are going to try and will be screwing their systems first and begging for help later.
<HiddenWolf> sivang: or download stuff from shady sites and repo's
<Coyctecm> hunger: try it replace the libdri.a with version avaible in that link, after that I got the direct rendering work with fglrx
<hunger> Coyctecm: Oh, I thought you did not use the binary drivers.
<hunger> Coyctecm: They break sleep mode here... no fun on a laptop, so I do not use those.
* hunger mumbles that maybe he should retry, now that ubuntu broke sleep anyway.
<ogra> hunger, ??
<ogra> WFM ...
<hunger> ogra: sleep mode is broken in dapper on my box. Filed a bug about it.
<ogra> ah
<ogra> works on my ibook ... and the first time even on my amd64 laptop ...
<hunger> ogra: Really bites me since dapper has a broken shutdown as well...
<Coyctecm> hunger: i almost must to use them with xorg 6.8.x, native support is too bad, hope that xorg 7 has better support
<hunger> At least on my box.
<ogra> thats only on new installs afaik ...
<hunger> ogra: Mine is no new install.
<ogra> all my upgraded systems shut down fine ...
<ogra> i see it on liveCds only here
<hunger> ogra: I'm following the development versions since shortly before hoary came out.
<Coyctecm> I was just thinking to upgrade breezy to dapper
<hunger> Coyctecm: I wouldn't.
<ogra> hunger, i'm doing my daily work on the development versions ... i dont see any shutdown robs on any of my systems ...
<ogra> *probs
<hunger> Coyctecm: dapper is seriously borked for me at the moment.
<ogra> only if i test liveCDs
<hunger> ogra: I do:-(
<HiddenWolf> ogra: TERM hangs for  a few minutes for me on Dapper
<Coyctecm> hunger: ok I'll wait :)
<ogra> udev has some weird issues with NIC naming currently, but apart from that, dapper is fine on 6 machines here
<Coyctecm> I have no hurry to upgrade, i'll wait :)
<hunger> ogra: Hmmm... my NICs are not set up automatically,even though ifup does not ork because it thinks they are up already.
<hunger> ogra: But apart from that I have no issues with udev (I think).
<ogra> hunger, did you try the latest ? 
<hunger> ogra: Power management is all borked (I am using kubuntu).
<ogra> it starts giving your NICs very weird names ...
<hunger> ogra: My system is current with what is in the repro right now.
<hunger> ogra: ifconfig -a lists lo only.
<ogra> cat /proc/net/dev ?
<hunger> Oh, fonts are completly unreadable at the moment, too. So I am stuck out of X (can't read anything there).
<hunger> ogra: lo, ath0, eth0, sit0. Looks fine.
<ogra> yes, Riddell is working on getting the dpi settings solved for KDE afaik
<hunger> ogra: But I did a ifdown/ifup on ath0 to get into the net.
<hunger> ogra: Those did not change (yet?).
<Coyctecm> are you guys getting paid for developing dapper? :) is this official developers channel?
<Coyctecm> just curious :)
<ogra> yes
<hunger> It is the official channel, but I am no developer.
<ogra> and yes
<Coyctecm> ok :)
<hunger> Coyctecm: Just hang out here to listen in and complain if I can not find out which package to whine about (so that I can not complain via the bugtracker).
<ogra> but there is only a small percentage of the 160 ppl here working full time on ubuntu ;)
<Coyctecm> :)
<hunger> ogra: My application was just rejected:-(
<ogra> hunger, application for what ? 
<hunger> ogra: QA engineer at canonical.
<ogra> ah
<ogra> sad ...
<Coyctecm> I program a lot of stuff too with python, but those are just my own "hacks" :)
<ogra> i dont know the criteria apart from whats on the website though ...
<hunger> ogra: Not really a surprise. But I had to give i it a try.
<ogra> sure, anybody with at least minor QA experience should 
<hunger> Would have been fun to work on ubuntu. Can't do much for it at the moment, too much work:-(
<Coyctecm> it would be great to work full time with some distro :) just that here in finland are not too many companies..
<Coyctecm> I'll think novell is only one...
<HiddenWolf> Coyctecm: work remotely, like most hackers. :)
<Coyctecm> sure, first Ill just have to get some company like canonical to hire me :) 
<Coyctecm> of all* :P
<HiddenWolf> So give it a shot. :)
<Coyctecm> yeah, i mail to mark shuttlework :) 
<Coyctecm> well.. not. :D
<HiddenWolf> Hm, it'll be good to have a QA person bug triager for ubuntu. :)
<HiddenWolf> amount of bugs is getting so huge.
<hunger> HiddenWolf: Take me, take me;-)
<Coyctecm> me! me!
<HiddenWolf> hunger: heh, I'm just a groupie. :)
<hunger> HiddenWolf: Then I could get my stuff fixed sooner;-)
<Coyctecm> :D
<hunger> HiddenWolf: So what, so am I.
<lemsto> mondus44
<Coyctecm> damn there is cold outisde :( 
<Coyctecm> outside*
<lemsto> how many flight is there before final release?
<nictuku> what is the canonical way to define the current distribution in a given machine? checking sources.list wouldn't be a good approach, would it?
<nictuku> I'm coding NetworkWideUpdates and I'm sort of stuck there.
<azeem> nictuku: /etc/lsb_release
<nictuku> hmm lsb-release
<azeem> of course, that is modulo manual fiddling or partial upgrades
<nictuku> Do you know if that file is always available in Debian sarge, too, in a minimal installation?
<azeem> I don't think so
<azeem> there is /etc/debian_version though, as well
<nictuku> hmm nice
<azeem> actually, I am sure it isn't, as I don't have it here
<nictuku> good to know, then
<nictuku> is there anywhere saying "3.1" in debian? :-)
<tseng> debian_release?
<nictuku> I can't check that, vanilla ubuntu here.
<azeem> debian_version says that, yes
<azeem> mbanck@blackbird:~$ cat /etc/debian_version 
<azeem> 3.1
<nictuku> ok. thank you - In ubuntu it says "testing/unstable".
<tseng> since thats the debian release its based on
<nictuku> yes, sure.
<nictuku> I was afraid that in debian it would say the codename, not the version number.
<AlinuxOS> hello guys someone can tell me how can I see a .po files statistics ? translated, fuzzy et?
<HiddenWolf> AlinuxOS: launchpad.net/rosetta
<AlinuxOS> HiddenWolf, not on the web
<AlinuxOS> locally
<elmo> NOTICE: *.ubuntu.com and other Canonical hosted services are going down in 10 minutes, see https://lists.ubuntu.com/archives/ubuntu-announce/2006-February/000049.html for more details
<LadyNikon> hey
<LadyNikon> you guys know www.ubuntu.com is down?
<ogra> yes
<mdke> yes, the server is down
<LadyNikon> ok
<ogra> https://lists.ubuntu.com/archives/ubuntu-announce/2006-February/000049.html
<LadyNikon> i know you probably have heard it a million times heh
<LadyNikon> so sorry.
<mdke> you're the first
<LadyNikon> your kidding.
<ogra> its down since some minutes only ...
<tseng> hi ogra 
* ..[topic/#ubuntu-devel:mdke] : 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 | Flight CD 3 released | If your initramfs is broken in any way, please save a copy for infinity | LP Upgrade was today, please report bugs if you see 'em | Ubuntu Servers are down for maintenance
<ogra> hey tseng 
<LadyNikon> ogra: heh.. i cant access that either 
<mdke> it's all down
<ogra> ah, yes, indeed ...
<LadyNikon> is there a mirror i can download ubuntu from?
<ogra> heh
<ogra> archive,ubuntu.com was redirected... should still work ...
<ogra> cdimage isnt though afaik
<mdke> http://releases.ubuntu.com/
<mdke> that works
<LadyNikon> can anyone change the topic in #ubuntu to reflect that as well
<mdke> ok
<mdke> topic is locked
<HiddenWolf> HEY, HO, HELP! UBUNTU.COM IS DOWN -- just to be the first of the panicy people
<HiddenWolf> :)
<mdke> they are fascists in #ubuntu these days
<HiddenWolf> mdke: One's got to have some rules in a channel of that size.
<mdke> some rules, sure
<LadyNikon> mdke: Sorry this site is currently unavailable as it's down for maintenance. It should be back shortly. Apologies for the inconvenience and please try again soon.
<mdke> who has a copy of dapper to hand?
<HiddenWolf> mdke: iso?
<mdke> installed
* ogra has only edubuntu around
<HiddenWolf> I do
<trappist> I just upgraded from breezy, whatcha need?
<LadyNikon> HiddenWolf: i was first :P
<mdke> ok, in a gtk app, hold ctrl and shift and type 2002
<mdke> e.g. gedit
<mdke> what does it produce?
<ogra> 2002 
<ogra> (with a little frame )
<mdke> yeah :/
<mdke> the font is missing that character
<trappist> does anyone else's mplayer segfault on a recently-upgraded dapper?
<mdke> ogra, in yelp, open an xml document, see if you get the missing character all over the index
<ogra> yup
<LaserJock> mdke: oh, that is what it is? I was wondering what the funny thing was.
<ogra> i'd say file a bug ... 
<mdke> sucks
<ogra> but you'll have to wait for launchpad to come up again
<mdke> ogra, there is one, i just wanted to make sure it's reproducable by everyone
<ogra> it is
* ogra wishes he had such easy bugs
<mdke> ok thanks
<LaserJock> mdke: what is it supposed to look like?
<mdke> LaserJock, it's a half white space
<LaserJock> interesting
<crimsun> HiddenWolf: pong
<HiddenWolf> crimsun: benc asked me to ask alsa-upstream about a bug. I thought I'd start with you. I have no sound on my bttv-tvcard, mixer settings identical to the setup on warty to breezy
<HiddenWolf> crimsun: I get the tearing static-sound only
<crimsun> HiddenWolf: on dist-upgrade or clean install?
<HiddenWolf> crimsun: dist-upgrade
<crimsun> HiddenWolf: unload all the ALSA modules, forcibly remove the state file, and reload the ALSA modules
<HiddenWolf> crimsun: dare I ask for the exact commands? (being as it is nearing midnight and I am clueless)
<crimsun> (any further troubleshooting should be in #ubuntu)
<LadyNikon> yay found a mirror
<ogra> LadyNikon, just use archive.ubuntu.com 
<LadyNikon> ogra: everything that had ubuntu.com in it wasnt working for me
<LadyNikon> so i found other sites
<ogra> try archive.ubuntu.com its redirected since this mornong already
<ogra> *morning
<HiddenWolf> LadyNikon: otherwise, there is se.archive.ubuntu.com
<ogra> HiddenWolf, which is the target of the DNS redirect ;)
#ubuntu-devel 2006-02-17
<thewama> do we have a flight 4 date?
<ogra> nope ... but likely next week some time ...
<thewama> yeah I figured
<thewama> any suggestions on how I can pitch in?
<thewama> I know my code but need some direction
<ogra> try #ubuntu-motu :)
<thewama> alrighty thanks!
<ogra> :)
<thewama> what about getting into gnome or xorg devel?
<thewama> package-work sounds like a good place to start, but how would I get into the core stuff?
<HiddenWolf> thewama: for ubuntu the starting point is motu. there is a gnome-hackers on gimpnet. xorg I don't know.
<ogra> thats rather something you should ask upstream (gnome.org or x.org) we mostly do packaging 
<thewama> makes sense, I'll look into MOTU for now
<MisterN> n8
<hunger> What's up with launchpad?
<HiddenWolf> hunger: hardware migration, all ubuntu sites are down
<dabaR> Does anyone know how to program a valid http cookie?
<jdong> Firefox had another speed regression...
<jdong> from 1.5.dfsg-4ubuntu6 ->  1.5.dfsg+1.5.0.1-1ubuntu3, the rendering speed was cut in half
<Chipzz> jdong: rtf changelog :)
<Chipzz> pango is enabled by default since 1.5.dfsg+1.5.0.1-1
<Chipzz> zless /usr/share/doc/firefox/changelog.Debian.gz
<jdong> so pango slows down Firefox? is that something that's going to be resolved before Dapper's release?
<Amaranth> jdong: it's something that will be solved Q2 2007
<Amaranth> jdong: when gecko 1.9 + firefox 3.0 is out
<crimsun> elmo: please sync easychem and plotdrop from Sid, overriding Ubuntu changes, thanks
<cfk> file:///usr/share/ubuntu-artwork/home/index.html  says "or chat with the community on Freenode IRC Channel: #ubuntu" - i think that should be a link that fires up the default chat cilent - where do I post sugestions like this?
<crimsun> cfk: for that issue, #ubuntu-doc
<LaserJock> cfk: I think the doc team
<LaserJock> crimsun: darn it, you beat me too it ;-)
<cfk> okee dokee - thanks
<sivang> morning all
<nictuku> hi
<crimsun> elmo: also, please sync advi and autoclass from Sid, thanks.
<Coyctecm> morning
<hunger> 
<drfalkor> anyone knows about a mirror I can upload my gimp-2.3.7 .deb file ?
<mdke> anyone else seeing bad signatures on breezy-security?
<mdke> W: GPG error: http://security.ubuntu.com breezy-security Release: The following signatures were invalid: BADSIG 40976EAF437D05B5 Ubuntu Archive Automatic Signing Key <ftpmaster@ubuntu.com>
<mdke> i see it on both my breezy systems
<jsgotangco> yep
<jsgotangco> confirmed
<jsgotangco> i thought they were moving to a new datacenter
<mdke> yes, maybe that was the cause
<jsgotangco> planet used to 404 a few hours ago
<mdke> mpt, any movement on AboutUbuntu? will it be ready for dapper you think?
<sivang> mdke: it probably would, it's a very simple application that I think all the pieces are already there.
<sivang> mdke: (I set with mpt and saw this POC app on his lappie at UBZ)
<mdke> sivang, i'm not sure any progress has been made since UBZ though, I hope so
<mdke> damn, i don't get mounted volumes on my desktop with dapper anymore. is that a conscious decision? it means that I can't unmount anything anymore
<jdong> mdke: you can still use the Computer browser
<\sh> elmo / Znarl: any ETA for accessing u.u.c again?
<Lathiat> the email said iirc?
<\sh> Lathiat: saturday 22 UTC + 6h == overdue :) 
<Lathiat> heh
<Lathiat> right
<ogra> i guess its only a DNS delay, noit all nameservers have catched up the change yet
<mdke> jdong, oh thanks
<mdke> jdong, its still not discoverable enough tho
<mdke> :)
<MisterN> hi
<zakame> hello devs :)
<Coyctecm> anyone have pci-e radeon x600 ?
<Coyctecm> how much you get fps with  glxgears ?
<Mithrandir> Coyctecm: glxgears is not a benchmark.
<Coyctecm> no not, but just thinking I only get ~1400
<Mithrandir> it's not a benchmark, the number is meaningless
<Coyctecm> with nvidia 6600gt agp I get about 3500
<Mithrandir> you can check whether you have accellerated 3d by looking at the output of glxinfo
<Coyctecm> yes, not that
<Coyctecm> doom 3 runs fine with 1280x1024 :)
<Mithrandir> or test something which tests your 3d performance, like doom
<mdke> jdub, whiprush, the tabs on the fridge are appearing at the bottom of the window, rather than on the top bar. can you ping me when it's fixed, I wanna take a screenshot of the fridge for the flash intro
<zakame> is there any work done for NetworkAuthentication?  I notice it is approved, but deferred for Dapper :/
<carl> dapper installer partitioner - tryed to span 2 drives with one LV volume - I had problems getting it setup, and watever I did setup isn't booting - "couldn't find all volumes"
<carl> I'll do the install again, wondering how I can document what the resulting partition config looks like
<carl> once I am done wiht that step, is there a deb-conf like file that has my partitioning choices?
<mdke> jdub, whiprush, interestingly, the tabs work in dapper epiphany, but not dapper firefox *shrugs*
<Kinnison> mako: ping?
<carl> duh - should I even be able to setup / on a LV?
<MisterN> cu
<mdke> ugh, something is spamming -devel mailing list
<xhaker> it's getting tagged atleast
<sistpoty> elmo: please sync gnustep-make (1.11.2-2) from unstable, no ubuntu specific version present.
<mantas_> doko, are you online ?
<ogra> hrm ... upload.ubuntu.com still refuses connections 
<pietrus> hi, is it ok to ask that a package be synched from debian if it is not in ubuntu yet?
<sistpoty> pietrus: until FeatureFreeze it is ok.. what package are you talking about?
<pietrus> tomcat5
<sistpoty> pietrus: tomcat5 is in universe
<pietrus> sorry
<pietrus> i was using packages.ubuntu.com and it defaults to breezy
<raphink> pietrus: if you're on breezy, you have to know that breezy is frozen
<ogra> elmo, Znarl, thanks (to whoever switched ftp back on)
<sistpoty> thanks from me as well ;)
<xhaker> hehe.. ogra is fast..ubuntu-meta there already
<ogra> i produced my 3rd coaster iso due to the inputattach shuffling already :( ... this upload should finally solve it 
<mako> Kinnison: hey there
<MisterN> re
<carl> dapper setup, another attempt at LV, install lilo step fail.  what files can I post that will document what happened?
<HiddenWolf> why does lvm use lilo at all?
<HiddenWolf> I've been using grub and lvm since warty
<CarlFK> good q
<CarlFK> can / be on a LV?
<ogra> sure
<HiddenWolf> since breezy afaik
<CarlFK> this is the first time playing with it - the plan was /boot on sda1, swap on sda2,  / on  sda3 and sdb1 using  LV - after fighting with the partitioner and a few reboots, I finally got it to install, but then it wouldn't boot.  so tried the install again, now it won't even install
<HiddenWolf> I have /dev/sda1 /boot - /dev/mapper / root /swap /home
<ogra> ogra@aleph:~$ mount|grep ^\/
<ogra> /dev/mapper/vg0-lvol0 on / type ext3 (rw,errors=remount-ro)
<ogra> /dev/sda1 on /boot type ext3 (rw)
<ogra> /dev/mapper/vg1-lvol1 on /var type ext3 (rw)
<ogra> works wondeful ...
<HiddenWolf> ogra: is suspend/hibernate supposed to work on a desktop system with swap on lvm?
<ogra> (using grub btw)
<ogra> HiddenWolf, good question ... never tried
<HiddenWolf> since that's the default setup nowadays
<CarlFK> HiddenWolf: I'll let you know if I could get it to boot ;)
<ogra> HiddenWolf, suspend shouldnt be any issue ...
<ogra> since thats to ram anyway
<ogra> i didnt try hibernate with lvm ...
<HiddenWolf> hm, I can't get either to work for me.
<ogra> i doubt thats a lvm issue for suspend
<HiddenWolf> the nvidia driver might be it.
<ogra> oh, indeed
<ogra> nvidia is known to break suspend/hibernate
<HiddenWolf> anything else?
<ogra> its pretty sure the nvidia driver ...
<ogra> try switching to nv ...
<HiddenWolf> Hm. I will in a bit. Watching extreme home makeover now
<CarlFK> what will it take to get scp available in the installer?
<HiddenWolf> Carlk, you should ask kamion
<CarlFK> I think he's sleeping ;)
<ogra> CarlFK, its early sunday afternoon ... i rather guess he's in weekend mode :)
<CarlFK> oh yeah... weekend..
<sivang> ogra: aleph in in hebrew, you know ? :)
<ogra> sivang, yup
<sivang> ogra: so where did you coin its name from? :)
<ogra> its also a wonderful short story by jorge luis borges 
<sivang> ogra: it is? then I gotta read it sometime soon :)
<ogra> yup :)
<sivang> ogra: what is it about?
<ogra> the aleph is a point in space that unites all times and spaces in a single point in this story ... 
<sivang> I was also surprised George Kantor used the tem "aleph ephes" to describe the first order of infinity magnitue :-)
<ogra> i found that matches a central server of my former comapny quite well ... this machine exists since 8 years ...
<sivang> ogra: ah, figures - 
<ogra> and was the center of my world for years
<MisterN> sivang: Georg Cantor is the way wikipedia spells it
<sivang> MisterN: then they are proibably wrong :)
<sivang> sorry,
<sivang> then /me/ is probably wrong
<sivang> ogra: ah, that figures. Aleph is a symbol for beginningness, for genesis, for a common point 
<MisterN> sivang: i bothered to search because in my memory this was a german not english / french mathematician ;)
<ogra> yup
<sivang> MisterN: According to my former math professor, he was hungerian , which is proibably more close to germen then english spelling
<MisterN> sivang: well he was born in st. petersburg so your professor's not entirely wrong and the description "deutscher Mathematiker" is not entirely correct :)
<sivang> MisterN: is this the st. petersburg that's currentyl in russia? or are there two of them?
<MisterN> sivang: probably in russia.
<tseng> Hungarian
<sivang> tseng: ?
<MisterN> tseng: ?
<tseng>  he was hungerian , 
<tseng>           which is proibably more close to germen then english spelling
<MisterN> well in words hungarian is different from anything
<sivang> tseng: ah, thanks :) but weirdly, I am searching google, and there there are a couple of stories that explain he had been living in germeny and was born in russia, any useful pointer to contradict that?
<tseng> sivang: Hungary is right next to germany and they share the language
<tseng> germany isnt that old as an official nation
* tseng compares dates
<MisterN> tseng: WHAT?
<MisterN> hungary does NOT share the language
<ogra> hungary and austria were one nation once ... but they dont share a language
<tseng> MisterN: mmm but austria does?
<tseng> right
<tseng> they split in 1919
<MisterN> germany and france once were a nation. but that's LONG ago
<tseng> after this guy was already dead
<ogra> MisterN, the K&K dynasty isnt *that* long ago
<MisterN> ogra: reread my sentence
<MisterN> charlemagne is long ago
<ogra> yup
<MisterN> or rather: karl der groe *heh*
<ogra> heh
* sivang can't see unicode letters in his irssi forsome reason :-(
<tseng> i dont think that was unicode
<ogra> & might be ...
<ogra>  surely are 
<tseng> mm ogra's are
<MisterN> http://smartin.bol.ucla.edu/caledonia/images/map-europe.gif <- old card
<MisterN> mine are unicde: 
<sivang> ogra: hungerian and germen I thikn have some stuff common, but are mostly different lanugages, right?
<ogra> i think hungarian is nearer to polish, russian or other eastern languages 
<ogra> but the north of hungary might well speak an austrian slang ...
<sivang> ah
<MisterN> hungarian isn't even an indoeuropean language
<MisterN> and it seems it's not like russian but like finnish
<ogra> oh, i'd have thought its slavian based
<sivang> MisterN: the weirdest thing for me in hungerian, is that some of the words sound close to arabic / turkish prnounciation
<sivang> MisterN: (that's what I could spot out when people are talking it)
<sivang> other then that, I don't understand anything although I've heared it a lot as a child :)
<MisterN> sivang: how comes?
<sivang> MisterN: my late grandmother used to speak hungerian.
<sivang> ogra: do you know your way around threads in python using thread.start_new_thread and locks ?
<ogra> nope
<ogra> i never did thread programming in python
<sivang> ah okay. I have strage prerformance penalty compared to regular non threaded code that does the same on the threaded version, was hoping for an expert advice :)
<ogra> sorry, no threading expert :)
<sivang> ogra: okay, I need mvo to come online and talk to him probably 
<CarlFK> sivang: not that I know squat about anything, but a friend has been looking at the Twisted framework, which sounds like it does threading - maybe?
<sivang> CarlFK: I'd have to first look at it to know, but I thought it had something to do with web applications no?
<CarlFK> apparently you don't understand the depth of my "don't know squat" ;)
<CarlFK> it came up when someone else was looking to "communicate with other processes via TCP/IP" and Twisted came up
<khermans> https://launchpad.net/distros/ubuntu/+bug/31242
<Ubugtu> malone bug 31242 in Ubuntu "network-admin "double-configure" problem when choosing a preset location and then hitting OK" [Normal,Unconfirmed]  
<khermans> why can't i properly choose a package name in bugzilla?  malone has bugs?
<khermans> since i could not, i only filed in the general "UBUNTU" package bug
<CarlFK> where did /var/log/debian-installer/ go?
<CarlFK> how can I dump the VT1 screen to a file?
<CarlFK> from the setup's VT2
<lemsto> is initNG included in dapper?
<lemsto> or for dapper++?
<siretart> hi!
<siretart> lemsto: not dapper. it might be considered for dapper+1
<ogra> there is a spec for such an implementation on launchpad ...
<ogra> but it doesnt target initng afaik
<ogra> search for streamlined-boot
<CarlFK> in the setup, cat /dev/vcs4 gives me what is on VT4, but /dev/vcs1 doesn't give me whats on VT1 - any clue how I get what is on VT1?
<lemsto> siretart, ok, thx
<lemsto> ogra, streamlined-boot is a similar project as initNG?
<lemsto> s/as/to :D
<ogra> initng is only an attempt to do stuff automated a human will do better ...
<ogra> so the idea is to do the same, but without initng as i understood Keybuk who is responsible for the spec
<ogra> if we choose something automated, its more likely to be adopted from solaris afaik
<ogra> but dont quote me on that, i had only a short talk with Keabuk about it
<ogra> *Keybuk
<lemsto> will it be possible to launch simultenaously 2 services with streamlined-boot?
<ogra> yup
<lemsto> k
<ogra> more than two even ...
<lemsto> hehe
<lemsto> thank you! now ill try to find some info...
<ogra> :)
<lemsto> (and its planed for dapper??)
<sivang> ogra: aren't we already running gdm login while other services are starting?
<ogra> sivang, yup
<ogra> but there is still a lot room for optimization
<sivang> indeed.
<HiddenWolf> ogra: for dapper still?
<ogra> HiddenWolf, ls /etc/rc2.d/
<ogra> gdm starts at 13 .... very early
<HiddenWolf> ogra: noted, but you said "a lot of room for improvement" 
<HiddenWolf> ogra: so I'm wondering "will dapper get faster yet"
<ogra> not for dapper according to the devlopment status streamlined-boot is deferred
<HiddenWolf> Hm, probably a wise choice. :)
<ogra> see the weekly update JaneW sends to the list...
<HiddenWolf> yeah, forgot to read that one this week.
* HiddenWolf taps his fingers impatiently
<HiddenWolf> mjg, you promised
* HiddenWolf twiddles thumbs
<Treenaks> HiddenWolf: ???
<HiddenWolf> Treenaks: he sent an email to -devel earlier that he was uploading xgl packages
<ogra> bah
<HiddenWolf> And I'm out of weed, so I need crack. :P
<ogra> HiddenWolf, arent you in .nl ?
<HiddenWolf> ogra: yeah. :)
<ogra> there should be some open coffes shop ... just go out and find it :P
<Treenaks> HiddenWolf: call the local crack dealer ;)
<HiddenWolf> ogra: it's sucky weather, and a 10 minute walk. :)
<ogra> lol
<HiddenWolf> Treenaks: that'd be my roomie, but he's out for the weekend.
<Treenaks> HiddenWolf: 2 words: supply management
<HiddenWolf> Treenaks: please, that's one of my subjects this term. :)
<HiddenWolf> I'll stick to beer.
<HiddenWolf> tonight, at least
<siretart> how do I check which conffile from a package got changed?
<nictuku> hmm I could not search in packages.ubuntu.com, is there a python ssl implementation package in main?
<thierry> nictuku : for wich distribution, and why can't you search on packages.ubuntu.com
<thierry> ?
<nictuku> i could not search 'python ssl' in the packages description
<nictuku> Error: keyword not valid or missing
<nictuku> only single words
<nictuku> thierry, dapper prefereably
<nictuku> my project: https://opensvn.csie.org/traccgi/nwu/trac.cgi/wiki
<nictuku> i forgot that it would be better not to depend on universe packages
<thierry> nictuku : don't know... sorry
<nictuku> and m2crypto is on universe in dapper too =/
<nictuku> thank you
<nictuku> found. python2.4-pyopenssl
<r0bby> I love how people can read
<Coyctecm> damn one finnish irc channel... big flame war that ubuntu doesn't do nothing "own" just a ugly fork of debian...
<Coyctecm> stupid
<Spastjeh> :)
<Coyctecm> I think ubuntu makes debian usable ;)
<Coyctecm> damn this make me nervous :D
<Coyctecm> just curious where are you from?
<Coyctecm> finland
<lemsto> france
<CarlFK> if I am having trouble installing on LV, is this the place to report it: https://launchpad.net/products/partconf ?
<jk-> Riddell: ping ?
<Riddell> jk-: hi
<jk-> Riddell: hiya. just had someone report a dep problem with the kopete meanwhile package.
<jk-> apparently it's depending on meanwhile 0.4.x ?
<jk-> (i don't have a dapper install handy, sorry :( )
<Riddell> libmeanwhile1 (>= 1.0.0)
<jk-> oh, cool.
<jk-> maybe his repos aren't set up correctly.
<jk-> cheers! :)
<HiddenWolf> mjg59: that mail you sent to -devel about uploading xgl packages, is that still going to happen?
<HiddenWolf> mjg59: lots of people begging, moaning and willing to get it from anywhere (and mess up their systems)...
<Riddell> jk-: yep, installs here fine in dapper
<jk-> Riddell: awesome :)
<MisterN> n8
<siretart> wow. seb128 is rocking malone..
<lucas> siretart: where ?
<mjg59> HiddenWolf: Soon
<siretart> lucas: I'm watching the mailinglist for bugs in main
<HiddenWolf> mjg59: how will you solve the patches to mesa and such?
<HiddenWolf> just wondering about the ubuntu-situation, after spending a time watching a gentoo-buff trying to get it to work
<HiddenWolf> And telling a half-dozen people to wait a bit before compiling today. :P
<mjg59> HiddenWolf: We already have the Mesa patches in slightly older form
<HiddenWolf> mjg59: Anyway, very cool that you are taking time to sort it out. I won't bug you further.
<ogra> CarlFK, rather take it here ...
<CarlFK> so.. how can I grab a screen shot of an installer error message?
<ogra> there is already a screencapture from tty1 recorded in the installer log
<CarlFK> no way...
<ogra> sure
<CarlFK> which log ?
<ogra> i sadly cant remember the right name .. but its in /var/log/installer
<CarlFK> leme lookie 
<CarlFK> thre is no var/log/installer 
<CarlFK> nor var/log/debian-installer (which was there in breezy)
<ogra> CarlFK, wait for Kamion, he'll be able to tell you tomorrow ... but in any case there is a complete capture of tty1 that you can replay ... looks quite funny
<ogra> (unless it was dropped recently)
<CarlFK> replay?  thats awesome 
<ogra> (which i doubt)
<CarlFK> I would hope not
#ubuntu-devel 2006-02-18
<CarlFK> ducky - different errors trying to do RAID1 on the same box
<CarlFK> box is haunted 
<CarlFK> the tar that the installer has doesn't create?!
<zul> heylo
<zul> heylo
<ogra> helyo ?
<zul> hmm?
<ogra> :)
<zul> hey ogra how is it going?
<ogra> very good ... ltsp is getting in shape for dapper+1, edubuntu is going forward ... all fine ..
<ogra> err s/dapper+1/dapper/
<ogra> my mind is already in the future :)
<zul> cool..
<ogra> how is the grub hacking going ? 
<zul> its coming..
<ogra> great :)
<zul> i have a couple of ideas for dapper+1, but now just trying to catch up
<ogra> i recently had a meeting with people who wanted something like a mixed ltsp/windows dual netboot environment ... would be funnyly crackful to make grub netboot aware :)
<ogra> so you have a grub menu to select what to netboot ...
<zul> grub has netboot..:)
<ogra> hehe
<ogra> still, they wanted to use something like partimage to store the windows image from only one PC and provide it for all machines in the network ... would get them into heavy license problems ...
<zul> icky...windows :)
<ogra> heh
<zul> http://cvs.savannah.gnu.org/viewcvs/grub/netboot/?root=grub
<ogra> oh, wow ...
<ogra> i'll take a deeper look for dapper+1 ;)
<wasabi> tmpfs for /var/run and /var/lock now?
<wasabi> What drove that out?
<crimsun> wasabi: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2006-January/000048.html
<wasabi> Ooh. Networking started by udev now?
<wasabi> That is an interesting one indeed.
<ogra> everything hardware related started by udev now :)
<wasabi> Does that drive out ifupdown?
<crimsun> no, ifupdown is still used
<wasabi> So, if interfaces defines a configuraiton for ethN, and ifrename gives it a specific name, hotplug will invoke ifupdown?
<crimsun> hotplug is gone
<ogra> no hotplug
<wasabi> Yes yes, I know.
<wasabi> Wasn't using "hotplug" as a product name.
<wasabi> And auto ethN isn't required in interfaces anymore then?
<crimsun> it is.
<crimsun> udev>ifupdown
<wasabi> ?
<wasabi> Yes but a manual up down command still needs to be available.
<crimsun> udev calls ifupdown upon seeing 'auto' in /etc/network/interfaces when the module is loaded
<wasabi> Ahh. Okay.
<wasabi> That's perfect then.
<wasabi> So ifupdown still keeps the neccassary state info.
<wasabi> exciting exciting. ;)
<wasabi> Now if only network manager cooperated with all that.
<mxpxpod> is anyone using the bogofilter plugin for evolution? I'm trying, but it doesn't seem to detect any spam
<netdur> can't ubuntu installer ask all questions needed in early stage?
<netdur> I mean, I'm installing cf3 right now, during "select and install software" progress a dialog pop up asking for screen resolution
<netdur> I don't know how long the progress stopped because of that, but I guess... ubuntu installer should ask all questions early to avoid us wasting time
<CarlFK> netdur: normaly it figures out screen res for you
<CarlFK> netdur: but if you are in a hurry - https://wiki.ubuntu.com/Installation/LocalNet "Hands Off Install"
<CarlFK> symantic, Add repo, any options (default is fine), hit OK - button blinks, but dialog doesn't close - regardless of how I hit, press, click, type
<zakame> Hi devs :D
<infinity> I've decided that building thunderbird is my least favourite thing ever.
<CarlFK> sudo apt-get install linux-686-smp...  ends with Setting up linux-686-smp (2.6.15.14).  Shouldn't the grub menu and kernel name have SMP in it? (2 x P3 box)
<infinity> CarlFK: linux-686-smp is just a dummy package to transition to linux-686, since all our x86 kernels now support SMP/UP autodetection.
<CarlFK> ah - that explains it
<CarlFK> thanks
<jmg> are there any .debs for fedora directory server?
<zakame> Mithrandir: ping
<dholbach> good morning
<CarlFK> um, should a box going into hiberenate say "The system is going down for system halt NOW!" ?
<CarlFK> which may explain why when I try to wake it up it doesn't resume where it left off
<HiddenWolf> good morning all
<poningru> sorry to bug people here, but who is incharge of planet ubuntu? the feed is broken
<jsgotangco> poningru, jdub 
<zakame> jdub is, but I think you should mail him
<poningru> ok
<lbm> wuh, waiting for xgl to hit the archives
<pupy> hello
<pupy> I've compiled udev, sysfstools and hotplug within a custom linux I've built, my question is whether is there anyone who could point me on how to get this to work, either pointing me to any of the ubuntu related sources, or to any good doc or tutorial on how to get automatic device detection working
<Lathiat> Is anyone else seeing this *****[netclusive]  SPAM-ERKENNUNG ? on ubuntu-devel
<zakame> yeah
<floam> Lathiat: it's on the archive also
<jsgotangco> WTF is that spam filter doing
<Lathiat> some incoming smtp filtering on the new dc link? :)
<Lathiat> 220 esperanza.ubuntu.com ESMTP Exim 4.52 Mon, 13 Feb 2006 07:38:53 +0000
<Lathiat> weird
<Seveas> jdub, poke - have a look at bug 14630 :)
<Ubugtu> malone bug 14630 in ubuntu-artwork "Gdm theme Human with face list" [Wishlist,Unconfirmed]  http://launchpad.net/bugs/14630
<Mithrandir> zakame: yes?
<jsgotangco> ohh face browser
<zakame> Mithrandir: I'd like to know what's up with NetworkAuthentication, I see its approved-but-deferred in Dapper...
<Seveas> jsgotangco, yeah, looks quite cool :)
<Mithrandir> zakame: I ended up not having time to get it implemented for dapper.
<zakame> ah
<zakame> I'm doing a bit more research, but I think I can help implement this
<pupy> am, you're all very kind guys..
<Mithrandir> zakame: if you'd like to, that'd be excellent.  It might be a bit on the late side for dapper, though. :-/
<zakame> Mithrandir: I'll see what I can do then :-)
<lifeless> is there any way that gnome-screensaver could break resume-from-suspend ?
<Treenaks> --> mjg59   :)
<ogra> lifeless, thats rather gnome-power-manager that concurs with a leftover from acpi-scripts ...
<ogra> how does it break ? 
<sivang> howdy all
<lifeless> ogra: locks up hard
<lifeless> black screen, no reaction to fn-buttons, ctrl-alt-F1 etc, power button.
* Treenaks has a locking-on-resume laptop as well
<lifeless> have to hold power for 30 seconds to kill it.
<ogra> thats unlikely to be gnome-screensaver or gnome-powermanager
<ogra> rather the backend ...
<ogra> g-p-m is dumb and only calls pmi in the background ... g-s-s has nothing to do with suspend/resume ... if it works usually for you, it shouldnt be the prob
* Kinnison returns
<Kinnison> Kamion: Is there some channel I need to be on, other than here?
<ogra> Kinnison, they will come over time ... :)
<ogra> depending on which packages you work 
<fabbione> Kinnison: ubuntu-x and ubuntu-kernel
<seb128> should xvfb Depends on xauth?
<ogra> if you want to help in support, #ubuntu as well
<fabbione> Kinnison: of course that means you will also help maintaing both :)
* Kinnison grins fabbione 
* Kinnison is still looking at bug lists
<ogra> Kinnison, oh, #ubuntu-meeting might be helpful :)
<ogra> Kinnison, so you are officially a new colleague now ? 
<Kinnison> ogra: yep, although I'm still waiting on my ubuntu membership
<ogra> yay 
<ogra> welcome then :)
<Kinnison> Thanks
<infinity> Kinnison: What package sets interest you?
<infinity> Kinnison: We have no end of stuff we can offload on you. ;)
<Kinnison> infinity: Currently power-management and laptop stuff
<Kinnison> infinity: I'm most interested right now in getting my suspend button to sodding well suspend my laptop
<infinity> Kinnison: How often does soyuz do cron.daily-like tasks?
<Kinnison> infinity: once per hour, starting on the hour
<infinity> Kinnison: I find it a bit disconcerting that my uploads seem to take hours to end up in build queues...
<dholbach> same here
<dholbach> the buildds all seem IDLE for a long time
<dholbach> I mean... I like a rest too, but... :-)
<Kinnison> Currently we only build from the published package set
<ogra> dholbach, RT #2865
<Kinnison> which means after a cron.daily cycle
<infinity> for instance, mozilla-thunderbird, uploaded 2 hours ago, still not in build queues.
<ogra> feel free to follow up (if thats possible)
<Kinnison> infinity: 2hrs and not built is odd
<ogra> Kinnison, i'm waiting since 3pm yesterday ...
<ogra> thats more than 2h :)
<pitti> hello
<dholbach> hey pitti
<infinity> Kinnison: Actually, if the recent build logs are to be believed (and if they are, in fact, in reverse chronological order), nothing has built for 1.5 days..
<Kinnison> okay that's very odd
<Kinnison> and noone rang me
* sivang hugs pitti and Kinnison 
<infinity> Kinnison: Well, since I don't get mailed build logs, dealing with the web UI to see what's up is taking some getting used to.
<seb128> an upload was broken for most of the day yesterday
<ogra> Kinnison, i thought you handed it over, so RT was my choice ...
<dholbach> mailed buildlogs for ftbfs would be great
<infinity> ogra: RT won't help much, you need to file bugs on soyuz.
<ogra> ah
<ogra> k
<pitti> hey infinity, sivang, dholbach 
<pitti> hi Kinnison 
* pitti hugs ogra, too
* ogra hugs pitti
<pitti> hey carlos_ 
<carlos_> pitti: hi
<Kinnison> ogra: which RT request was it?
<ogra> RT #2865
<pitti> elmo: please sync noweb 2.10c-3.2 (stable-security) and elog (new universe upstream, but tons of security fixes)
* Kinnison goes to acquire coffee during workrave break
<Kamion> CarlFK: to get scp in the installer, 'anna-install openssh-client-udeb'
<Kamion> CarlFK: /var/log/debian-installer moved to /var/log/installer, but won't be available until after the first reboot
<Kamion> CarlFK: there is no longer a typescript of tty1 activity in /var/log/base-config.log, which is what ogra was referring to (although it was only ever a typescript of the second stage, not the first), because we no longer run base-config
<Kamion> CarlFK: I don't know of a convenient way to get a screenshot of tty1 in the first stage other than a virtualisation environment of some kind or an actual camera
<Kamion> Kinnison: sounds like just this channel will be fine for now
<Kinnison> Kamion: cool
<Kamion> and welcome aboard
<Mithrandir> Kamion: if you have the fb running, just catting /dev/fb0 to a file might work.
<Kinnison> Kamion: I take it no word from mako or sabdfl about my membership?
<Kamion> Kinnison: I'll mail them now with a log of the meeting
<Kinnison> Kamion: thanks
<Kinnison> unless i'm really lucky, this fix to hal will take a while anyway
<Treenaks> Mithrandir: /dev/vcs* if fb isn't running ?
<Mithrandir> Treenaks: I'm not sure if you can grab what's on a tty if it's not a fb.
<Treenaks> Mithrandir: Virtual consoles: yes; ttys: I don
<Treenaks> uh
<Treenaks> other ttys: no idea
<Mithrandir> well, VCs are what's interesting here.  I doubt ttyS's save any state at all
<Treenaks> Mithrandir: cat /dev/vcs1
<Mithrandir> indeed
<Kamion> Kinnison: (mailed)
* Kinnison nods Kamion 
<slomo> hm, i get no mails from the ubuntu lists anymore :/ "postfix/smtpd[13260] : timeout after DATA from esperanza.ubuntu.com[82.211.81.173] "
<ogra> slomo, i get them ...
<ogra> (more than i like :) )
<slomo> ogra: hmm, please send a testmail to me ;) maybe something is broken... but my own mails arrive
<ogra> a PM ?
<slomo> ogra: no, email... to slomo@ubuntu.com or mail@slomosnail.de
<ogra> sent 
<ogra> yes, i wanted to know if a personal mail would suffice :) sent anyway 
* ogra watches dholbach getting praise on the desktop ML
<ogra> well deserved :)
<dholbach> ogra: thanks
<whiprush> is that the bogofilter thing?
<ogra> yup
<ogra> whiprush, hey !
<whiprush> I was wondering who did that. Very cool, works great here.
<whiprush> ogra: hey, I got some good edubuntu news.
<ogra> whiprush, jammcq pinged me yesterday, youre a heavy edubuntu promoter i heard :)
<ogra> hehe :)
<whiprush> Our Loco is helping out a local charity prebundling ubuntu.
<whiprush> heh
<ogra> thats so cool :)
<whiprush> We already have 50 that are vouched for.
<whiprush> should be fun.
<ogra> wow
<ogra> i didnt even know you and jammcq know each other :)
<whiprush> yeah we start building them on saturday and taking pics of kids installing it and stuff, should be awesome.
<whiprush> heh, he's my lug president. :p
<ogra> lol
<slomo> ogra: hm, i didn't get the mail yet... i got two connects from fiordland.ubuntu.com but nothing happened yet... weird
<ogra> the world is so small :=)
<ogra> slomo, it didnt come back either
<ogra> i'll look im my servers log, wait a sec, probably it shows something
<whiprush> ogra: I'm tasked with customizing the CD with some content, I'll swing by later, (going to work now)
<ogra> Feb 13 11:26:53 aleph postfix/smtp[9949] : 7962B220CA5: to=<mail@slomosnail.de>, relay=mail.slomosnail.de[83.151.31.59] , delay=300, status=deferred (host mail.slomosnail.de[83.151.31.59]  said: 421 mail.slomosnail.de Error: timeout exceeded (in reply to end of DATA command))
<ogra> slomo, ^^^
<ogra> whiprush, thanks for everything :)
<slomo> ogra: nice... i didn't change anything in my setup since yesterday and now it stops working ;) hmm...
<ogra> oh, above...
<ogra> Feb 13 11:21:53 aleph postfix/smtp[9949] : certificate verification failed for mail.slomosnail.de: num=21:unable to verify the first certificate
<ogra> did your tls cert expire ? 
<slomo> ogra: ah... thanks... that's most probably the problem :)
<slomo> yes... *sigh* should work now again
<ogra> want another testmail ?
<slomo> sure
<ogra> sent
<dholbach> ogra: there's a new dia release
<ogra> hmm, worth it ? 
<dholbach> ogra: dia 0.95-pre1 - dunno if you want that in edubuntu
<ogra> pre1 sounds scary 
<dholbach> ogra: it can only be better ;)))
* dholbach shrugs
<ogra> i'll look at it
<dholbach> cool
<Kamion> Mithrandir: since I think you're already part-way there, could you start looking at keymap configuration in espresso? https://wiki.ubuntu.com/UbuntuExpress/GnomeUserInterface and https://wiki.ubuntu.com/UbuntuExpress/BaseSystemConfiguration are relevant
<Kamion> Mithrandir: you'll want to bzr pull, I've been doing the debconffilter refactoring work
<Mithrandir> Kamion: will do.
<Kamion> Mithrandir: thanks
<Kamion> I'm going to try to make the gparted integration slightly less painfully bad today, I think
<koke> mvo, I have some suggestions/bugs about the update-manager dist-upgrader, where did you sent the mail originally?
<mvo> koke: I send it to ubuntu-devel, feel free to mail me personally about this (especially upgrade reports)
* mvo goes for lunch now
<HiddenWolf> mjg59: ping
<mjg59> Hi
<HiddenWolf> mjg59: I was wondering why your xgl upload is in the -kserver package. Can see that causing lots of questions.
<mjg59> It's not
<mjg59> I haven't uploaded xgl yet
<HiddenWolf> mjg59: hm, see, lots of questions already. :)
<mjg59> I've just removed it from the kdrive one
* HiddenWolf hides. :)
<ogra> seb128, what about http://bugzilla.gnome.org/show_bug.cgi?id=94049 ? can we have it ? 
<hunger> mjg59: You did not? I installed it yesterday:-)
<seb128> ogra: no
<mjg59> hunger: That's old xgl
* hunger wonders which version he grabbed...
<ogra> seb128, why ? 
<mjg59> Like, really old
<ogra> seb128, its really giving edubuntu users a hard time ...
<hunger> That explains why it does not work too well then.
<HiddenWolf> Try utterly ancient. :)
<seb128> ogra: because I don't want to divert from upstream for that, especially for a patch I don't understand
* sivang is first to try XGL official dapper debs if/when they're out :)
<ogra> seb128, it forces users of internet cafes to switch to xfce or KDE, thats quite a big amount ...
<seb128> ogra: I need to have a look on it, it seems to not be too long should be quite easy
<HiddenWolf> sivang: you'll have to beat a horde of anxious users to it. ;)
<hunger> sivang: Not if I can beat you to it. I'd really like to see what all the fuss is about.
<mjg59> sivang: This evening, with luck - compiz has broken itself, and I want that in first so I can test the Xgl package
<seb128> ogra: did you try the patch?
<ogra> seb128, i'd love you till the end of my life if we could get it 
<ogra> will do and repoirt back 
<seb128> is that supposed to convince me? :p
<ogra> lol
<ogra> as long as it doesnt scare you 
<sivang> mjg59: yay, that means you're getting clsoe right?
* seb128 hides behind dholbach
<mjg59> sivang: Yes. Xgl builds and works fine, but needs integration love
<seb128> ogra: it does in fact :p
<ogra> oh, sorry :)
<seb128> let me know if it fixes your issue
<dholbach> seb128: shall I bring ogra back into his cage? :-)
<mjg59> It also needs me to figure out why it won't run standalone
<seb128> if it does we will ship with next package update
* ogra makes menkeyish noises
<seb128> dholbach: yes please :)
* dholbach hugs ogra
<ogra> *monkeyish
<dholbach> haha
<mjg59> Hm.
<mjg59> The build is bitching about undefined symbols, but in plugins that are designed to be opened in the main program
<mjg59> Which is where those symbols are define
<mjg59> d
<mjg59> There's something obviously wrong here, I think
<lifeless> its a very unixy trick
<mjg59> Oh, I see why Xgl bitches in standalone mode
<doko> seb128: weill you upgrade to the new gtk release?
<lifeless> fucks up and dies on windows
<mjg59> lifeless: I'd expect it to work fine here, but the linker seems to have other ideas
<seb128> doko: sure, it's on my disk since yesterday, I just run GTK for a day or so usually before uploading, why?
<lifeless> mjg59: using libtool ?
<mjg59> lifeless: Yeah
<lifeless> make sure it has the 'be as broken as windows' feature turned off
<Mithrandir> maswan: care to kick ravel? :-)
<doko> seb128: the wxpython maintainer did ask me
<seb128> Debian question or Ubuntu one?
<Kamion> pitti: something still seems to be popping up a window for /target when espresso mounts it
<Kamion> /dev/sda1 on /target type ext3 (rw)
<Treenaks> mjg59: (do you have time for that wacom-tools stuff today?)
<pitti> Kamion: hmm, trying to reproduce here
<mjg59> Treenaks: This evening
<pitti> Kamion: good timing, btw, I uploaded a new g-v-m 10 seconds ago :)
<Treenaks> mjg59: cool, thx
<Kamion> pitti: heh. live CD image from a few days ago
<mjg59> lifeless: Works if I use automake-1.7 rather than 1.9
<mjg59> Looks like the linker flags aren't being passed through
<Kinnison> Hmm, looks like my laptop isn't coming out of suspend again
* Kinnison bahs
<Treenaks> Kinnison: lots of people seem to have that
* Treenaks has that too
<Kinnison> Treenaks: yeah, annoying when I'm trying to fix a bug in the suspend button
<mjg59> Kinnison: Suspend button bug?
<Kinnison> mjg59: toshiba, hal, blah
<mjg59> Kinnison: (Note that I've changed the handling of suspend buttons a lot)
<Kinnison> mjg59: the outward sign is "pressing fn+f3 does not suspend the laptop"
<Kinnison> hmm, I can ping it, but it's not come back further than that
<mjg59> Kinnison: It should just be generating a keycode now, and latest hal should pick up on that with hald-keyboard-addon
<mjg59> Kinnison: You'll need g-p-m
* Kinnison has g-p-m
<mjg59> Latest?
* Kinnison will tell you when his laptop has booted again
<mjg59> Pressing the sleep button ought to be generating a dbus system message
* Kinnison nods
<mjg59> But that needs latest hal 
<Kinnison> what info would help?
<mjg59> Package versions, whether hald-addon-keyboard is running, whether you get a message on the system bus when you hit the key
<mjg59> And whether sudo acpi_fakekey 142 does the same thing
<mjg59> Oh, acpi_fakekey may be broken - someone pointed that out to me
<Kinnison> right, a dist-upgrade shows nothing halish
<Kinnison> hald-addon-keyboard is running
<mjg59> If you run xev and do sleep 2; sudo acpi_fakekey 142 then point at the xev window, does it generate an event?
<pitti> Kamion: hmm, g-v-m doesn't do anything here if I mount something on /target
<pitti> Kamion: which g-v-m version did you use?
<pitti> Kamion: that was fixed in 1.5.10-0ubuntu4
<Kinnison> mjg59: no, and sudo exits with status 2
<mjg59> Kinnison: Ok, acpi-fakekey is broken
<Kinnison> would it help if I investigated that?
<mjg59> Nah, known bug
<mjg59> With known fix
<mjg59> Just need to upload
<Kinnison> Okay
<mjg59> It seems to work for me entirely by accident, so I didn't catch it
<Kinnison> Right
<Kinnison> If you have a fix, I'll move on to something else for now
<Kinnison> like looking at why my sodding machine doesn't come back properly
<doko> seb128: s/or/and/
<seb128> doko: it has been uploaded yesterday to Debian and will be today to Ubuntu
<Kamion> pitti: 1.5.12-0ubuntu1
<pitti> Kamion: hm, do you want to help me with debugging?
<mjg59> Kinnison: https://launchpad.net/malone/bugs/31302
<Ubugtu> malone bug 31302 in acpi-support "[PATCH]  Fix typo in acpi_fakekey.c" [Normal,Unconfirmed]  
<freeflying> anyone would have comment on this https://lists.ubuntu.com/archives/ubuntu-devel/2006-February/015252.html
<Kamion> pitti: sure, except that I just rebooted that live CD so it'll take a moment to set up again
<pitti> Kamion: no problem, see /msg
<mjg59> Oh argh now the build has broken again
<mjg59> Hang on
<mjg59> Nngh.
<mjg59> Why has dh_make put CFLAGS stuff in that breaks the build?
<Kinnison> mjg59: Who is the best person to ask about gnome-power-manager?
<mjg59> Kinnison: I'm a good start
<Kinnison> should it be showing options for what to do when I press the suspend button?
<mjg59> Yes
* ogra raises his hand as well (but only for the trivial bits)
<mjg59> Ah. But possibly only if it thinks you have a suspend button (which it ought to)
<Kinnison> Right, well it isn't
<ogra> thats a hal thing then ...
<Kinnison> Okay, so hal needs to be educated about toshiba laptops?
<mjg59> No
<mjg59> g-p-m needs to be told to show the suspend stuff all the time
<mjg59> Since we can't actually tell if you have a suspend key or not
<Kinnison> Right
<mjg59> Go go compiz upload!
<ogra> heh
<Kinnison> mjg59: Okay, so turning off video-post made the laptop come back after suspend
<mjg59> Kinnison: Fun
<mjg59> Kinnison: Now you get to work out why that's unhappy :)
<Kinnison> aye
<Kinnison> mjg59: Wooyay
<mjg59> Xgl will follow later
<CarlFK>  Kamion thanks for the answers 
<mjg59> I probably need to do that from home, it's going to need some testing
<Kinnison> mjg59: heh, but coming back from suspend, g-p-m's icon has vanished
* Kinnison sighs
<ogra> hmm, looks like your dbus crashed or something 
<Kinnison> dbus is fine
<Kinnison> well, networkmanager hasn't died
<ogra> hmm
<mjg59> Kinnison: Is there still a space where the icon should be?
<Kinnison> no
<mjg59> (And in gnome-power-manager still running?)
<mjg59> s/in/is/
<Kinnison> no it isn't
<ogra> does it come back if you start the preferences ? 
<Kinnison> ogra: yes it does
<ogra> hmm ...
<Kinnison> and a suspend/resume cycle just reliably killed it again
<mjg59> Kinnison: Ok. Can you do gnome-power-manager --no-daemon --verbose ?
<ogra> doesnt happen here 
<Kinnison> mjg59: yep, I'll do that right now
<mjg59> See where it's falling over
<mjg59> If that's not enlightening, then do the same with a gdb stuck on it
<Kinnison> at least I can resume reliably again
<mjg59> Can anyone other than elmo do NEW?
<Kinnison> kamion can
<Kinnison> mjg59: okay, this time, it stayed alive, and I got a six-icon logout dialog
<mjg59> Kinnison: ?
<mjg59> Weird
<Treenaks> wasn't the 6-icon dialog abandoned?
* hunger still can not suspend. Suspend request is just ignored.
<mjg59> I wonder if that was it somehow getting a power buttn event
<mjg59> hunger: With what? g-p-m?
<hunger> Maybe that is because I am on kubuntu (no g-p-m)?
<Kinnison> mjg59: I pressed the power button to resume
* Kinnison tries lid close/open
<seb128> Treenaks: no, that's the dialog we will use for dapper
<Treenaks> seb128: uh.. so we'll have _2_ kinds of dialog for logout?
<mjg59> seb128: Does it still show sleep all the time?
<mjg59> If so, can that /please/ be fixed?
<Kinnison> mjg59: nope, lid close/open caused the six icon dialog too
<Treenaks> seb128: the System -> {Logout,Shutdown} ones that logout automagically, AND the butt-ugly 6-button one?
<mjg59> Kinnison: Right, there's often a power button event regardless of how you resume
<mjg59> Anything in /var/log/acpid ?
<seb128> mjg59: give me 40hours day and it'll be fixed
<Kinnison> mjg59: I'm just trying a suspend/resume with g-p-m started from g-p-p
<mjg59> seb128: We can't release with the sleep button there
<seb128> there is a limit on how many bugs I can fix in a week sorry
<mjg59> It's just not reliable enough
<hunger> seb128: My boss used to say: There are 24h in a day and if that is not enough you may work at night as well.
<Kinnison> mjg59: Right, running --no-daemon --verbose it doesn't crash
<mjg59> seb128: But sure, it's not urgent
<Kinnison> mjg59: running autospawned it crashes
<mjg59> Kinnison: What fun
* Kinnison gets gdb out
<ogra> ARGH 
<seb128> Treenaks: no, just the "butt-ugly" one
<seb128> and I'm not making the decisions here
<Treenaks> seb128: I'll never log out again.
<seb128> so complain to Mark :)
<ogra> and i was so careful to get ubuntu-meta in fast enough... now gnome-terminal is broken on my CDs ... *sigh*
<seb128> I'm tired to get all the complains for stuff I don't decide
* ogra gives up on edubuntu flight4 
<Kinnison> mjg59: Oh the irony
<seb128> Treenaks: such comments are just demotivating and make me feel I don't want to feel any bugs you may mention to be honest
<Kinnison> mjg59: "Program exited normally."
<mjg59> Kinnison: Haha
<hunger> Any chance of getting non-g-p-m suspends working again soonish?
<ogra> Kinnison, the buildds dont process in upload order ?
<mjg59> hunger: Once KDE has implemented what it needs to implement, it'll be fine
<Treenaks> seb128: How should I know who decides this? As far as I knew it was gnome upstream that decided this..
<hunger> Not having that hits me hard since shutdown freezes my box.
<infinity> ogra: They never have.
<ogra> grumbl 
<mjg59> infinity: Is X your baby now?
<hunger> mjg59: I'd guess they won't.
<mjg59> I can't remember what the decision was
<seb128> Treenaks: GNOME upstream decided the 2 panels new dialog, Mark asked to do the 6 buttons one
<Kinnison> ogra: also, for added amusement, the UI is currently sorted backwards for pending builds
<mjg59> hunger: Shrug. Riddell knows what needs doing.
<infinity> mjg59: I'm sharing said baby with others (like Fabio)
<seb128> Treenaks: I don't ask you to know who decides but comment like "<Treenaks> seb128: I'll never log out again." are nothing near to be useful
<Kinnison> ogra: but either way, the buildds are all busy with gcc/gcj
<infinity> mjg59: But I seems to have some of it, yes.
<mjg59> infinity: Ok. xgl builds from an xorg cvs branch
<ogra> infinity, i tought i'd have a good chance to have ubuntu-meta fixed before any other package when i did the first upload after the DC shuffling yesterday ...didnt expect anything to queue up ...
<hunger> mjg59: good, then I'll bug Riddell
<seb128> Treenaks: that's like a "I'll switch to <whatever other OS> if you don't fix my bug"
<mjg59> infinity: So in the long run, it'll be built from the xorg source package, but for now it needs to be a cvs checkout
<infinity> ogra: Yes, well... Normally you'd have been okay, but.. :)
<mjg59> infinity: Any objections to me uploading that for now, and generating an xserver-xgl binary deb?
<ogra> Kinnison, my CDs are already broken ... i'll have to wait untill all of the new gnome is there anyway 
<Treenaks> seb128: Do you have a bug number for this that I can comment on?
<infinity> mjg59: Erm, you're aware that the xorg source package contains no actual xorg source... Right?
<mjg59> infinity: Yeah, but you know what I mean
* ogra withes for a time machine to pull the trigger for CD builds in the right second ...
<mjg59> At some point in the future, it ought to be built from the same source that generates xserver-xorg
<Kinnison> mjg59: and of course, with added joy comes stracing it causes it to D state on resume
<seb128> Treenaks: https://launchpad.net/distros/ubuntu/+source/gnome-session/+bug/28798
<mjg59> Kinnison: Hahaha
<Ubugtu> malone bug 28798 in gnome-session "new logout dialog interface issues" [Normal,Unconfirmed]  
<Treenaks> seb128: thanks, I'll read that
<infinity> mjg59: Probably, yes.  And for now, you're going to upload an xserver-xgl source package which is a CVS snap that builds Xgl?
<Kinnison> mjg59: this is utterly sucky
* Kinnison reboots
<seb128> Treenaks: np
<mjg59> infinity: Yeah
<infinity> mjg59: Sounds fine to me.  Doubly fine if it's in universe.
<mjg59> infinity: Then in future we kill that and shift the binary build to the main package
<mjg59> Cool
<ogra> mjg59, better put a big red debconf warning in the package
<mjg59> ogra: ?
<infinity> No debonf abuse required.
<ogra> users tend to ues these packages, even from universe :)
<mjg59> Sure
<infinity> ALL CAPS IN THE DESCRIPTION ARE FUN, THOUGH.
<ogra> *use
<ogra> heh
<mjg59> But if somebody installs a package that has "This is not stable" in the description, they don't need to be told a second time
<infinity> Ed Zachary.
<ogra> mjg59, they will ...
<infinity> A debconf note that says "you don't actually want this package you just downloaded" is irritating.
<mjg59> ogra: I wouldn't be uploading it otherwise
* ogra remembers the 2.6.11 kernel snapshot fabbione had in universe once
<infinity> ogra: Of course people will use it.  And they get to keep both pieces when it breaks.  Such is life.
<ogra> yup, i know 
<StevenK> How about a device that punches the user and says "You really don't want to use <x>!"
<ogra> hehe
<infinity> ogra: We don't support universe.  We've made this clear.  We really don't support packages with BIG SCARY CAPS IN THE DESCRIPTION.
<StevenK> vrms on steroids
<mjg59> "Do you want to install this package you just asked me to install?" Yes. "Really?" Yes. "Really?" Yes.
<StevenK> mjg59: Hah
<Kamion> ogra: I'm going to start going round and shooting debconf notes at some point
<mjg59> "Really?" I'M GOING TO KILL ALL OF YOU
<ogra> infinity, i doubt many users read the description, they didnt for the git kernel snaphot
<Kamion> ogra: it is entirely possible that the note facility will disappear from debconf soon
<StevenK> Kamion: Yay! Go!
<Treenaks> mjg59: make the user type a long sentence into apt, like when you try to remove libc6
<infinity> ogra: They may not.  This isn't my problem.  Honest. :)
<ogra> Kamion, i wasnt serious ... i wouldnt have uploaded xgl 
<mjg59> apt-get install xserver-xgl --yes-i-know-this-is-not-a-good-idea-but-i-hate-life
<ogra> yeah,  better :)
<mjg59> xgl is already in universe
<mjg59> I'm just replacing it with a less buggy version
<infinity> ogra: The target audience that will install xserver-xgl is not the fabled Aunt Tilly, it's self-proclaimed "power users" who can bloody well learn to read.
<ogra> i'm just relying on my experience from the kernel stuff back in hoary ...
<mjg59> The kernel image was an issue because it looked like a newer version of the kernel
* StevenK will probably try xgl when he gets PCI-Ex Nvidia card.
<mjg59> If you had universe in your sources list, it looked like an obvious upgrade
<ogra> yup
<ogra> sure, xgl is somewhat different here ...
<StevenK> mjg59: So this xgl upload will look like a subtle upgrade? :-)
<StevenK> "My version number is different. Really. Why don't you believe me?"
<HiddenWolf> StevenK: the previous -xgl is not used by anyone with half a brain or more, so upgrades are unlikely. :)
<Treenaks> I tried the current Xgl, it crashed the moment a window tried to map
<HiddenWolf> *chuckle* Poor devs. I imagine bugs coming in by the busload.
<HiddenWolf> does launchpad link to xorg bugzilla yet?
<mjg59> hunger: pmi needs to be run as root
<ogra> Treenaks, dont map windows then :P just be happy it runs ;)
<Tm_T> hmm, looks like some packages are broken: gcalctool gnome-games gnome-utils
<Treenaks> ogra: 'observe my l33tness! a black/white X'ed screen!'
<dholbach> Tm_T: broken? how?
<Tm_T> all complaining: subprocess post-installation script returned error exit status 1
<ogra> Tm_T, yes, there is a new gnome upload running ...
<ogra> oh
<HiddenWolf> Treenaks: just like ikke's video?
<dholbach> Tm_T: what else does it say?
<ogra> Treenaks, but dare to move the mouse :)
<Tm_T> dholbach: not my system, but I
<Treenaks> HiddenWolf: ikke?
<Tm_T> 'll keep ooking
<Tm_T> looking
<HiddenWolf> Treenaks: nm
<dholbach> Tm_T: dapper? fully upgraded? any held back packages?
<Tm_T> dholbach: dapper, ubuntu-standard held
<dholbach> Tm_T: what would   apt-get dist-upgrade   be trying to install?
<Tm_T> dholbach: inputattach
<dholbach> hrm
<dholbach> Tm_T: i'm just trying to reproduce
<ogra> ?
<ogra> inputattach is there 
<Tm_T> it installed fine, but those those three packages keep complaining
<ogra> did you dist-upgrade or only upgrade ? 
<hunger> mjg59: I ran pmi as root. No effect at all.
<Tm_T> upgrade, install and dpkg -i
<ogra> hunger, exactl command you did ? 
<mjg59> hunger: Try pmi action suspend force ?
<hunger> ogra: pmi action suspend
<ogra> hmm
<hunger> mjg59: I am still here...
<hunger> mjg59: pmi action suspend force has no effect whatsoever.
<mjg59> Ok. Try tracing through /etc/acpi/sleep.sh to see why it's exiting
<hunger> mjg59: Tracing? How do I do that with a shell script?
<mjg59> Put set -x at the top of it
<HrdwrBoB> bash -x
<Mithrandir> ogra: (or somebody else with a ppc) could you try pulling and building xresprobe from http://people.ubuntu.com/~tfheen/bzr/xresprobe/trunk and see if it works?  It builds fine on davis, but I don't have a ppc so I can't see if I get sensible results or not. :-)
<ogra> Mithrandir, will do
<hunger> mjg59: Calling /etc/acpi/sleep.sh turns of my screen....
<Mithrandir> ogra: thanks.
<hunger> mjg59: WLAN, HD, Bluetooth keep blinking, so it definitly does not shut down.
<Tm_T> dholbach: ok, ping me if you find anything
<mjg59> hunger: Right. Where does it fail?
<dholbach> Tm_T: what about the messages? is there anything else?
<hunger> mjg59: No idea... the screen went dark.
<hunger> mjg59: I'll try again and redirect the output.
<mjg59> hunger: Ok
<Tm_T> dholbach: Nope
<Tm_T> dholbach: nothing else notable I think
<ogra> Mithrandir, dpkg-buildpackage builds a fine binary now ... do you need a pbuilder test as well ? 
<ogra> ddcprobe and xresprobe report the right values
<Mithrandir> ogra: no, I wonder if it works and gives sensible output. :-)
<Mithrandir> ok, coolie.
<ogra> :)
<Mithrandir> thanks.
<ogra> np
<Tm_T> dholbach: I'll pastebin it all
<Tm_T> http://kubuntu.pastebin.com/552513
<hunger> mjg59: Calling /etc/acpi/sleep.sh in trace mode works...
<hunger> 
<hunger> 8
<hunger> mjg59: Damn! Now calling /etc/acpi/sleep.sh works, even without -x:-(
<hunger> mjg59: It has some trouble finding xscreensaver-command, that's it.
<zul> heylo
<zul> Kamion: ping..
<doko_> could somebody enlighten me, why gcj-4.1_4.1ds8-0ubuntu8 was rejected with "Uploads to dapper are not accepted." ?
<pitti> doko_: did you upload to jackass?
<doko_> pitti: yes
<infinity> Then that's your problem.
<pitti> doko_: upload.ubuntu.com
<ogra> Kamion, hmm, fun, after a failed install attempt that stopped on ltsp-client-builder (fairly early) i have grub error 15 now, how can that be ? 
<doko_> argh!
<ogra> hmm, resue mode neither works on amd64 live nor on amd64 install, thats odd
<zul> ogra: erroro 15 maybe it cant find the kernel or something..
<ogra> zul, but i wasnt even beyond the base system install
<Kinnison> mjg59: Grah, --no-daemon doesn't die even without --verbose
<ogra> there is nothing that should touch my grub
<mjg59> Kinnison: Ha
* Kinnison can't find anything obvious in the code
<mjg59> Kinnison: Without --no-daemon, it forks and the parent exits. Is gdb following that sensibly?
<Kinnison> the "exited normally" thing hints towards the dbus library closing
<zul> ogra: hmm..interesting
<Kinnison> mjg59: in that instance, gdb indicated a normal exit
* Kinnison tries it again incase it was a fluke
<mjg59> (Start it outside gdb. gdb -p to the process?)
<Kinnison> yeah
<Kinnison> mjg59: "Program exited normally"
* Kinnison stuffs a breakpoint on exit
<ogra> phew ...
<ogra> fixed...
<ogra> but that shouldnt happen...
<ogra> apart from being technically impossible ...
<Kinnison> impossible just takes a little longer to achieve
<zul> heh...apparently anything is possible
<Kinnison> mjg59: HATE HATE HATE
<mjg59> Kinnison: ?
<Kinnison> mjg59: even with breakpoints on _exit and exit, gdb doesn't catch it
<ogra> zul, how ? there is nothing that touches grub stuff in base install so that "technically" cant happen
<mjg59> Kinnison: Fun
<Kinnison> mjg59: indeed
<zul> ogra: im not sure...but something went wrong
<ogra> obviously :)
<ogra> the odd part was that both amd64 CDs i have here crash in busybox in the rescue mode
<ogra> and i386 cant chroot to restore grub on a amd64 system
<pitti> ogra, Kinnison: do breezy-updates uploads work properly now?
<ogra> pitti, apparently
* pitti needs to fix some breakage from the last langpack update
<pitti> ogra: cool
<ogra> but i dont know if that changed after the DC shuffling ...
<ogra> friday it worked :)
<Kinnison> source uploads work
<Kinnison> builds are not currently done
<Kinnison> https://launchpad.net/products/launchpad-buildd/+bug/31082
<Ubugtu> malone bug 31082 in launchpad-buildd "Current system doesn't treat Pockets properly" [Normal,Confirmed]  
<Diziet> Has there been a recent change to the www.ubuntu.com front page which might involve cpu-consuming javascript ?
<Diziet> I see some JS there but I'm not enough of a web-JS programmer to tell whether it's likely to cause sluggishness.
<ogra> ctrl-u says there is some javascript in there ...
<HiddenWolf> what for?
<Diziet> I ask because of Malone 31141.
<HiddenWolf> that page is as dull as it can be.
<ogra> dunno if it was recently added
<ogra> HiddenWolf, its for the search field ...
<HiddenWolf> ogra: ah, got it.
<janimo> has anything changed wrt NEW binaries handling since switching to LP?
<ogra> janimo, not from your perspective ... only for the prople processing NEW
<ogra> *people
<janimo> ok, thanks. But it is no more transparent on LP than it used to right?At least yet.
<janimo> I also find that lamonts buildLogs were nicer than current LP build stats.Hope things will imporve
<ogra> me too 
<ogra> but at least LP has newest on top :)
<HiddenWolf> Did you guys send suggestions to mark yet? :P
<HiddenWolf> he wrote that interface, I think.
<ogra> HiddenWolf, no, we're all fearing our jobs if we criticize :P
<ogra> (yes there are several bugs open)
<ogra> but it works, there are other things with much higher priority
<lemsto> what are the current bigger bugs?
<desrt> dholbach; are you here?
<Kamion> ogra: that partition stored your grub configuration. Reformatting it erased the grub configuration so it no longer knows how to boot.
<Kamion> zul: yes?
<ogra> Kamion, i didnt reformat hda1 (which holds my grub)
<ogra> my test part is hda4 ...
<Kamion> ogra: I bet a previous installation caused grub to be installed to point to hda4
<ogra> and i'm 100% sure that i checked "do not use" for hda1
<ogra> hmm 
<Kamion> that's what the evidence points to
<ogra> right ... 
<ogra> my test installs indeed install grub on hda4
<ogra> ok, thats explains it ...
<ogra> additionally, amd64 rescue mode breaks in initramfs ...
<Riddell> mjg59: how do HP laptops work with gnome for volume buttons? (trying to answer http://bugs.kde.org/show_bug.cgi?id=121890)
<ogra> on both, live and install CD
<Kamion> ogra: rescue mode no longer really exists on the live CD; I'll kill the boot menu item now
<Kamion> don't waste your time with that one
<Kamion> what exactly breaks with rescue mode on the install CD?
<Seveas> Riddell, on my HP laptop volume keys work OOTB
<Seveas> they have keymaps - not ACPI events
<ogra> Kamion, it get thrown into busybox, didnt see any special errormessages
<ogra> Kamion, tell me where to look, i can easily reproduce
<Riddell> Seveas: gosh, how sensible :)
<mjg59> Riddell: They send a keycode
<Seveas> Riddell, I haven't yet found anything on that laptop that didn't make sense :)
<Seveas> well, there's this stupid SD card thing - but I never use it :)
<mjg59> Riddell: Can't remember what the X keycodes are off-hand, but I can probably find that out for you
<Kamion> ogra: check that it's really an installer initrd: make sure /lib/debian-installer.d/ is there
<Kagou> hi
<pitti> Kinnison: oh, -updates go to security.upload.u.c, too?
<Kinnison> pitti: the intention is for them to go to u.u.c
<Kinnison> pitti: but until that bug is fixed there's little point
<Kinnison> pitti: uploads to s.u.u.c won't get through if they're not -security
<pitti> ok, I see
<pitti> then I'll keep the packages around without uploading them
<ogra> Kamion, give me a second...
<pitti> I accidentially dput'ed one of them to upload.u.c already
<Kinnison> pitti: then the source will go in and the binaries will build when the bug is fixed
<pitti> that sounds good
<pitti> so I can actually upload it already so that I don't accidentially lose the package, and I don't need to keep track of that build bug
<Kinnison> yep
<pitti> rock
<ogra> Kamion, hmm, thats intresting, now it works with the same iso .... must be the media
<Kamion> ogra: sounds to me like you were using the live CD by mistake ...
<tepsipakki> could someone confirm a bug on gnome-screensaver that I'm having.. you should have a line "grabDesktopImages: True" in .xscreensaver, and choose AntSpotlight (or Flipscreen3d etc) as the screensaver. Then try to lock the screen
<ogra> Kamion, i have live and install isos on different machines... very hard to mix up :)
<Kamion> fair enough
<Kamion> anyway, I've disabled the rescue option on live CDs now
<ogra> i always burn one set of all arches and test that ... i rather think the writing or media failed ...
<Alinux> pitti_laptop, hello dear...
<Alinux> I saw your malone message.
<Alinux> fixed ?
<pitti> Alinux: uploaded, but breezy-updates is not built yet
<tseng> BenC: do you have any idea why dell openmanage insists on me having a kernel with regparm?
<BenC> no idea
<tseng> BenC: (i seem to recall you wanted to get it working)
<BenC> what is regparm?
<tseng> it was an experimental kernel option last i looked
<Alinux> pitti, thank you.
<tseng> about a year old, some compiler voodoo
<BenC> oh, where it forces function args into regs instead of on the stack
<tseng> yeah
<BenC> very incompatible change, must be how they compiled their kernel stuff
<tseng> it gives me shivers still
<tseng> i have the source for the driver
<BenC> do they have binary portions of a kernel driver or something?
<tseng> but the build script insists on having regparm
<BenC> are you sure there aren't any binary files being linked into the kernel driver?
<BenC> if there aren't, then just hack the build to ignore it
<tseng> mm there are some .o files
<dholbach> desrt: yes
<BenC> oh, nasty
<tseng> lots of them
<tseng> this thing is generally targetted at RHEL
<BenC> tseng: unless you feel like hacking the source to mark all those function calls to the .o files as regparm type, then there's not much to do
<torkel> tepsipakki: http://bugzilla.gnome.org/show_bug.cgi?id=328404
<Ubugtu> gnome2 bug 328404 in dialog "dialog loses focus" [Critical,Unconfirmed]  
<desrt> arg.  reply then go offline.
<tepsipakki> torkel: yes, that's me =)
<tseng> BenC: yeah i dont really feel like loading up hacked up modules onto my servers today
<torkel> tepsipakki: ah :-)
<tseng> BenC: thanks.
<torkel> tepsipakki: and yes I have seen something similiar
<tepsipakki> torkel: good to know, I'm not going mad then, yet anyway
<dholbach> desrt: yes
<tseng> BenC: if you ever get to it give me a yell, i have a bunch of poweredge ubuntu system
<desrt> dholbach; remember just before breezy release we were having those battery issues
<desrt> dholbach; and i banged together a patch to fix it and it seemed to work for you but you never included it and neither did i because we were both too close to our respective releases?
<desrt> dholbach; what's the deal with that?
<dholbach> desrt: it's in dapper
<desrt> the patch?
<dholbach> desrt: as soon as it opened
<dholbach> yes
<desrt> oh.  awesome
<desrt> i'll upstream it then
<dholbach> :-)
<dholbach> and some people got happy by using it :)
<desrt> i was wondering why everyone stopped complaining :)
<dholbach> hahaha :(
<dholbach> :-)
<dholbach> because you rock! :)
<desrt> pfah
<mjg59> What was this for?
<desrt> mjg59; battstat workaround for buggy acpi
<mjg59> Ah, ok
<MisterN> hi
<pitti> dholbach: so you also sometimes get the 'two eth cards race for the same name' bug?
<pitti> dholbach: is there already a bug filed about that? I just discussed that with Keybuk and debugged this a bit
<dholbach> pitti: Erm... those two boxes only have one card.
<pitti> dholbach: hm, didn't you tell me this morning that you get that, too?
<dholbach> pitti: you didn't say anything about two cards - so I must have misunderstood you
<pitti> ok then :)
<pitti> dholbach: ah, it's bug 31188
<Ubugtu> malone bug 31188 in udev "udev renaming can cause odd network names" [Normal,Unconfirmed]  http://launchpad.net/bugs/31188
<dholbach> ahhh
<ogra> pitti, i have that as well, but with _ethX and __ethX (as i told you thid morning)
<dholbach> I just have 'lo' on those two. ifconfig {_,}eth<X> up tells me, that that card doesn't exist
<ogra> what does "cat /proc/net/dev" say ? 
* dholbach boots
<dholbach> eth0_clashed
<dholbach> nice :)
<ogra> yup
<dholbach> thanks ogra
<ogra> :)
<pitti> dholbach: same bug then
<wftl> Hello everyone. Who is working on the live installer for Dapper?  And how is it going? :-)
<Kamion> status updates are posted regularly to ubuntu-devel-announce@ along with all the other distro projects being done by Canonical employees
* Kamion runs to play chauffeur for a bit
<dholbach> mdke: ok, with doing a ubuntu-docs update now?
<mdke> dholbach, you bet!
* dholbach needs to get his idiomatic English up to scratch
<dholbach> mdke: I suppose 'Yes'? :)
<mjg59> Oh argh.
<mjg59> Does http://librarian.launchpad.net/1568090/buildlog_ubuntu-dapper-i386.glitz_0.5.2-1_FAILEDTOBUILD.txt.gz make sense to anyone?
<Diziet> /bin/sh ../libtool is, erm, inspired.
<mjg59> It builds fine here, so I'm guessing that it wants an extra build dependency
<mjg59> But I honestly can't see what
<Diziet> if test -e ./libtool ; then cp -f /usr/bin/libtool ./libtool  ???
<Diziet> But only if  "" = "post"
<ogra> mjg59, a dependency on autotools-dev ? 
<mjg59> It has that
<mjg59> Ngh.
<ogra> hmm
<mjg59> It needs to build-depend on libtool!?
<janimo> maybe it's libtool that says something is missing
<janimo> I saw something similar bu tmaybe not quite this with some missing .la files
<mjg59> (Removing libtool results in the same failure)
<ogra> normally libtool should be in autotools-dev 
<janimo> of course it dod not say which it needs
<mjg59> ogra: ?
<ogra> shouldnt it ? 
<mjg59> autotools-dev just provides config.guess and config.sub
<ogra> oh
<janimo> mjg59, tried running libtool by hand in there?
<mjg59> The package is libtoolised
<janimo> I mean tried by hand for debugging?
<mjg59> janimo: Uh. What do you mean?
<janimo> in a failed build dir
<janimo> execute that bin/sh ../libtol line
<mjg59> In a failed build dir, there is no libtool
<janimo> and if it fails you can start looking what it exactly does
<janimo> are you sure then that libtool is missing?
<janimo> I thought maybe the not found message is echoed _by_ libtool
<mjg59> "No such file or directory" is pretty definite
<janimo> but nothing else
<mjg59> But yes
<janimo> I think I saw something similar
<janimo> libtool says that error too I think
<janimo> notice the colon after libtool
<janimo> the mesage is his not bash's
<janimo> so in the glitz deps I think one does not provide a .la file and that leads to this.
<mjg59> janimo: Go to an empty directory. Try /bin/sh ../libtool
<janimo> empty?
<mjg59> Yes
<mdke> dholbach, yes :)
<janimo> debuild -us -uc does something and leaves it that way
<dholbach> mdke: uploading
<janimo> ah ok so debuild by hand then try resuming where it failed
<janimo> mjg59, Oh I see I'll try
<mjg59> janimo: The error is that the configure script does not generate a libtool file
<dholbach> janimo: can you turn off the give-me-your-password-before-you-can-shutdown-xfce thing? :)
<janimo> dholbach, on the TODO list, by using priv separated HAL for PM :)
<janimo> mjg59, ok I am stupid, sorry for the noise
<mjg59> janimo: Heh, no problem :)
<dholbach> I see. :-)
<dholbach> mdke: done
<mdke> dholbach, yay thanks
<dholbach> mdke: de rien
<seb128> mjg59: usually we use -..ubuntu... versionning for uploads to Ubuntu
<Kinnison> mjg59: Have you sorted a new acpi-support with fixed acpi_fakekey goodness?
<ogra> seb128, that really depends if its expected to show up in debian
<Burgwork> Kinnison, I see you are running into that gpm crash as well
<seb128> ogra: for package like glitz which come from Debian....
<ogra> Burgwork, and he's fixing it
* Kinnison nods
<ogra> seb128, oh, there indeed ...
<Kinnison> ogra: well, not very effectively
* Burgwork hugs Kinnison 
<Kinnison> Currently the best fix for it is to debug it harder
<Kinnison> then it fixes itself until you give up and do something else
<ogra> heh
<Kamion> Kinnison: mako said he approved your membership, btw
<Kinnison> Kamion: yeah, I noticed another shiny emblem on my person page :-)
* Kinnison has spent the afternoon reviewing bugs, subscribing to some, asking for feedback on others
<Kinnison> mostly to do with toshibas or g-p-m
<zul> Kamion: ping..
<Kamion> zul: I already ponged earlier and you didn't respond ...
<zul> sorry i was busy with work, did you have a look at the interdiff i sent you
<sivang> Kinnison: cool :)
<Kamion> zul: jbailey already responded and sent it to Mithrandir who actually has an i2o system, so I'm letting him review it
<zul> ok cool..
<zul> sorry to bug you
<ploum> gnome-icon-theme updated in Dapper... Oh.. The old icons are back :-(
<ploum> I liked the new ones
<seb128> too many glitches for that cycle
<seb128> text preview broken, CD icon broken, mixer applet using wrong icon, etc etc
<ploum> seb128: ah ok
<seb128> the new spec is great, etc but that's a bit late in the cycle
<ploum> I understand
<seb128> ploum: note that's a GNOME choice, not a distro one :)
<seb128> (but I do think they take the right decision)
<ploum> thanks for the information
<ploum> I really  like the new one
<ploum> thanks for the information problem
<seb128> np
<seb128> maybe you can give a try to tango if you like the new one :)
<ploum> seb128: I don't like tango very much
<ploum> too blueish for me
<seb128> right
<seb128> so wait for next cycle :)
<seb128> new icon-theme using new spec will be a part of it
<ploum> https://bugs.freedesktop.org/show_bug.cgi?id=5608
<Ubugtu> freedesktop bug 5608 in icon theme "Folder icon must be a bit more neutral" [Normal,New]  
<ploum> but the most irritating thing in tango, IMHO, is :
<ploum> https://bugs.freedesktop.org/show_bug.cgi?id=5607
<Ubugtu> freedesktop bug 5607 in icon theme "Consistency between different files icons" [Normal,Resolved: notabug]  
<ploum> seb128: are you coming to FOSDEM ?
<seb128> probably not, no
<seb128> though I'm not totally decided yet
<ploum> Dommage... 
<ploum> We will also announce the launch of Ubuntu-be :-)
<Kamion> grr, I hate the way you have to subclass things in gtkmm in order to do the equivalent of signal_new
<Treenaks> ploum: ubuntu-be? why didn't ubuntu-nl hear of this? :)
<Treenaks> ploum: we have a few Belgians in there :)
<ploum> Treenaks: I talk about it a few times on #ubuntu-nl
<Treenaks> ploum: oh, some time ago then :)
<ploum> https://wiki.ubuntu.com/BelgianTeam?highlight=%28belgian%29
<ploum> Treenaks: yes, a few months ago
<ploum> But I will send an "official" announce as soon as I have the hour of the meeting
<ploum> (I will try to speak a bit in dutch ;-) )
<mjg59> seb128: Ngh. I thought that was just for modifications to synced packages?
<mjg59> Kinnison: Not as yet
<Kinnison> fyi the patch works fine on my laptop to make it suspend, but that then does expose the amusing re-suspend-on-resume bug
<Kinnison> so I'll hammer at g-p-m once I've finished re-triaging the bugs
<Kinnison> mjg59: but lock screen isn't quite working again yet
<mjg59> Kinnison: Right. That probably needs a touch more love.
<ogra> Kinnison, but thats g-s-s responsibility ...
<Kinnison> ogra: Hmm
<ogra> g-p-m doesnt do locking ... it only calls g-s-s
<ogra> (at least its supposed to do that)
<ogra> there was a silly discussion upstream that resulted in g-p-m doing dpms and g-s-s doing all the rest ...
* Kinnison goes for supper, back in a bit
<carlos> seb128: hi
<carlos> seb128: dude, gnome-xchat is not able to disable the away message???
<Tm_T> carlos: it might disturb users?
<carlos> Tm_T: disable, not 'display'
<Tm_T> carlos: function as function ;(
<mjg59> Kinnison: Uploaded
<dholbach> seb128: disable away message?
<Kinnison> mjg59: cunning thought re: suspend-straight-after-resume
* sivang is joyed while using generators.
<Kinnison> mjg59: could it be that we have keypress suspending, and also key release suspending?
<janimo> sivang, working on backup spec?
<sivang> janimo: yup
<janimo> ready till freeze? :)
<sivang> janimo: we'll see , I'm doing my best , cutting down some sleep time is in place :)
<mjg59> Kinnison: Doubt it
<mjg59> It's supposed to be checking the value of the press
<Kinnison> mjg59: aye, it was just a random thought while eating dinner
<janimo> sivang, good luck :)
<janimo> mdz, if you're around please grant UVF exception for ivman - forgot to put in on the xubu list. Latest version has bugfixes specifically requested for xfce session shutdown handling. thanks
<sivang> janimo: thanks, I'm gonna need it.
<janimo> sivang, got no help? isn't  sbackup author interested too?
<sivang> janimo: ah ops, that last sentence was meant with a :-)
<sivang> janimo: not really, he didn't quite like the design and concept, IIRC. I'm mostly fine, could just use some more free time :)
<ryanpg> mjg59, hey noticed some effort going into getting Xgl packaged... just wanted to say: thanks :)
<shaya> stupid Q.  where can one track what packages are being prepared to be installed?
<shaya> people are saying "compiz has made it to universe", but i don't see it in launchpad nor in my available package list
<shaya> when I mean "installed" I mean into the archive
<azeem> there is the dapper-changes list
<mjg59> shaya: It's in the NEW queue. It needs manual intervention before it'll get any further.
<shaya> mjg59: that was my Q
<shaya> where can one view what's in that queue
<shaya> is there a web page?
<mjg59> I don't believe you can
<shaya> hmm, oh well.
<olemke> shaya, https://launchpad.net/distros/ubuntu/+builds
<janimo> olemeke, that does not show the NEW queue unfortunately
<shaya> all it says is compiz failed ot build on i386
<olemke> janimo, ah ok :-(
<janimo> hopefully it will :)
<LeeJunFan> us archive has not been updating - at least breezy for a few weeks now. Anyone here that can do something about it? I posted to lists but I did that when I noticed and must be no-one notice my post.
<dholbach> breezy shouldn't change
<dholbach> breezy-updates and breezy-security should
<LaserJock> LeeJunFan: that is why I've been using archive.ubuntu.com for a long time. us.a.u.c is often out of sync (at least in the past)
<tseng> please dont encourage him, daniel is correct
<LaserJock> tseng: I'm not trying to encourage him but in his email he says it is out of sync
<LeeJunFan> dholbach: latest kernel image there is build 26 archive.ubuntu.com has 28, I've been using that too because us isn't working right.
<LeeJunFan> it's slow as hell today though, I can only get about 10K from main archive, us I can pull over 300K. :(
<dholbach> kernel-image?
<dholbach> it's slow today, that's known and worked on
<LeeJunFan> linux-image
<LeeJunFan> linux-image-2.6.12-10-386_2.6.12-10.28_i386.deb is not on us.archive
<seb128> mjg59: Debian has a glitz package too by example
<seb128> carlos: how so? /away doesn't work?
<carlos> seb128: that sets the away but how do you disable it?
<mjg59> seb128: Yes, but not for that version
<Treenaks> carlos: /away again
<seb128> mjg59: yeah, but they might package it and use the same version as you, they don't have for habit to check on Ubuntu and use -debian... versions in case we already used it
<seb128> carlos: /away
<carlos> Treenaks: really?
<seb128> sure
<carlos> didn't know that....
<carlos> thanks
<seb128> :)
<carlos> O:-)
<seb128> carlos: every day we learn a bit :)
<Seveas> carlos, many irc clients have /back aliased to /away for your cnvenience :)
<LeeJunFan> looks like ca.archive.ubuntu.com is old too.
<Amaranth> ca == us
<Amaranth> most of the country code mirrors are the same couple of machines, i think it's so they can add more later without trying to get users to update their sources.list
<LeeJunFan> Amaranth: they are different cnames and resolve to different addresses.
<LeeJunFan> they resolve to different cnames that is. mirror.arcticnetwork.ca and ubuntu.mirrors.tds.net for the USA.
<Mez> infinity, cheers for the upload
<shaya> mjg59: any chance you can apply an fglrx patch hack to glitz?
<shaya> glitz doesn't seem to recognize fglrx's pbuffer support w/o it
<mjg59> shaya: Possibly, if you can provide a pointer
<mjg59> But I'd rather not add mad hacks
<shaya> small patch
<shaya> but without it, glitzinfo says I have no pbuffers on my t42p
<shaya> mjg59: http://ubuntuforums.org/showthread.php?t=127090&page=33
<shaya> near the top
<Treenaks> http://ubuntuforums.org/attachment.php?attachmentid=6046&d=1139694349
<shaya> though revman applied something on 2/10 to do something, but doesn't seem to do much for me
<shaya> fglrx hack and some missing ChangeLog entries
<shaya> "fglrx hack and some missing ChangeLog entries" (being his changelog entry)
<shaya> for src/glx/glitz_glx_extension.c:1.3->1.4
<shaya> PatchSet 111 (as computed by cvsps)
* mdke seethes at people posting to -devel about yelp, who plainly haven't tried dapper
<Treenaks> mdke: yelp in dapper segfaults on startup
<shaya> it does?
<mdke> Treenaks, yes it does.
<shaya> I'm running it now
<Burgwork> Treenaks, it should be fixed now, see the latest in the thread
<shaya> no one tell my yelp that
<mdke> Treenaks, but that's not what I am referring to
<mdke> its a shame to see people saying "yelp has had no love this cycle" when the speed has been improved by about 4000%
<Treenaks> speed love!
<Treenaks> I've also noticed overall memory usage reductions
<Treenaks> in all of gnome
<sivang> Treenaks: probably moz stuff breaking it..
<mjg59> Damnit. 
<mjg59> My mesa build failed because I forgot to upload x11proto-gl first
<sivang> does anybody know about a good way other then going all over the files for calculating a a dir (actual size, not apparent) ? preferably in python ;-)
<Treenaks> argh! shift+insert is broken in gnome-terminal
<Mez> infinity, ping
<MisterN> n8
<Pygi> fabbione: ping
<dholbach> Pygi: i suppose he's in bed
<Pygi> dholbach: k, thanks
<Pygi> if I am not around once he gets online, please tell him that daily build of ubuntu-server installs cleanly
#ubuntu-devel 2006-02-19
<mdz> seb128: do you know if anyone is interested in visualization functionality in rhythmbox?  currently it seems only totem does this
<HiddenWolf> mdz: the request pops up from time to time
<HiddenWolf> mdz: rhythmbox upstream wouldn't mind, as a plugin
<HiddenWolf> mdz: and they are investigating hijacking gedit's plugin system now that 0.9.3 is out.
<mdz> only as a plugin?
<seb128> mdz: upstream has some plugin code to the CVS now, maybe they could do a plugin for it right
<HiddenWolf> mdz: doctau and the others feel that RB is a music player first and foremost, and that there is too much to improve in the core yet to think about branching out.
<seb128> do you think that visualisation is something useful for a music player?
<HiddenWolf> seb128: it'd make a hell of a screensaver in fullscreen mode with visualisations. :)
<mdz> seb128: yes, I like it
<mdz> it certainly makes more sense in rhythmbox than in totem
<seb128> totem has already a video area that's easy to do
<mdz> but totem isn't very nice as a music player
<seb128> but I think a rb plugin for that would be nice
<seb128> should be quite easy to do with gst
<dholbach> good night guys
<mdz> night dholbach
<dholbach> have a nice rest of the day, mdz :)
<nemonoid> if I spot a problem with a failed build on the build farm, is there any way, or even a point of reporting a possible fix?
<Burgwork> nemonoid, the uploader gets notified by email
<Burgwork> nemonoid, do you have a fix for the build failure?
<nemonoid> yeah...just wanted to know if there was a way of notifying the uploader
<Burgwork> nemonoid, email the maintainer if you have a fix, otherwise leave them alone as I am certain they are all over it
<LadyNikon> hey was anyone able to check out the bug for vpnc?
<LadyNikon> sorry had to find the bug
<LadyNikon> https://launchpad.net/distros/ubuntu/+source/vpnc/+bug/29727
<Ubugtu> malone bug 29727 in vpnc "vpnc: missing script vpnc-connect" [Normal,Unconfirmed]  
<sivang> night all
<Mez> mdz: ping
<hyperactivecrond> ubuntu express != gui installer, yes?
<Burgwork> hyperactivecrond, ubuntu express is now espresso
<hyperactivecrond> ok
<Burgwork> hyperactivecrond, and espresso allows installs from the livecd
<hyperactivecrond> espresso != gui installer
<hyperactivecrond> then
<Burgwork> it runs completely within GNOME on the live cd, so it is a gui installer
<hyperactivecrond> ah.  i thought they were 2 seperate things
<hyperactivecrond> are we doing a gui installer for the install cd/
<jblack> Hi. My computer is  self destructing. 
* hyperactivecrond puts on a bomb vest
<hyperactivecrond> whoops wrong channel for sarcasm... apologies jblack
<jblack> I tried changing my theme. The theme program crashed. Now it crashes everytime it starts. It also seems that many gnome apps are crashing. Even firefox crashes now
<hyperactivecrond> jblack: is this a development ? ?
<jblack> hyperactivecrond: It is for me.
<hyperactivecrond> file a bug?
<jblack> Did you catch "even firefox crashes" ? 
<jblack> I can't look up bugs or file a bug, or search google for other people solved it. #ubuntu isn't providing any help.
<hyperactivecrond> install kde? lol
<hyperactivecrond> try gnome failsafe login?
<jblack> Yeah. I can try that. brb
<jblack> No. everything crashes in failsafe gnome too.
<jblack> I think whats happened is that I've selected a theme that crashes gnome. I think I can get out of it if I can change the theme by hand
<hyperactivecrond> that works :)
<jblack> I don't know how. Thats why I'm asking for help.
<jblack> at least gnome-terminal runs
<hyperactivecrond> hmm...
<infinity> I assume the theme is broken, yes.
<hyperactivecrond> yes
* infinity pokes around for theme changing manually.
<infinity> jblack: Try ~/.gconf/apps/metacity/general/%gconf.xml
<infinity> jblack: The first entry in there is the theme on my mahcine... 
<infinity>         <entry name="theme" mtime="1129293671" type="string">
<infinity>                 <stringvalue>Human</stringvalue>
<infinity>         </entry>
<jblack> infinity: that took care of it, though I had to change about a dozen places in a half dozen files.
<jblack> Thanks!
* jblack goes off to file a bug
<whiprush> jblack: got your mail, I've been busy, but I'll get to it. :D
<jblack> whiprush: Great. email about what?
<whiprush> the bzr thing for the fridge.
<jblack> Ahh. You're Jorge?
<whiprush> yep
<netdur> is there any document about customization INSTALL cd?
<jblack> Ok. You guys should know this. There's a problem in dapper right now. If a user select the SphereCrystal theme, then theme manager will crash and refuse to start. Also, most other complicated applications will crash too.
<jblack> The proper solution is to reboot the computer, log into the console, grep through all SphereCrystal references, and replace them with something else -- say Human.
<fabbione> morning
<pitti> Good morning
<ajmitch_> morning pitti :)
<zakame> hi pitti 
<zakame> and ajmitch_ :)
<pitti> hi ajmitch_ 
<dholbach> good morning
<lemsto> hi there!!
<lemsto> i'd like to know if its possible ti take only few package from dapper and use them in breezy (such as firefox 1.5)
<dholbach> lemsto:  encourage to use just what was compiled for breezy, such as stuff in breezy-{updates,security,backports}
<dholbach> lemsto: and that's more of a #ubuntu question
<dholbach> hello mvo
<lemsto> dholbach, ok, thank u
<mvo> hello dholbach
* mvo yawns
<dholbach> lemsto: no worries
<sivang> good morning all!
* sivang is happy after a very good glade design sessions last night.
* pitti hugs sivang
<pitti> sjoerd: I'm currently preparing a hal diff for you with changes that are interesting for Debian; do you have some minutes to talk about it today?
<pitti> mjg59: is your add-keyboard-addons hal patch already upstream?
<sjoerd> pitti: yeah, probably tonight
<sjoerd> btw davdid said he would probably release 0.5.7 today
<pitti> sjoerd: uh, that would be nice
<pitti> although I'm not sure whether we can upgrade to it
<pitti> sjoerd: http://people.ubuntu.com/~pitti/patches/hal-ubuntu-debian.diff
<pitti> sjoerd: some patches speak for themselves, but some require some explanation
<pitti> sjoerd: I will be online until at least 1700 CET (1600 UCT)
<pitti> UTC, even
<sjoerd> hrm, dunno if i will be back then
<dholbach> mdz, Kamion: the new ekiga (part of GNOME release) will require a new pwlib and opal - luckily this time there is no API breakage this time. Do you want me to send you a UVF exception report or something?
<sjoerd> probably have some time later in the morning too... i'll ping you :)
* sjoerd gotta go now
<dholbach> mdz, Kamion: upstream (which is debian-voip team as well) has packages ready, which i will just have to modify for debian/changelog (since they're stuck in debian NEW)
* Mithrandir radiates hate at random stuff taking forever and ever and ever and ever to install due to gconftool-2 being the slowest piece of software on earth.
<slomo_> Kinnison: hi... is stuff on dep-wait cleaned automatically now?
<mjg59> pitti: Yup
<Treenaks> mjg59: had time for the wacom-tools update yet? :)
<mjg59> Treenaks: Nope - yesterday didn't entirely work out as planned
<Treenaks> mjg59: I saw heaps of Xgl-related uploads ;)
<lemsto> mondus44
<lemsto> oops
<lemsto> sorry
<lemsto> :)
* Treenaks knows lemsto's password now
<lemsto> nop, wrong channel
<lemsto> :p
<viviersf> hmmm
<viviersf> weird
<viviersf> new dapper chroot's locales doesnt want to regenerate :/
<Mithrandir> not even if you do a locale-gen $localename?
<pitti> viviersf: what do you mean? does it say 'up-to-date'?
<viviersf> i made a new chroot for dapper
<viviersf> so i can start a new impi build
<viviersf> dpkg-reconfigure locales just sais
<viviersf> setting locale failed and a some other things
<viviersf> http://pastebin.com/554049
<Mithrandir> viviersf: do locale-gen en_US.UTF-8
<viviersf> kewl thx
<viviersf> but if i want all the locales to get generated or is that a bad idea ?
<seb128> Riddell: "juk" still use gst0.8?
<Mithrandir> viviersf: install language packs, then.
<viviersf> kk
<Riddell> seb128: oh yes, I'll get rid of that
* Riddell does so
<seb128> thank you
<pitti> heeey Keybuk, welcome back
<viviersf> thx Mithrandir :)
<Keybuk> not "back", just being more cheeky <g>
<Keybuk> pitti: did you get any further with your bug?
<pitti> Keybuk: I added the udev stanza, but I didn't reboot yet
<pitti> Keybuk: will do soon, but I wanted to finish some stuff first
<pitti> Keybuk: this morning I was lucky and both eth cards were alright
<Keybuk> ok, thanks
<Keybuk> I have a hunch it's linux-wlan-ng being silly
<ogra> seb128, where or what is python-gst0.10 ? it breaks the CD 
<pitti> Keybuk: but I don't use l-w-n on my desktop, I only have proper eth cards
<Keybuk> pitti: ok, maybe it's not then :p
<seb128> ogra: universe
<ogra> ah, k ...
<seb128> ogra: I'm not doing promotions, talk to Kamion :)
<ogra> yup
<Kinnison> slomo_: not currently
<ogra> Kamion, ?? ^^^ can you promote python-gst0.10 ?
<ogra> serpentine depends on it 
<ogra> seb128, i guess its the successor of 0.80 so no main inclusion report needed, right ? 
<seb128> correct
<ogra> :)
<stub> Launchpad is going down in 10 minutes for the weekly code update. Estimated downtime is about 10 mins. wikis will be in readonly mode.
<Kamion> dholbach: those are fine
<Kamion> ogra: I can't do promotions at the moment because I have no idea how to do override changes in Soyuz, sorry
<Kamion> Kinnison: could you change python-gst0.10's override to main, or is that still an elmo thing?
<stub> Update: Launchpad is going down in 15 minutes for the weekly code update. Estimated downtime is about 10 mins. wikis will be in readonly mode.
<dholbach> Kamion: thanks
* ogra giggles while watching gnome-control-center build .... what the hell are eggaccelerators silly names ...
<Kinnison> Kamion: elmo
<Kinnison> Kamion: if he'd tell you how, that'd be grand
<Treenaks> ogra: gnome egg* is unstable/not-yet-finished stuff
<ogra> speed up your brekfast with our new eggaccelerators !!!
<Kinnison> Kamion: I believe it's the override-change.py but I have no idea if he's fixed it all up yet
<Keybuk> ogra: eggs that give you the runs?
<ogra> hehe
* ..[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 | Flight CD 3 released | If your initramfs is broken in any way, please save a copy for infinity | LP Upgrade was today, please report bugs if you see 'em | Launchpad maintenance in progress, uploads queued
* ..[topic/#ubuntu-devel:Keybuk] : 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 | Flight CD 3 released | If your initramfs is broken in any way, please save a copy for infinity | Launchpad maintenance in progress, uploads queued
<ogra> seb128, the patch from gnome bug #94049 works fine on all arches, no regression for normal usage, i'll do more testing with multihead people to confirm it works there as well
<seb128> cool
* ..[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 | Flight CD 3 released | If your initramfs is broken in any way, please save a copy for infinity | LP upgrade was today, please report new bugs if you see 'em
<Kinnison> expect queued uploads to be processed in 3 minutes time
* Kamion attempts to read gtk+2.0 source and discovers yet another 'debian/rules <givemethedamnsource>' argument to add to his list
<Kamion> <cjwatson@cairhien ~/src/packages/gtk+2.0/gtk+2.0-2.8.10>$ debian/rules patched-source
<Kamion> <cjwatson@cairhien ~/src/packages/gtk+2.0/gtk+2.0-2.8.10>$ debian/rules patch
<Kamion> <cjwatson@cairhien ~/src/packages/gtk+2.0/gtk+2.0-2.8.10>$ debian/rules apply-patches
<Kamion> <cjwatson@cairhien ~/src/packages/gtk+2.0/gtk+2.0-2.8.10>$ debian/rules unpack
<Kamion> <cjwatson@cairhien ~/src/packages/gtk+2.0/gtk+2.0-2.8.10>$ debian/rules setup
<Kamion> <cjwatson@cairhien ~/src/packages/gtk+2.0/gtk+2.0-2.8.10>$ debian/rules extract
<Kamion> (the last after reading debian/rules)
<Kamion> please provide aliases for some of the more common ones found in other packages so my chances increase
* Keybuk *hugs* his trusty zsh tab-expansion rule
<Keybuk> debian/rules <tab> .... oh-bugger-its-not-obvious
<Kamion> debian/rules should not be as hard as tla :P
<Treenaks> make needs a way to list targets ;)
<Kamion> (the latter of which certainly requires completion to use sanely)
<ogra> debian/rules gamble ?
<StevenK> oh-bugger-its-not-obvious is a great target for debian/rules!
<Treenaks> ogra: debian/rules random
<ogra> Treenaks, yes, that would be called by gamble ;)
* StevenK notes his zsh doesn't tab complete debian/rules.
<ogra> before debian/rules win or debian/rules loose :)
<Keybuk> StevenK:
<Keybuk> _debian_rules() { words=(make -f debian/r
<Keybuk> _debian_rules() { words=(make -f debian/rules) _make }
<Keybuk> compdef _debian_rules debian/rules
<Keybuk> -- 
<Keybuk> (obviously without the first incomplete line)
<pitti> mjg59: do we have any excuse to upgrade to hal 0.5.7?
* mvo is away for lunch
<seb128> pitti: you didn't ask me, but like it has the .capacity for CDs and ncb? :)
<seb128> pitti: you may be interested by http://mail.gnome.org/archives/gnome-vfs-list/2006-February/msg00007.html
<pitti> seb128: we'll also need the new ncb patch for that
<pitti> seb128: right, that could be interesting, will take a look at it
<seb128> pitti: there is some chance than we ship with a GNOME that requires the new hal ...
<pitti> seb128: the LUKS stuff still needs serious cleanup
<seb128> for stuff like that patch 
<mjg59> pitti: Several bugfixes
<sivang> Keybuk: does it expand to the make targets in rules?
<Keybuk> sivang: yes
<Keybuk> at least, it should
<Keybuk> (and seems to)
<Keybuk> pitti: could you attach your /etc/iftab to bug 31188 please
<Ubugtu> malone bug 31188 in udev "device named eth0_clashed during swapping" [Major,Needs info]  http://launchpad.net/bugs/31188
<pitti> Keybuk: I already did?
<sebest_> sjoerd: ping
<Keybuk> ah, it's in a comment, sorry
<Keybuk> pitti: can you try something for me:  run /lib/udev/iftab_helper eth1 00:06:4f:06:80:7c 1
<pitti> $ /lib/udev/iftab_helper eth1 00:06:4f:06:80:7c 1
<pitti> eth1_clashed
<Keybuk> :o
<ogra> heh
<pitti> is that good or bad?
<ogra> sounds not good
<Keybuk> I'm having a moment here
<Keybuk> I know why it doesn't work ;)
<Keybuk> BECAUSE THE CODE IS JUST DAMNED WRONG WRONG WRONG WRONG WRONG :p
* Kinnison hands keybuk some more bleach
* Treenaks also gives Keybuk the rusty blunt spoon
<Keybuk> pitti: grab the udev source for me
<pitti> god it
<pitti> got it, even
<seb128> we get quite a bunch of gnome-power-manager bugs, who is responsive for that package?
<Keybuk> http://people.ubuntu.com/~scott/80-extras-iftab_helper.patch
<Keybuk> replace that patch
<Keybuk> seb128: hmm, /^g/ ... you
<seb128> no no no :p
<Kinnison> seb128: I've been looking at it yesterday and this morning
<Kinnison> seb128: but other than that it's mostly been mjg59
<seb128> Kinnison: do you want to be the bug contact for it? :)
<ogra> seb128, worst case fall back on me
<seb128> there is no worst case
<seb128> there is just a pile of bug and nobody looking on them
<ogra> (if you dont find anybody ...)
* StevenK beats Keybuk with glibc
<ogra> i'm looking at them ...
<Kinnison> seb128: I'll be bug contact, sure
<seb128> if we do ship it for dapper somebody needs to be responsive for them
<Kinnison> seb128: I went through it a lot yesterday
<seb128> ok, cool
<Keybuk> StevenK: "with glibc" ?
<ogra> you might note that i'm subscribed to all of them
<seb128> lot stay un-assigned in fact
<mjg59> Keybuk: It's big and nasty
<Keybuk> seb128 maintains that too
<ogra> oh ?
<Keybuk> he's just in denial
<StevenK> Heh
<Keybuk> pitti: obviously then build and install it
<lifeless> he must be wet then
<Keybuk> and try the iftab_helper command again
* seb128 slaps Keybuk
<StevenK> lifeless: Teehee
<pitti> seb128: don't he's just fixing my network breakage!
<pitti> s/ he/, he/
<seb128> ok ok, I can wait a bit :)
<Kinnison> seb128: Do I have to do something in launchpad to be "bug contact" for g-p-m?
<Keybuk> seb128: so, upstream are considering renaming it to gdev :)
<Keybuk> Kinnison: 
<pitti> Keybuk: $ /lib/udev/iftab_helper eth1 00:06:4f:06:80:7c 1
<pitti> eth0
* pitti applauds
<Keybuk> click the "I want to be bug contact" link
<Kinnison> Keybuk: aah yes, thanks
<Keybuk> pitti: just don't diff the two patches, okay :)
<Kinnison> Keybuk: gdev?
<pitti> Keybuk: I overwrote it right away :)
<Keybuk> Kinnison: I think it's under Contact settings on the first bug page, or something
<Kinnison> Keybuk: already done, thanks :-)
<seb128> Kinnison: https://launchpad.net/distros/ubuntu/+source/gnome-power-manager/+subscribe
<seb128> good
<seb128> ogra: subscribe too if you are interested
<ogra> doing
<sebest_> hello, i just installed vmware-server webui on breezy, and the httpd included is looking for libssl.so.4
<seb128> thank you guys, so we have somebody gettings the bugs by default :)
* ogra waits for his inbox to explode
<Kamion> bah, signals not propagated across gtksocket/gtkplug
<Keybuk> ogra: I heartily recommend not having one
<Keybuk> no e-mail is liberating
* Kamion throws away several hours' work
<sebest_> i added a link named libssl.so.4 pointing to libssl.so.0.9.7 and it's working
<Keybuk> not to mention causes a massive increase in productivity
<ogra> Keybuk, the bad thing about that is that my server doesnt know ... i tried that from christmas to mid january when my server was broken ...
<StevenK> Keybuk: I used that argument when I broke the mail server at work.
<StevenK> Keybuk: People didn't see it that way. :-)
<ogra> but it only resulted in 6000 unread mails after the new server was in place :(
* Keybuk tries to think of a decent musical
<Keybuk> I'm running out
<Treenaks> Keybuk: there aren't any?
<Kinnison> Keybuk: southpark: bigger, longer, uncut.
<StevenK> Oh dear god.
* StevenK smothers Kinnison.
<Keybuk> Treenaks: thankyou :)
<Keybuk> Treenaks: that has exactly the kind of lyrics I was looking for
* Kinnison has never heard of the "there aren't any" musical
<Keybuk> ok!  that should be the end of that udev bug
<StevenK> Keybuk: The King and I?
* Kinnison reads keybuk's change comment and realises he was just being mad for thanking treenaks
<Keybuk> Kinnison: no, attack of the tab key, s/Treenaks/Kinnison/ :)
<Treenaks> yeah, because t<tab> and k<tab> are so close :P
* Kinnison gives keybuk a great big valentine's day snog
<Keybuk> Kinnison: I'm sure my boyfriend and yours would object
<Kinnison> Keybuk: mine wouldn't complain so much as want in on the action :-)
<sivang> heh
<sivang> guys, as Steve once said in #lp , isn't this supposed to be a "family channel" ? :)
* mvo chuckles
<Yagisan> no, it clearly say #ubuntu-xxx ;)
<sivang> or maybe it's only #lp that's a family channel... 
<StevenK> Well, there was some hot and heavy developer on code action when Keybuk uploaded udev ...
<sivang> ha ha ha
<Keybuk> what's not family about two people snogging?
<Keybuk> two people have to do a lot more than just snog to *get* a family
<sivang> oh my god, I see that I gotta turn away from my loved irc window to get more work going :)
<sivang> Keybuk: what's snuggle ?
<Yagisan> StevenK: isn't the support line 1902-domyubuntu ?
<sivang> (dict used that word to explain snog)
<Treenaks> sivang: dict ;)#
<sivang> Treenaks: what is snuggle then ? :)
<Treenaks> sivang: dict tells you :)
<Yagisan> sivang: TTBOMK it is/was slang for sex
* Kinnison laughs
<Kinnison> dict's answer for 'snog' is typically wrong
<Keybuk> heh
<Yagisan> snog should be kiss, but you'd need a pom to confirm
<Keybuk> very wrong
<dholbach> ding offers "to pet, to to neck, to smooch" as well
<sivang> snog: snuggle and lie in a position where one person faces the
<sivang>          back of the others
<sivang> according to dict.
<Kinnison> sivang: aye, that's wrong
<Keybuk> that's spooning
<pseudo> hi dudes.
<Kinnison> hi pseudo 
<Keybuk> http://www.urbandictionary.com/define.php?term=snog
<Treenaks> dict needs an urbandictionary plugin (or, ud needs to export their db as a dict service)
<sivang> pseudo: that's one hack of a clock you've got there :)
<Treenaks> hack? or heck? :P
<sivang> Treenaks: ah ah ah!
* sivang couldn't help it anymore
<pseudo> lol heck
<pseudo> =p
<Keybuk> I think we should usurp dholbach's "hug day" and replace it with "snog day"
<Treenaks> snug day?
<dholbach> Keybuk: right, let's think about the proper announcement later :)
<Yagisan> oh god no - I just imagined it.
* sivang finds the british meaning of the temn, accoridng to urbandict
<dholbach> Yagisan: stop whinging :))
<sivang> heh "A word originating in London, England. Meaning KISS. *Hopefully nothing more*."
<tseng> "The two British girls in my class always sneak off to the toilet together to do a bit of snogging between every class."
<tseng> is this true?
<sivang> heh
* sivang changes the topic to "Ubuntu Development and Comedy channel"
<Keybuk> tseng: trust me, while a Lesbian might be a fine friend, when they get plural it's *always* trouble
<Yagisan> Keybuk: from experience ?
<Keybuk> Kinnison: back me up on this? :)
* ogra does ...
<tseng> Keybuk: will take your word, i only have a handful of gay males as friends
<tseng> Keybuk: im not sure i remember even talking to a lesbian.
<sivang> Keybuk: you and Kinnison and twl girls? now that's what I call party :)
<Keybuk> infinity: ping?
<Yagisan> sivang: no, that sounds like a nightmare
* Kinnison nods, two == danger
<Kinnison> they gang up
<Kinnison> most scary
<Yagisan> even just 1 is dangerous
<Keybuk> nah, one can be useful; especially if you need shelves putting up
<Keybuk> or other work done around the house
<Kinnison> like kitchen floors laying
<Kinnison> they're good at that
<Keybuk> coo ... I just found a source package I've completely failed to upload :)
<sivang> Kinnison: why is it bad when they gang up ?
<tepsipakki> gtkpod-aac
<tepsipakki> duh
<Yagisan> sivang: how old are you ?
<Kinnison> sivang: it's hard to explain :-)
<sivang> Yagisan: 27, why?
<sivang> Kinnison: s/hard/complicated/ :p
<Yagisan> sivang: you should know by now why then. when they gang up, you can kiss you plans goodbye
<Yagisan> s/you/your
<infinity> Keybuk: pong, but only briefly (note the away message)
<Kinnison> sivang: Oh no, I can explain very simply, but we'd have to fire up skype so you could hear me scream in terror
* Kinnison goes to grab lunch
<sivang> Kinnison: I'll take you up on that.
<Keybuk> infinity: did you ever make any changes to the sysvinit patch I did for the K scripts?
<infinity> Keybuk: Yeah, I did.
<Keybuk> infinity: where did you put them?
<infinity> Keybuk: http://cerberus.0c3.net/~adconrad/rc
<Yagisan> sivang: this ganging up behaviour - it seems to be genetic. my little one, and her mum try to gang up on me when they are together.
<infinity> Keybuk: Granted, that could probably be rewritten in a way you feel is more sane, that's just the version I was testing with on my system (which does work)
<sivang> Yagisan: ah, I understood now, so ganging up you meant like "we're all girls decided to do X, and that is why you will have to conform with us"
<Treenaks> http://www.oreilly.com/catalog/ubuntuhks/?CMP=NLC-TT3401179977&ATT=w3
<Keybuk> infinity: cheers
<Keybuk> (which reminds me that I need to officially send apologies that I won't be at this evening's TB meeting)
<mjg59> Keybuk: Ok, sounds like we should possibly skip tonight
<Keybuk> mjg59: oh, who else is apologising?
<Yagisan> sivang: that's part of it. although there isn't always a rational reason for wanting to do X
<sivang> Treenaks: yay, he released it eventually .
<Yagisan> Keybuk: think of the day. anyone with even a hope of having a significant other is probably practising their apology.
<Keybuk> indeed, I'd quite like some sex this year, after all
* Yagisan didn't even get a card.
<mjg59> Keybuk: Matt can't make it at the normal time
<Yagisan> Keybuk: I find it all goes quite well until you have kids. then it is worse then being single
<SAAD3000> Hello, i have a problem connecting from Ubuntu to the internet but from xp it works fine.
<SAAD3000> any ideas please.
<dholbach> SAAD3000: that's more of a #ubuntu question
<SAAD3000> dholbach nobody can help i asked from yesterday night, really they ended up by "I don't know", "strange", "weird" things like that.
<SAAD3000> I really like ubuntu i don't want to uninstall it, but why i can't connect.
<dholbach> SAAD3000: maybe writing to the ubuntu-users@lists.ubuntu.com mailing list helps
<dholbach> or filing a support request at   http://launchpad.net/support
<SAAD3000> kthanx man.
<dholbach> this is unfortunately the wrong place for suppotr
<dholbach> cool - good luck
<ogra> seb128, for g-s-d, tested on all arches, ltsp and two multihead setups ... http://people.ubuntu.com/~ogra/26_allow_single_user_multiple_logins.patch
<ogra> (its already a cdbs patch ...
<ogra> )
<dholbach> Kamion, mdz: are you ok with a gthumb-bugfix-only upload (11 gnome bugs, 3 LP bugs)?
<dholbach> Kamion, mdz: it's not a strict part of gnome desktop
<dholbach> Kamion, mdz: I can make the changelog/diffstat available on the net, if necessary.
<Kinnison> Keybuk: Given the TB is likely not to run, what's happening about my upload status?
<ogra> Kinnison, why shouldnt it run ? 
<dholbach> ogra: Keybuk apologized, Matt is said to not be able to make it, ...
<ogra> dholbach, oh, i didnt know about matt
<dholbach> <mjg59> Keybuk: Matt can't make it at the normal time
<ogra> ah
<Keybuk> Mark almost certainly won't make it either (he rarely does)
<ogra> i was testing g-s-d, missed that ...
<Keybuk> Kinnison: you'll need to ask mdz what he wants to do wrt that
<Kinnison> Keybuk: okay
<ogra> i guess you could go the mjg59 way with a separate approval "quick meeting"
* Kinnison will carry on with assuming he'll get upload soon enough and I'll get sponsors in the meantime :-)
<Kamion> dholbach: can you stick the changelog somewhere?
<dholbach> Kamion: yes
<Keybuk> seb128: could you update initscripts when it appears and try rebooting
<Keybuk> see whether that cures your /tmp and /var issues
<Kinnison> damnit my emacs fingers still need retraining
<dholbach> http://ubuntu.gplan.info/gthumb/
<ogra> seb128, can you also think about bug 29404 before uploading next gdm ?
<Ubugtu> malone bug 29404 in gdm "gdm should support alternate config file for cdd branding" [Normal,Unconfirmed]  http://launchpad.net/bugs/29404
* Kinnison keeps defaulting to opening ~/dev-canonical instead of ~/ubuntu-packages
<Kamion> dholbach: looks ok, go ahead
<dholbach> Kamion: merci beaucoup
<seb128> Keybuk: will try, thank you
<seb128> ogra: yeah, those 2 are on my list, don't worry
<ogra> seb128, thanks a lot :-D
<seb128> np
<_jdong> is it just me, or did a lot of fonts get much uglier within the past two weeks?
<jsgotangco> yeah dude
<jsgotangco> heh
<jsgotangco> serif hell
<jdong__> ack stupid network connection
<jdong__> was there anything else said about fonts that i missed?
<tseng> no.
<jdong__> is there any planned fix?
<jsgotangco> i still enjoy my serif hell
<hunger> jsgotangco: Same here.
<jsgotangco> even my display is slooww
<jdong__> jsgotangco: the slowness is pango
<jdong__> I think
<jdong__> but the appearance is just ugly
<jsgotangco> yeah
<jdong__> what's the exact problem??
<sivang> Keybuk: are you doing also uptream work for udev other then just integrating it to ubuntu? </curious>
<Keybuk> well, we work pretty closely with upstream
<jsgotangco> when someone sends a message from gaim, i get the sound first, then a second later, the text
<sivang> Keybuk: that is sending patches etc right? upstream is a RH guy?
<Keybuk> upstream is a SuSE guy
<Keybuk> all of our patches are sent upstream, and swapped with him
<Keybuk> and I chat to him a lot on IRC and via e-mail
<sivang> Keybuk: ah, kool
<Keybuk> sivang: any particular reason for the question?
<jdong__> jsgotangco: wow, try adding some infinite loops in esd to delay the sound? ;)
<jsgotangco> heh
* Keybuk hauls the amd64 out of the box for the second time
<jdong__> jsgotangco: I g2g, but you want to file a bug on the font ugliness?
<jdong__> if Dapper gets released like this, the reviews will burn us
<Keybuk> "all that pitiful font-deuglification"
<jdong__> Keybuk: you enjoy the new Dapper font?
<jsgotangco> jdong__, ok i'll check LP for possible dupes
<Keybuk> I can't say I've *seen* new Dapper fonts
<Keybuk> the bold terminal fonts still wobble, but they've done that for ages
* Kamion applauds the rtc.startTime option in VMware - now I can test those clock-skew installation bugs without having to find a sacrificial machine
<sivang> Keybuk: </curious> mostly, but I had the wrong idea that he was a RH guy, and you sorted it telling me he's a SuSE guy.
<jsgotangco> it reminds me of that old win98 theme with the steam train engine
<dholbach> Kinnison: I suppose this was asked a million times already, but why was it decided that will soyuz fetch new source uploads only hourly?
<mdke> our fonts are also missing some characters i think. would be awesome if anyone knows how to fix. See yelp, any document for the horror symbols
<Kinnison> cron.daily is hourly because it's currently too slow
<dholbach> Ok, that's a point. :)
<jsgotangco> mdke, i see lots of ugly section symbol borkage
<Kinnison> Keybuk: what's the quickest way to find out what app is listening to a given keyboard shortcut?
<mdke> jsgotangco, yes, its character 2002 that is missing
<jsgotangco> (for some reason the fonts look nice on yelp)
<Keybuk> Kinnison: no idea... press it? :P
* Kinnison spanks keybuk :-)
<Kinnison> Keybuk: I think I've solved the double-suspend bug
<Keybuk> ask an X expert
<Kinnison> Keybuk: but to know, I need to check the code of whatever listens for the sleep keyboard shortcut
<Keybuk> probably gnome-settings-daemon
<Keybuk> or metacity
<Kinnison> ta, I'll look thewre
<Treenaks> or gnome-power-manager
<Kinnison> Treenaks: given I'm working on g-p-m I'm fairly confident it's not that
<zakame> hi devs
* Treenaks needs an X dev, or at least a new ati driver upload
<jsgotangco> mdke, are we having your patch uploaded?
<Treenaks> I don't have working X on my minimac!
<ogra> Treenaks, patches are welcome :P
<Treenaks> ogra: daniels told me he had a patch a month ago. but then he disappeared.
<jsgotangco> heh serpentine is borked
<seb128> what is borked about it?
<slomo_> Treenaks: patch for which problem? broken desktop background, funky colors etc?
<ogra> slomo_, thats ppc specific 
<Treenaks> slomo_: no, funky refresh issues on X700
<Treenaks> slomo_: X700 + 1920x1200, actually
<Treenaks> slomo_: Never worked since breezy, I did some register dumps, too
<slomo_> ogra: i know... he was talking about his minimac so i thought he maybe meant that problem ;)
<Treenaks> oh, the minimac problem is a different one :)
<Treenaks> that's '1360x768 scales weirdly'
<Kamion> is it fixed upstream?
<Treenaks> Kamion: I have no idea, I don't know where to find the upstream changelog
* Kamion guesses at http://cvs.freedesktop.org/xorg/driver/xf86-video-ati/ChangeLog?view=markup
<Treenaks> ah .. xorg/driver
<Treenaks> not xserver/hw/
<Treenaks> Kamion: I think the 2006-01-19 entry is the fix he meant
<Kamion> does that description match your card?
<Kamion> https://bugs.freedesktop.org/show_bug.cgi?id=5656 is the bug
<Ubugtu> freedesktop bug 5656 in Driver/Radeon "ati radeon xpress 200 is an IGP chip" [Normal,Resolved: fixed]  
<tepsipakki> keybuk: since you are the sysvinit-guy, what do you think about https://launchpad.net/distros/ubuntu/+source/glibc/+bug/30141 ?
<Ubugtu> malone bug 30141 in glibc "nscd needs to start earlier" [Normal,Unconfirmed]  
<Treenaks> hm.. no..
<Kamion> the patch is specific to PCI_CHIP_RC410_5A62
<Kamion> I suggest e-mailing daniels and asking, if you haven't already done so; I think he's ignoring Ubuntu bugs
<Treenaks> Kamion: Hm... my bug is #20284
<Keybuk> tepsipakki: possibly, I must admit that anything rc2 doesn't hugely interest me right now
<tepsipakki> Keybuk: yes, all the cool stuff in rcS ;)
<Kamion> Treenaks: bug number typo? it's not 20284
<Treenaks> uh, 20283 sorry
<tseng> Keybuk: is HCT going live? i see some UI
<tseng> Keybuk: </schoolgirl>
<Mez> tseng: i'd love for it to golive
<Mez> lol
<Mez> make life so much easier
<Treenaks> HCT?
<siretart> tseng: ui?
<tseng> siretart: in launchpad
<siretart> where excatly?
<mvo> Diziet: can I bug you about those "dist-upgrade" conffile prompts? I asked about it a while ago and apparently it still happens on breezy->dapper upgrades
<tseng> siretart: on the source package page
<poningru> I had a question perhaps better suited for email list, are we doing something about adding tango?
<tseng> poningru: tango is added
<tseng> poningru: since months.
<ogra> tseng, that button is there since ages
<HiddenWolf> tseng: it's just not default. :P
<poningru> tseng: oh well the tango just looked a little bit less shinier
<poningru> nm then
<ogra> its not complete
<siretart> tseng: I fail to see what you mean, e.g. on https://launchpad.net/distros/ubuntu/+source/pmount
<ogra> and its blue ...
<poningru> yeah
<raphink> hmm seems cups is broken again :s
<ogra> so it would need brownification first 
<tseng> "it's not the default" is silly for most things, seeing as it takes a few seconds to install a package
<tseng> ogra: dapper+1 wont be brown
<ogra> tseng, how do you know ? 
<tseng> mark said something about how the look was going to change after dapper
<tseng> for 4 more releases
<raphink> how will it be tseng ?
<tseng> i dont know, i cant read his mind :)
<tseng> just what he said
<poningru> tseng: green!!
<ogra> tseng, i know he said it *must* not be brown ...
<ogra> but thats not definite saying it *will* not be brown
<raphink> lol
<ogra> :)
<tseng> I guess
<raphink> ogra: why? human?
<ogra> siretart, https://launchpad.net/distros/ubuntu/dapper/+source/ltsp
<ogra> raphink, ?
<Kamion> you mean "*might* not be brown" or "doesn't have to be brown", I think
<raphink> ogra: it must still be a human theme?
<Kamion> "must not" means "muss nicht" rather than "darf nicht"
<ogra> i have no clue which color dapper+1 will have, it might or might not be brown by marks statement
<Kamion> (if I remember my German right)
<ogra> Kamion, right ...
* ogra blushes, Kamions german is still better than ogras english :)
<Kamion> nah, I can't hold a conversation in it
<raphink> hehe
<tseng> ogra and dholbach still "stand up" in the morning :)
<raphink> well depends what kind of conversation I guess Kamion ;)
<tseng> and other germanisms
<ogra> Kamion, heh, but your grammar is better than most germans grammar 
<ogra> tseng, heh, yes :)
<ogra> siretart, look at the top right
<raphink> tseng: we also stand up in the morning in french :)
<ogra> and given that dholbach is french ...
<tseng> haha!
<Kamion> raphink: oh, I could probably hold my own online with the aid of a dictionary, but I have no hope of holding a spoken conversation at the moment unless it's artificially slowed down to a tenth of the speed
<raphink> hehe
<raphink> ogra: haha
<ogra> Kamion, hmm, that'd give very low tunes :)
<siretart> ogra: oh, so this means that is available only for packages, which have a Code branch associated. I see
<siretart> thanks
<ogra> siretart, its not available at all ... its only a dummy ...
<Kamion> ogra: heh
<raphink> anyone having issues with cups today?
<lemsto> is esound still used in dapper? and if yes is there a way to use gstreamer/dmix in stead of esd for all gnome events? :D
<ogra> BenC, everytime i suspend my ibook and wake it up again, my appletouch driver breaks and the mouse is stuck... known bug ? 
<ogra> rmmod/modprobe doesnt help ...
<mjg59> ogra: Using what mechanism for suspend?
<ogra> doesnt matter 
<ogra> suspend to ram either via g-p-m or pbbuttonsd
<ogra> i dont think its related to one of them ...
<ogra> rather a kernel or driver bug
<siretart> doko: python2.3 considered deprecated? huh?
<pitti> siretart: yes, we want it out of main
<pitti> doko: great progress, thanks :)
<siretart> pitti: oh. good to know. Do you know what the status about python2.4 as default in sid?
<pitti> siretart: not really, but AFAIK 2.3 is still the default; doko should know better, though
<siretart> pitti: yes. it is
<ogra> doko, oh, i see my chances for schooltool rise :)
<Mez> lmao@ the linda easter egg
<jpatrick> Mez: that poem?
<Mez> yeah
<sebest> mjg59: i read your post about brigthness control on laptop
<mjg59> sebest: Mm?
<sebest> and i'd like to know how you found these informations
<sebest> http://mjg59.livejournal.com/57875.html
<doko> siretart: in the final stages ...
<doko> ogra: why?
<ogra> doko, new zope3 ?
<sebest> because i'd like to do the same for my fujitsu siemens, and i'd like to have a starting point :)
<BenC> ogra: not known
<Kinnison> mjg59: (good) news
<Kinnison> mjg59: I've tracked down several issues relating to gnome-power-manager
<Alinux> mjg59, thank you bro! Super!      sudo apt-cache search georgian | grep bpg
<Alinux> ttf-bpg-georgian-fonts - BPG Georgian fonts
<doko> ogra: but no new schooltool yet ...
<siretart> doko: cool. good to hear
<Kinnison> mjg59: one at least is in the acpid package
<ogra> doko, i know ... jinty is working on it afaik
<Kinnison> mjg59: one is related to how gnome-power-manager is invoked in a normal session
<Kinnison> mjg59: bug 31407
<Ubugtu> malone bug 31407 in acpid "powerbtn.sh incorrectly looks for PowerManager" [Normal,Unconfirmed]  http://launchpad.net/bugs/31407
<BenC> Mithrandir: ping
<ogra> BenC, anything i can do to get more info about the appletouch thingie ? 
<BenC> ogra: more than likely, it just needs to be added to the suspend/resume scripts as a module that needs unload/reload
<ogra> ah, k
<raphink> is http://people.ubuntu.com/~lamont/ obsolete now?
<ogra> raphink, depends for what ...
<dholbach> raphink: if you mean the buildLogs, then yes
<ogra> i guess lamont still uses it :P
<Mithrandir> BenC: pong?
<ogra> raphink, https://launchpad.net/distros/ubuntu/dapper/+builds
<raphink> dholbach: oh ok didn't know
<raphink> where can I find the buildlogs now then?
<siretart> how do we get a list of packages, which currently FTBFS?
<siretart> raphink: the package's page in launchpad has the buildlogs linked
<ogra> siretart, there is a filer 
<raphink> thanks ogra, useful to know 
<ogra> *filter
<dholbach> siretart: https://launchpad.net/distros/ubuntu/dapper/+builds?build_state=failed
<siretart> thanks dholbach 
<ogra> just select it from the pulldown
<raphink> siretart: pretty useful, but how about this ? https://launchpad.net/distros/ubuntu/dapper/+source/revu-tools
<siretart> ah, right, thanks
<raphink> siretart: how do I know the where this has stopped?
<pitti> Kamion: still remember this 'dhlient.conf only contains NetcfgDHClient' line bug? this is already fixed, right?
<Kamion> pitti: yeah
<siretart> raphink: looks like it has not been attempted to be built
<pitti> Kamion: in which package? I'd like to close bug 30220
<Ubugtu> malone bug 30220 in hal hal-device-manager "Problem with automatic start NIC adapters after update Dapper Drake Flight CD3" [Normal,Confirmed]  http://launchpad.net/bugs/30220
<Kamion> we don't propagate netcfg's private vendor class id any more
<raphink> siretart: indeed, yet it's on my LP page
<pitti> ah, netcfg, thanks
<raphink> siretart: https://launchpad.net/people/raphink/+packages you see?
<raphink> siretart: revu-tools and konq-kim are on my LP page, although they haven't been built
<raphink> siretart: and I don't seem to be able to know where they're stuck
<Kamion> pitti: you can mark it as a dup of bug 27141
<Ubugtu> malone bug 27141 in netcfg "error message: no option named dhcp-class-identifier" [Normal,Fix released]  http://launchpad.net/bugs/27141
<pitti> will do, thanks
<Kamion> and tell the user to just remove that line
<BenC> Mithrandir: can you give me the exact mkisofs command used to create the daily-live cd's for ppc?
<Kamion> BenC: I stand a better chance probably, give me a second
<BenC> Kamion: ok, thanks
<Kamion> BenC: first, grab http://people.ubuntu.com/~cjwatson/hfs.map
<Mithrandir> BenC: no. :-)  https://wiki.ubuntu.com/LiveCDCustomizationHowTo should have it.
<Kamion> BenC: then I think it's "mkisofs -r -V 'Ubuntu 6.04 ppc Bin-1' -o dapper-live-powerpc.iso --netatalk -hfs -probe -map hfs.map -part -no-desktop -hfs-bless <path/to/cd/tree>/install -hfs-volid Ubuntu/PowerPC_dapper <path/to/cd/tree>'
<BenC> Kamion: thanks
<siretart> raphink: I don't know either. If you are already waiting for it for some time, I'd suggest asking in #launchpad
<BenC> Kamion, Mithrandir: I'm testing mksquashfs 3.0 to see if it avoids the oops on ppc
<raphink> siretart: ok thanks
<BenC> our current kernel module is 2.1/3.0, but our mksquashfs is 2.1 (so we aren't using much of the newer code)
<Mithrandir> BenC: wasn't the oops in unionfs rather than squashfs, though?
<BenC> no, it's in squashfs, and occurs when readahead-list is called
<Kamion> BenC: actually we also put '-chrp-boot -iso-level 2' in there now
* ogra didnt see the oops on his test on friday
<BenC> atleast the oops I am seeing right now is
<BenC> I just tested yesterdays live-cd and it oopsed on my pb
* Kamion updates his rune file
<ogra> hmm
<BenC> it ran fine, but the oops is still there
<Kamion> (I should make debian-cd actually log its mkisofs command)
<BenC> Kamion: a file in install/mkisofs-cmd.txt would be nice
<Kamion> BenC: yeah, I agree, been meaning to do that for a long time
<BenC> the crazy part is, if I mount the squashfs locally, and run /etc/init.d/readahead from chroot, it doesn't cause an oops
<Mithrandir> BenC: maybe some weird interaction with unionfs, then?
<BenC> Mithrandir: who knows, it crashes inside of __down(), but that doesn't make any sense
<BenC> the mutex seems to be initialized just fine
<Mithrandir> stack gone boom?
<Mithrandir> but that'd probably make your system wobbly afterwards..
<BenC> well, it crashes inside add_wait_queue_exclusive() actually, but the calls if from __down() on the fragment_wait semaphore
<janimo> mvo ping
<mvo> janimo: pong
<janimo> hello, I replied to your mail
<janimo> so if it's too much bother keep gconf
* mvo checks mail now
<janimo> does kubuntu have an update-notifier?
<jpatrick> janimo: yes
<janimo> so gconf is part of kubuntu as well?
<mvo> it seems like one issue is that gconf must be split out of python2.4-gnome2, it's currently all one big package
<jpatrick> well there's adept-updater
<janimo> mvo, hmm I filed a bug on LP regarding splitting out gnomecanvas from same
<mvo> janimo: thanks, that's nice. I don't use it for fancy stuff, it's just *so* convenient :)
<janimo> I may have to look at it and provide a patch to seb since this comes up in quite a few gnome-python packages which do not actually req gnome
<janimo> like gcompris
<janimo> mvo, so kubuntu-updater is a different app entirely?
<jpatrick> yes
<janimo> too bad.
<janimo> I mean it would be nice instead of so mucg duping just have backend+ qt and gtk frontends
<mjg59> sebest: Sorry, my connection died
<mjg59> sebest: Mostly from reading the drivers
<mvo> yes, it's a unfortunate situation
<janimo> I wonder if they chose this path because of gnome-python deps or other core logic is different in their app
<ogra> janimo, ugh, splitting out gnomecanvas would probably cause a huge transition ...
<janimo> ogra, not necessarily
<ogra> there are mmayn apps using it
<janimo> you could just keep depending on gnomepythons
<ogra> *many
<janimo> and transition package by package if needed
<mvo> janimo: it's mostly historical reasons
<janimo> g-pythjon would dep on canvas-python
<mvo> if we switch to smart for dapper+1 things will converge again
<janimo> mvo, including adept synaptic or is that divergence for good?
<sebest> mjg59, and if there is no windows software or driver provided by the manufacturer? 
<janimo> a smart, I did not read that part of the sentence
<janimo> ogra, the packs I found so far ar hwdb-client and gcompris
<ogra> ldm/ltsp-client is another
<sebest> mjg59, i can try to test the different options that you discovered and cross my fingers :)
<janimo> ogra, does that too bring in gnome just for canvas?
<ogra> and i guess there are much more where you have to look at the source
<ogra> yes
<janimo> and that ldm/ltsp is client side in edubuntu?
<ogra> it uses other pygtk stuff though ... 
<ogra> yes
<mjg59> sebest: What hardware do you have?
<ogra> its in the chroot you build with ltsp-build-client 
<janimo> well those gnome libs are not loaded on startup so it's not _that_ bad, but are installed nevertheless
<ogra> not really obvious to catch the dependencys
<sebest> mjg59, a fujitsu siemens amilo d 7400
<sebest> i can control brigthness using the fn+left/right keys (but no way in software)
<janimo> mvo, but in theory if you don't use gconf fanciness would using an ini file be ok?
<janimo> since gtk has a nice api for that too
<janimo> actuallly glib
<mjg59> sebest: Easiest thing to test is doing watch 2 cat /dev/nvram
<mjg59> After loading the nvram module
<mjg59> Then see if it changes as you change the brightness
<sebest> mjg59, ok, i test this
<janimo> mjg59, since a recent upgrade (kernel? udev?) I cannot hibernate
<janimo> acpi_sbs uses stuff
<mjg59> janimo: "uses stuff"?
<janimo> so hibernate just triggers screensaver
<janimo> hmm don't have the exact message
<janimo> a moment
* Kinnison gets workraved. joy
<janimo> ERROR: Module ac is in use by acpi_sbs
<janimo> ERROR: Module battery is in use by acpi_sbs
<mvo> janimo: yes, sure. I'm too busy to rewrite the code currently
<janimo> so hibernation starts. screen blanks but after ~10 sec it just pop up the screen lock dialog
<mjg59> Ah, ok
<mjg59> Hmm. No, that's almost certainly not the problem
<mjg59> That code doesn't get called until the resume
<janimo> hmm /etc/acpi/hibernate.sh: line 27: echo: write error: No such device
<infinity> mjg59: While people are bugging you, any plans to make /etc/acpi/lid.sh DTRT with gnome-screensaver?
<janimo> maybe this a bit above
<mjg59> infinity: Yes
<mjg59> (That is, do nothing)
<infinity> mjg59: Oh.  Nothing is kinda what it already seems to do.
<janimo> other than that the usual warnings: cardctl not found, eth0 cannot be mapped reliably
<mjg59> infinity: gnome-screensaver ought to have the ability to DTRT itself
<infinity> mjg59: To be honest, I miss my lid button being a quick shortcut to "lock my console" :)
<mjg59> If it isn't, we should fix that
<infinity> mjg59: Ahh, well, whoever should be doing TRT, they're not.
<mjg59> (It really ought to have a "Lock screen on lid close" option)
<janimo> hmm the lid->lock screen works here (xscreensaver)
<infinity> mjg59: s/g-s-s/g-p-m/ you mean, then.
<mjg59> No
<mjg59> It's not a power management issue
<infinity> mjg59: Well, g-p-m has the close lid options in it.
<mjg59> It has options for the power management aspects of it
<infinity> mjg59: Which I have set to "do nothing", cause the other options (suspend and hibernate) are clearly not what I want.
<infinity> mjg59: I'd find it phenomenally unintuitive to have options to do stuff on lid closure in two different places... But whatever.
<mjg59> infinity: Hmm. I'd find the other way more unintuitive, I think
<infinity> Well, we're attacking from two different angles, I guess.  You're all about "locking the screen is a screensaver thing, so I should set it there", and I'm all about "I saw sometihng about closing the lid in the g-p-m properties, so that's where I should configure stuff that happens when I close the lid"
<ogra> mjg59, err, didt we agree to have a "lock only" option in g-p-m last week ? 
<ogra> *didnt
<mjg59> ogra: Did we?
<ogra> i think so ...
<mjg59> Oh, ok
<ogra> see my weekly dapper report
<infinity> (I also don't expect most users to know or care that locking a console is a screensaver function.. that's a UNIX oddity)
<mjg59> I think it seems odd to configure screen locking in a power management thing
<infinity> Locking a console is certainly not related to the screensaver in WinNT, for instance.
<ogra> but its confusing to have lid actions anywhere else
<mjg59> Hmm. Fair enough, then.
<infinity> So, either the whole thing moves to a "configure my special buttons" applet (so it's not tied to power management OR screensavers), or just leave it in g-p-m with a "Lock Screen" option...
<infinity> Or put it in both plages, with the same options.
<ogra> mjg59, https://launchpad.net/distros/ubuntu/+source/gnome-screensaver/+bug/29881
<Ubugtu> malone bug 29881 in gnome-screensaver "Closing the lid should lock the screen if locking is activated in gnome-screensaver" [Normal,Unconfirmed]  
<ogra> (see the initial reporter)
<infinity> Which was what Windows used to do with the monitor power problem.  It was in both screensaver and power management.
<ogra> :)
<janimo> mjg59, just in case you missed it /etc/acpi/hibernate.sh: line 27: echo: write error: No such device
<mjg59> janimo: Do you have a swap partition mounted?
<mjg59> (Check /proc/swaps)
<janimo> I see there is a /sys/power/state
<janimo> no swaps!
<janimo> hmm
<janimo> I wonder why my swap partition does not get activated
<Kinnison> ogra: since I'm going to start hacking on gnome-power-manager fairly soon, should I be looking into implementing the lock-only action?
<ogra> Kinnison, that would be great, since it would be a last minute thing before feature freeze next wee on my side ...
<janimo> mjg59, ok I see my swap partition somehow went away recently without me noticing it
<ogra> you just need to call gnome-screensaver.command --lock ...
<ogra> err
<ogra> gnome-screensaver-command
<ogra> as the lock icon in the desktop does ...
<ogra> should be trivial to implement
<Kinnison> does that turn the backlight off?
<infinity> On most laptops (mine included), hitting the hardware switch turns off the backlight anyway.
<mjg59> g-s-s should be turning the backlight off on lid close regardless
<ogra> it does if i use the locj button, so i guess yes
<janimo> Kinnison, will there be a show NEW queue status in LP?
<Kinnison> mjg59: which is g-s-s?
<mjg59> gnome-screensaver
<ogra> gnome-screensaver
<Kinnison> janimo: eventually
<Kinnison> right, noted
<mjg59> That's a "It should do this" rather than "It is meant to do this"
<mjg59> I have no idea if it does
<mjg59> If it doesn't, it should be fixed
<infinity> Also, /usr/share/acpi-support/screenblank is called on lid close, which should turn off the backlight for most people.
<infinity> mjg59: Or is that going away?
<mjg59> infinity: Yeah, but shouldn't be if you have some other policy manager running
<ogra> BenC, removing appletouch before suspend works, thanks for the hint ...
<ogra> mjg59, does powerpc have any common script to care for module removal ? (i added appletouch to the alsa script for testing for now)
<ogra> or do i need to write one ? 
<mjg59> ogra: This should all be part of pmi
<mjg59> (And some scripts should be migrated from acpi-support to there)
<ogra> ah, there is only alsa for now in /etc/apm/scripts.d ... having a dummy to add stuff manually would be cool ...
<ogra> i think i saw such a script on amd64 in the acpi scripts ...
<pitti> mvo: u-n still spins 100% cpu on the current live CD - which version was supposed to fix that?
<pitti> mvo: hmm, current live CD has the latest version 0.41.6
<pitti> mvo: still spins in the same read/write/poll=EAGAIN loop
<mvo> pitti: I uploaded a 0.41.7 but my hopes aren't that good
<pitti> mvo: this damn bug haunts you in your dreams, doesn't it?
<mvo> I'll do another debugging session later
<mvo> yes
<mvo> it's the suck
<mvo> I'll open a bottle of  champagne  when I have it
<pitti> mvo: revert to gamin?
<seb128> that's not due to gam
<pitti> mvo: hm, gam_server doesn't run on the current live session
<seb128> the loop is egg stuff and notify icon
<seb128> nothing due to gnomevfs or inotify
<seb128> pitti: why should it? we stopped using it...
<pitti> seb128: no, I mean, it would be a pity to reintroduce it just for u-n
<seb128> I agree with that :)
<seb128> and easier to debug u-n than to debug gam_server again imho
<pitti> ack
<pitti> mvo: can you reproduce it on the live CD?
<pitti> mvo: or reproduce it at all?
<mvo> pitti: I'm syncing the latest live cd now to test it
<mvo> pitti: otherwise I wasn't able to reproduce it, I sometimes get it when I kill the panel often enough
<mvo> but killing the panel has lots of other unpleasnt effects
<Alinux> pitti, hello pal :)
<pitti> hi Alinux 
<pitti> where did the "OS" go? :)
<Alinux> sudo apt-cache search georgian | grep bpg
<Alinux> ttf-bpg-georgian-fonts - BPG Georgian fonts
<Alinux> pitti, :)
<Alinux> hehe
<AlinuxOS> here I am :)
<AlinuxOS> great thing with fonts!! Super!
<pitti> hm, I don't have that package yet
<mjg59> infinity: Did we get support for having a separate file to declare the resume partition?
<AlinuxOS> mjg59, done :)
<Kinnison> mjg59: http://people.ubuntu.com/~dsilvers/gpm/
<AlinuxOS> done it :)
<Kinnison> ogra: ^^
<mjg59> infinity: Right now, anyone upgrading is likely to lose that information (and we're going to have to find some way to reconstruct it)
<Kinnison> mjg59: adds "lock" option to gpm
<Kinnison> ogra: ^^
<janimo> mvo any way to trigger the u-n cpu usage or just random?
<mjg59> Kinnison: Why poke?
<Kamion> mjg59: (could be sucked out of the conffile in the preinst)
<AlinuxOS> pitti, and maybe you link them like dependency for georgian gnome locales ?
<ogra> Kinnison, cool
<Kinnison> mjg59: so that when you open the lid again, the unlock dialog is there waiting
<mjg59> Kamion: Not for anyone who's already upgraded it can't
<mjg59> Kinnison: Poking it will turn on the backlight
<Kamion> mjg59: sure, I know, but I'm ultimately more concerned about release->release upgrades
<pitti> AlinuxOS: yes, at least; usually we want fonts in the default install, but that's a matter of size
<Kinnison> mjg59: Hmm, it doesn't on my laptop
<mjg59> Kamion: Sure, but it's the people who've been tracking who are going to bitch :)
<pitti> AlinuxOS: but adding them to l-s-ka is easy
<Kamion> and I don't think we *can* fix it well for people who've already upgraded
<Kinnison> mjg59: or else the laptop forces the backlight off when the lid is closed
<Kamion> we can note the issue in the release notes for the Flight CD release after we get the problem fixed
<mjg59> Kinnison: Either acpi-support is still switching off the backlight, or your hardware is doing so
<AlinuxOS> pitti, there ara only 275,3 KB
<Kinnison> mjg59: acpi-support almost certainly is
<Kinnison> mjg59: I'll look into it some more
<mjg59> Kinnison: It's likely to stop doing that soon
<AlinuxOS> I think it's not a problem...
<Kinnison> mjg59: Okay but lock on its own doesn't dpms off
<AlinuxOS> mdz, told me some days ago.
<Kinnison> mjg59: would it be reasonable to poke when lid opened?
<mjg59> Kinnison: g-p-m or g-s-s should turn the screen off on lid close
<mjg59> Kinnison: Yup, that's reasonable
<Kinnison> mjg59: I'll rework the patch
<mjg59> Kinnison: np
<ogra> Kinnison, poke me to test and upload if you like then ...
<mjg59> Kinnison: The downside of just having it as another setting on the "lid" action dropdown is that it means it doesn't interact with sleep/hibernate
<mjg59> Kinnison: So it probably ought to be calling it on those as well
<ogra> i thougth pmi does that anyway ?
<Kinnison> mjg59: gpm's sleep/hibernate already locks and pokes as appropriate
<mjg59> Kinnison: It does?
<Kinnison> yep
<mjg59> I don't always seem to see that
<ogra> Kinnison, i think that works only if youo have lock checked in the g-ss preferences
<Kinnison> ogra: aye
<ogra> try without the check ...
<mjg59> It probably should only do that if that's checked
<Kinnison> if lock is not enabled in gss, it won't try
<mjg59> But does it always blank the screen on suspend?
<mjg59> (and therefore lock it if locking is enabled)
<Kinnison> no
<ogra> yup, at least i see the fade if i open the lid
<Kinnison> it only locks if locking is on
<mjg59> Kinnison: That doesn't seem to disagree with what I said
<ogra> i'm pretty sure the screensaver is started on hibernate/suspend ...
<ogra> if lock is set, it behaves like wanted
<ogra> if not it doesnt lock ...
<mjg59> Kinnison: One thing - suspend should not proceed until the screen is blanked (if locking is enabled)
<mjg59> Kinnison: Otherwise on resume there's an opportunity for a glimpse of desktop before the screen is blanked
<Kinnison> mjg59: I have no idea if gpm_screensaver_lock returns before the blank phase is complete
<Kinnison> mjg59: hmm, dbus_g_proxy_call_no_reply doesn't sound like a blocking call to me
<mjg59> Kinnison: Right - that probably needs to be looked at, then
<ogra> let it sleep for some seconds ? 
<Kinnison> ogra: messy but possible
<ogra> just to be sure
<BenC> Mithrandir, Kamion: using mksquashfs 3.0 for filesystem.squashfs gets rid of the oops for me
<Kinnison> mjg59: can you file a bug on gnome-power-manager so it doesn't get forgotten?
<mjg59> Kinnison: Not right now (awkward network situation)
<mjg59> I'll try to do that later
* ogra yays at seb128  about gdm :)
<Kinnison> mjg59: ta
<seb128> ogra: that may change ...
<Kinnison> mjg59: btw, tonight, chinese @ norfolk st, then film. interested?
<ogra> seb128, oh, whats wrong ? 
<seb128> ogra: upstream move the gdm.conf to /usr/share, I'm thinking about what to do on update
<mjg59> Kinnison: Otherwise engaged, sadly
<seb128> so for now it's still to /etc
<ogra> seb128, feel free to move that for cdd as well, i rally dont care where its stored ...
<ogra> ... as long as the option is there ...
<seb128> k, I'll let you know
<Keybuk> Kamion: the scrollbar on a daily from last week is behaving a little oddly, it jumped from 6% to 34% after lots of work
<HiddenWolf> Keybuk: can you take a look at https://launchpad.net/malone/bugs/29789
<Ubugtu> malone bug 29789 in udev "tv card audio not working" [Normal,Needs info]  
<ogra> Keybuk, you dont happen to test edubuntu ? :P (ltsp chroot building has only 50 and 100% :) )
<Kinnison> mjg59: updated
<Kinnison> ogra: updated
* ogra grabs
<ogra> (greedy)
<Kinnison> ogra: Once I've worked out where the autocrud came from, I'd like an 
<Kinnison> sponsored upload
<ogra> oki
<Kinnison> if you have any idea what might have caused the autocrud I'd be grateful
<jsgotangco> good night
<ogra> Kinnison, likely some cdbs cruft ...
<Mez> Kinnison, still not a MOTU ?
<ogra> (i switched the package to cdbs with 0.3.4 to make it more convenient for seb128 if he takes it over :P )
<Keybuk> HiddenWolf: doesn't look like a bug
<Keybuk> looks like you need to blacklist bttv for your configuration to work
<HiddenWolf> Keybuk: where do I do that?
<Keybuk> add a "blacklist bttv" line to a file in /etc/modprobe.d
<Kinnison> ogra: updated
<Kinnison> Mez: I'm supposed to become core-dev
<ogra> still testbuilding here ...
<Kinnison> Mez: dunno when though
<Kinnison> mjg59: The 0ubuntu7 patched g-p-m does the lock and dpms correctly even if lid.sh is stubbed with "exit 0" at the top
<Kamion> Keybuk: er, which scrollbar?
<mjg59> Kinnison: Ok, sounds good
<mjg59> Kinnison: (Though how are you checking the dpms?)
<slomo_> infinity: please give-back ikvm on amd64, ftbfs should be fixed now with the new nant. thanks :)
<Kinnison> mjg59: looking carefully at my closed laptop, and reading g-p-m's output which certainly claims to be doing the dpms
<mjg59> Kinnison: Ok, sounds good
<Kinnison> the debdiff is now small and clean
<mjg59> Cool
<mjg59> What's the URL?
<Kinnison> people.ubuntu.com/~dsilvers/gpm
<mjg59> Kinnison: Want it uploading?
<Kinnison> mjg59: I believe ogra is looking at it right now
<mjg59> Ok
* Kinnison would like the TB to consider him for core-dev :-)
<Kinnison> but I'm guessing that's unlikely today
<ogra> Kinnison, mjg59 did also get approved in a extra meeting ... you would need mdz to have quorum ...
<HiddenWolf> Kinnison: just win enough hearts and minds. :)
<mjg59> Kinnison: Can you send that to upstream?
<ogra> HiddenWolf, it blocks his work to have no upload rights ...
<ogra> at least it slows down
<Kinnison> mjg59: what, the lock patch? sure
<Kinnison> mjg59: gnome bugzilla?
<ogra> Kinnison, hughsie is in #hal ...
<Keybuk> Kamion: installer
<Kinnison> okay I'll poke him there
<Keybuk> unpack/config/etc. phase
<ogra> Kinnison, he's upstream
<Kamion> Keybuk: dude, it has lots of progress bars
<Kamion> Keybuk: base-installer ("Installing the base system") or pkgsel ("Select and install software")?
<Kinnison> ogra: right
<Kamion> both of those match your description
<Keybuk> base-installer I think
<Kamion> a wodge of that progress bar is reserved for downloading packages, and it tends to jump past that on CD installs
<Kamion> debootstrap was probably in deep contemplation of the files on the CD or something
<Keybuk> I've so got to install bootchart on this thing :)
<Keybuk> a primitive "run date twice on another machine and hit enter" suggests it's 18s from grub to gdm
<Kinnison> ogra: he's not around, I'll file a bug in gnome bugzilla with the debdiff if you want to upload to dapper in the meantime
<ogra> i will, just finished the testbuild, lets see how it behaves
<Kinnison> cool
<ogra> hmm... it suspends on ibook
* ogra restarts to make sure nothing old is around
<Kinnison> rehi ogra_ibook 
<Kinnison> any luck?
<ogra> Kinnison, backlight goes definately off
<LinuxJones> There seems to be a problem with a package "libopenh323-1.15.3c2_1.15.6-1_i386.deb" while doing a clean install of ubuntu-desktop.
<ogra> (ibooks are great to test that ;) )
<ogra> but i think it should override the g-ss setting for locking, like the lock button in the menu does
<ogra> Kinnison, apart from that, its fine :)
<Kinnison> ogra: I think for now, it's better it honours the g-ss option
<mjg59> Possibly "Blank your screen" rather than "Lock screen"?
<Kinnison> mjg59: if you issue a lock instruction to g-ss when it doesn't have locking enabled, does it still do anything?
<mjg59> It should expose the phrase "lock" unless it unconditionally does so
<mjg59> Kinnison: Unsure. Hang on...
<mjg59> Ha
<mjg59> It doesn't run under Xgl
<mjg59> So I can't test right now
<Kinnison> heh
<Kinnison> I'll try, give me a sec
<ogra> hmm, it doesnt blank ...
<ogra> Kinnison, you should probably omit the poke if lock is not set ...
<ogra> (if it doent lock, the screen comes back immediately)
<Kinnison> ogra: that patch does just that
<ogra> the recent one ? 
<Kinnison> the most recent one yes
<ogra> ok ... i'm one behind here ...
<Kinnison> Can you try the latest?
<ogra> i'm on it
<Kinnison> cool
<sivang> mjg59: xgl debs are go? :)
* sivang -> back
<mjg59> sivang: Everything but the server
<mjg59> Which I'm test-building now
<sivang> mjg59: wheee :)
<mjg59> Needs a bit of debconf love
<sivang> mjg59: and I assume Kinnison is helping you out with that?
<mjg59> Nope
<Kinnison> sivang: I'm not doing anything directly with mjg59 right now
<Treenaks> mjg59: so I can impress my colleagues tomorrow? cool! you rock! :)
<ogra> sivang, Kinnison makes powermanagement ROCK for us
<sivang> ogra: ah, still, I was wondering if he already finished it and moved to the next task already :)
<sivang> Kinnison: heh
* Kinnison has been slow on the uptake
<ogra> sivang, its me who is lagging with the tests :) he's already done 
<sivang> ogra: hehe
<sivang> figures
<sivang> ogra: you're probably head over hills busy with edubuntu..
<sivang> guys, would you care to comment what to change / remove , split in this design for hub (please note this is incomplete, and the list view will get autoimatically filled on startup) - http://muse.19inch.net/~sivan/backup-ng.png
<sivang> some people already suggested splitting between backup and restore,
<sivang> and some logical re-arrangemtn for the button.s
<mjg59> sivang: The top isn't very HIGgy looking
<ogra> Kinnison, even with the new one it doesnt have the screensaver running if i open the lid :/
<sivang> mjg59: okay, are you conversant with the HIG? I actually wanted to specifically collect your comments :)
<mjg59> sivang: Heh. Not something I've actually looked at lately, but I can tell by the way it doesn't look like any other Gnome app :)
<mjg59> Yeah, I think backup/restore should be split
<Burgwork> sivang, calum might also be able to help you
* ogra wonders if a dbus restart is needed for the change to take effect
<sivang> Burgwork: calum ?
<Kinnison> ogra: It should only need you to kill/restat gnome-power-manager
<ogra> Kinnison, yes, thats what i thought, but it doesnt work as expected
<Kinnison> ogra: kill gnome-power-manager
<sivang> mjg59: cool, so it's you , mvo HiddenWolf and tseng already, basically I've followed mpt's original design but splitting seem to serve this better.
<Kinnison> ogra: run gnome-power-manager --no-daemon --verbose
<ogra> Kinnison, i did ...
<ogra> ah
<Kinnison> ogra: close the lid and reopen it
<Kinnison> ogra: nopaste me the log
<Burgwork> sivang, sun usability guy, on irc.gimp.net
<sivang> Burgwork: is he doing the same for GNOME stuff?
* sivang goes to look for him on gimpnet
<Burgwork> sivang, yes
<ogra> Kinnison, http://pastebin.com/554588
<Burgwork> sivang, #usability
<sivang> Burgwork: thanks
<ogra> Kinnison, i guess its the ThrottleEnabled: 0 in the end 
<ogra> it should stay at 1
<Kinnison> ogra: Is your g-ss set to permit locking?
<ogra> Kinnison, nope 
<Kinnison> ogra: aah the current patch won't lock then
<ogra> Kinnison, but it should at least save ...
<Kinnison> ogra: Give me a few minutes
<ogra> it locks fine with locking enabled ... what i mean is that it neither starts the screensaver 
<ogra> (after opening the lid)
<willy_> Ok guys libopenh323-1.15.3c2_1.15.6-1_i386.deb is borked and won't allow a successfull install of Gnome on Breezy !
<ogra> willy_, file a bug ..
<Kinnison> ogra: okay, one last time
<Kinnison> ogra: I will always call _lock regardless
<ogra> oki
<Kinnison> ogra: because you configured it to lock
<Kinnison> ogra: and I always poke on lid open because it's harmless if you're not locked anyway
<ogra> hmm...
<ogra> 7me twiddles thumbs ... wonders if he should have taken a powerbook with faster disk ...
<ogra> (and with a better shift key :) )
<Kinnison> heh
<dholbach> Kamion: I sent the current version of the patch to the gparted developer.
<Kamion> dholbach: -0ubuntu2?
<dholbach> yes
<Kamion> dholbach: I'm going to send him a mail, since he mailed me asking about it - I just wanted to get the work I did today sorted out
<Kinnison> ogra: I'm gonna go wash my hair ready to go out, hopefully you can have tested it before I get back
<Kamion> because it had a big impact on whether installer mode would actually work
<ogra> Kinnison, just installing
<dholbach> Kamion: yeah, I thought so, when I read the changelog :-)
<ogra> Kinnison, cool, ready for upload :)
<ogra> it DTRT
<Kamion> previously we just kind of had to hope that the user knew how to drive it, and that gparted wouldn't mind sitting around for a while during partman
<dholbach> argh, yse, i can imagine
<dholbach> Kamion: i really hope they integrate it, since the 0.2 release has changes we really want (http://sourceforge.net/project/shownotes.php?release_id=389304&group_id=115843) - but that means altering your patch as well
<Kinnison> ogra: fantastic, if you wouldn't mind doing the honours
<ogra> will upload (just adding a closes #29881 to the changelog)
<Kinnison> sure
<Kamion> dholbach: I understand the installer-mode.patch internals pretty well now, so if need be I can probably manage to forward-port it; but yes, I'll talk to upstream
<dholbach> Kamion: that's great! :-)
<Kamion> I'd like to do something other than partitioning for a while though; my head hurts ;)
<dholbach> Kamion: go out and enjoy the evening! :)
<Kamion> will be having a quiet evening in with Kirsten, I imagine
<dholbach> That's good as well.
<Kinnison> Kamion: come to the norfolk-st chinese for dinner?
<Kamion> we have Benedict so I suspect that won't work, unfortunately
<Kinnison> aah well
<Kamion> but thanks
<ogra> Kinnison, you are whitelisted already for uploads ? 
<Kinnison> ogra: I am not
<Kinnison> ogra: so you have to sign it
<Kamion> whitelist as in the e-mail whitelist
<ogra> oh, ... hmm then the Accepted mail will go nowhere 
<Kamion> assuming soyuz still does that
<Kinnison> it doesn't
<Kinnison> ogra: you'll get the mail 'cos you signed it
<Kamion> in that case it no longer matters :-)
<ogra> oh
<Kinnison> signer, changed-by and maintainer are all considered for mail
<Kinnison> if they're in the relevant team in LP, they're mailed
<ogra> it should go to the address in the changelog
<Kamion> Kinnison: could you adjust http://wiki.ubuntu.com/Uploads accordingly?
<ogra> ah
<Kamion> ogra: that would not be appropriate for syncs
<ogra> Kamion, nope, but thats how katie did it 
<Kinnison> Kamion: can you mail me to remind me? I have to leave in 2 minutes
<Kamion> ogra: not quite, no
<Kinnison> ogra: believe me, it's careful
<ogra> Kamion, for uploads, not syncs
<Kamion> ogra: the algorithm didn't care
<ogra> oh ... hmm
<Kamion> it mailed whichever of maintainer/changed-by was in the whitelist
<Kamion> the changelog was irrelevant except insofar as it produced a changed-by field in the .changes
<Kamion> Kinnison: will do
<ogra> thats what i meant ...
<ogra> (the changed-by field)
* Kinnison is off, mail me if there're issues
<ogra> EEEK
<Kinnison> ciau
<ogra> it was targeted to unstable 
<ogra> gah, i didnt check ...
<Kinnison> silly ogra
* Kinnison -> out
<Kamion> hmm, might need to tweak how gparted --installer does transient dialogs too
<Kamion> but not today
<dholbach> have a nice evening, Kamion :)
<ogra> Kinnison, that wasnt me who set it to this :P
<ogra> dholbach, woah, blender is a hell amount of changes ...
<ogra> i'll do a testbuild tomorrow and check if there are any drawbacks 
<dholbach> i test-built it already
<dholbach> builds nicely
<ogra> i mean test it, i assumed it builds :)
<dholbach> that's why i wrote my concerns in that mail as well
<ogra> it should also run fine (i usually grab a blender animation from their homepage and let it run in wireframe and solid mode ... if it survives it should be fine)
<sivang> mjg59: is there a way to find out the capacity of a blank CD/CDRW form hal?
<cfk> Kamion, every couple of days my preseed install breaks, like today it doesn't know where to install grub.  Should I report this?  guessing no, but need to confirm before my next Q...;)
<cfk> wait.. is Kamion the right person to ask?
<dholbach> cfk: i hope he takes a rest atm
<cfk> fair enough
<dholbach> cfk: and reporting might make sense
<Kamion> cfk: please do
<Kamion> (report)
<Kamion> yes, I'm the right person to ask
<Kamion> I'm not gone for the evening *yet*, but will be RSN
<cfk> k
<cfk> any idea how I can dump the VT1 screen to a file?
<ogra> cfk, i guess looking at the old base-config code (probably from breezy ?) should give you some hints
<ogra> since that did the typescript stuff
<Kamion> cfk: you can't
<Kamion> ogra: no, that's irrelevant
<cfk> rats
<ogra> ah, k
<Kamion> base-config is DEAD DEAD DEAD in dapper and that typescript stuff never mattered for stage 1 anyway
<Kamion> cfk: Mithrandir suggested catting /dev/fb0, I guess you could try that
<Kamion> (or whatever the filename is in the installer)
<Kamion> but I'm not entirely sure that'll work. some people use a physical camera ...
<ogra> or qemu and screenshots
<Kamion> ... if the bug manifests in qemu
<ogra> ...
<sivang> yes, it's not always that easy to test / reproduce in qemu
<sivang> I've heared vmware are offering free downloads of some of their client product..
<Kamion> yes, but you can't create new virtual machines in the vmware player
<Kamion> well, at least not within the terms of the EULA; it does happen to be possible by fiddling around a bit, I'm told
<Kamion> and vmware has the same problems as qemu with regard to reproducibility of bugs specific to particular hardware anyway
<Kamion> although in general it is somewhat easier to set up and use
<cfk> yeah - I'v done the camera, just trying to automate things with a script that makes a .tar out of anyting that might be usefull
<Kamion> to be honest I find attachments of individual files much easier
<Kamion> that way I can just click on them in malone - if I get a tarball I have to faff around downloading it
<cfk> I was affraid you were going to say that ;)
<Kamion> and IME I tend to put those bug reports off to a later date (not particularly deliberately, it just seems to happen that way)
<cfk> understood
<mjg59> sivang: Unsure
<sebest__> sjoerd: ping
<sivang> mjg59: already asked sjoerd , it seems volume.disc.capacity is never reported by I am checking this as we speak.
<sivang> sjoerd: yep, it's not working. maybe it's becasue I'm querying hal from python?
<sjoerd> sivang: doesn't matter
<sivang> sjoerd: volume size is also useless, it reports the size of the very small volume (probably factory placed) on a blank cd.
<sivang> oh well, guess I'm off to trying with other tools :)
<sebest__> sjoerd, do you receive my private messages?
<sjoerd> sebest__: nope apparently not 
<sebest__> sjoerd i think it because i didn't register yet
<cfk> cat /dev/fb0 and dd if=/dev/fb0 gave different results, but neither seem to have anything usefull
<sjoerd> sivang: the code is there in the hal to set it correctly, dunno why it's not there
<sivang> sjoerd: bug? :)
<sivang> sjoerd: I really need that informaiton for my spec implementation, can we fix it ?
<sjoerd> sivang: dunno, need to look into it
<sjoerd> sivang: could you file a bug on the debian package, then i'll look into it later this week
<sjoerd> hopefully that's fast enough for you ?
<Kamion> cfk: in any case, it's relatively rare that the contents of the screen are all that useful to me - I'd rather get a syslog of the installer running with DEBCONF_DEBUG=5
<Kamion> which is usually sufficient to tell me what's going on, and from my point of view somewhat more convenient
<cfk> k
<sivang> sjoerd: could be :)
<Kamion> cfk: of course that does require you to be able to run the installer with DEBCONF_DEBUG=5 from the start
<Kamion> (it works as a kernel boot parameter)
<cfk> ker.. good.
<sivang> sjoerd: would it be very hard and tedious to maybe guide me where to check, I might fix that on that way..:)
<mdke> Kamion, have you got a moment in the next few days or so to have a look at that email for the WikiLicensing spec?
<sivang> sjoerd: I can also alwasy peopen to cdrdao and get that info there :)
<sjoerd> sivang: the code is in hal/hald/linux2/probing/probe-volume.c , you could add some printf stuff there to see what goes wrong
<sivang> sjoerd: thanks, I'll take a look there.
<Kamion> mdke: ok, will try to get to it tomorrow
<mdke> Kamion, yay thanks
<Mithrandir> BenC: coolie; we might want to ask for an UVF exception for new squashfs-utils, then.
<sivang> sjoerd: the source pakcage (dapper) misses the run-hakd.sh and debug-hald.sh files, can I then just fire up ./hald from .../hald dir in the src pkg? 
<Kamion> mjg59: if you're cancelling TB tonight, could you tell the #ubuntu-meeting topic, please?
<Kamion> mjg59: and https://wiki.ubuntu.com/TechnicalBoardAgenda
<mjg59> Kamion: I still haven't heard from mdz, but I'm guessing so
<Kamion> mdz's around on #canonical now
<Kamion> er, no, #launchpad
<mdz> I'm around
<mdz> and will be attending
<mjg59> mdz: Ok, so we're going ahead?
<mdz> assuming we have a quorum
<mjg59> I'll be there
<mdz> Keybuk is essentially offline
<mjg59> Keybuk offered apologies earlier
<mdz> I'll ping sabdfl
<mdz> but the two of us should be enough to do the usual business
<sjoerd> sivang: you should have a helper script in the debian dir of hal
<mdz> Kinnison: ping (tech board)
<cfk> Kamion, is this the right place to report preseed issues?  (im attaching the preseed and syslog now)
<cfk> https://launchpad.net/distros/ubuntu/+source/preseed/+bug/31432
<Ubugtu> malone bug 31432 in preseed "timezone/hardware clock are not being set" [Normal,Unconfirmed]  
<cfk> neat
<sivang> sjoerd: I have run-hald there, I'll make it executable, but does it use binaries compiled inside built-tree/. ?
<sjoerd> sivang: iirc it does
<sivang> sjoerd: hmm, it's missing a user id (haldaemon) 
<mjg59> sivang: It should use hal under Debian, not haldaemon
<sjoerd> yup, just run configure with the same arguments as the rules file does and you'll be fine :)
<sivang> mjg59, sjoerd : ah :)
<ogra> mdz, ping
<sivang> sjoerd: btw, why isn't there the debug-hald.sh script? 
<sivang> (in the deb)
<mdz> ogra: TB is starting
<sjoerd> upstream doesn't ship it in the tarball
<sivang> sjoerd: ah, so hald by default runs in verbose mode? will I be able to track it's probing etc?
<ogra> mdz, i know ... just wanted to notify you that the debian guys sceduled a meeting in #ltsp on thursday 18:00 utc
<sjoerd> sivang: if you run it with --daemon=no --verbose=yes it does, but there aren't much debug statements in the volume probing part
<ogra> mdz, we are invited to attend ...
<sivang> sjoerd: so there would my printouts come , hopefully :)
<gouchi> Hi
<gouchi> sorry ask this
<gouchi> will dapper have graphic grub ?
<gouchi> I didn't find on Dapper Goals
<Kamion> cfk: as good as any, I guess
<Kamion> cfk: the debian-installer package is a good catch-all for installer issues
<shaya> mjg59: you here?
<shaya> newest update to glitz cvs provides all the fixes fglrx needs
<mjg59> shaya: Thanks
<shaya> basically previous fix, forces glx version to 1.3 if vendor is ATI, current version forces pbuffer and fbo's if glx version is 1.3 it seems
<shaya> mjg59: if you want to have some fun, rdesktop to a windows box, while running compiz
<shaya> you'll have transparent windows :)
<mjg59> shaya: Woo
<Treenaks> so I can try xserver-glx now ? :)
<shaya> http://www1.cs.columbia.edu/~spotter/screenshot.png
<Treenaks> shaya: (any HOWTOs on this?)
<shaya> I just built it by hand
<shaya> wait for mjg59's debs
<shaya> they are getting close
<cfk> Kamion, syslog is 4meg, so won't fit on a floppy - will tail -n 500 /var/log/syslog be enough?
<sivang> sjoerd: can't find anywhere on that file mention of "capacity" , but I can see other namespaces
<sjoerd> sivang: probably nog in the logs, you'll need to add some extra debug info for that
<sistpoty> elmo: please sync smilutils (0.3.0-8) from unstable, no ubuntu sepcific changes present. thx.
<sistpoty> elmo: please sync nco (2.9.9-2) from unstable, no ubuntu specific changes present. thx.
<mdz> ogra: what sort of meeting?
<ogra> mdz, the alioth pkg-ltsp team and future collaboration of development with ubuntu
<sivang> sjoerd: but surely the string bit that create the namespace for disc.capacity should be there , *somewhere*, or am I missing something?
<ogra> i'll be attending anyway, even if its my bday :P 
<mdz> ogra: I might be able to attend
<sivang> mjg59, mdz : There is currently an upstream fix for probing disc.capacity from hal, can we make this a patch to the dapper package? It will be nice to have it for HomeUserBackup and not have to peopen some external tool to probe disc capacity
<mjg59> sivang: Sure. Talk to pitti?
<mdz> sivang: talk to pitti, he is knowledgeable about hal
<seb128> I think pitti was considering asking an uvf exception for the new hal
<seb128> it would benefit to GNOME and fix some other stuff too
<sivang> mdz, mjg59 : sure, thanks will do.
<sebest> would it be possible to make grub (and the kernel) to really be quite
<sebest> not display anything between the grub countdown and the usplash
<sebest> ?
<zul> sebest: im working on it
<sebest> zul: ah great, does it need to modify the kernel?
<sebest> or only grub?
<zul> grub
<sebest> no more "uncompressing linux kernel"?
<zul> thats something else...
<sebest> it's built in the kernel uncompressing routines i guess
<Kamion> cfk: syslog should compress well, and you have gzip available
<carl> now you tell me
<Kamion> oh, no, you don't, whoops
<Kamion> last 500 lines would often be better than nothing, but it depends on the bug
<carl> ill see if I can figure out how to scp it to the box I post from
<Kamion> 'anna-install openssh-client-udeb', if you don't know that bit already
<carl> shouldn't you have gone to sleep about 12 hours ago? ;)
<Kamion> no, I'm on UTC ...
<Kamion> (that's my native timezone, even, not just an adopted one)
<carl> I am runnign out the door, so heres a quick fly by bug report:   the "early command" preseed thing stopped working too
<carl> know anything about that?
<Kamion> no, preseed/early_command should still work, although anything base-config-ish will no longer work
<Kamion> (including base-config/early_command, that's gone)
<carl> so no "apt-get install openssh-server"
<carl> ah... I was using base-config
<Kamion> you can do that in preseed/late_command, if you prefix it with chroot /target
<Kamion> or you can just preseed pkgsel/install-pattern
<Kamion> d-i pkgsel/install-pattern string ~t^ubuntu-standard$|~t^ubuntu-desktop$|~n^openssh-server$
<Kamion> the requirement to use aptitude syntax is a bit awkward, but you get everything else handled for you that way
<carl> neat
<mjg59> Treenaks: One thing that suddenly springs to mind - is radeonfb able to set your screen mode correctly?
<carl> when whill that take effect?
<carl> as in, how soon can I scp from another host
<carl> ride is here...
<carl> see ya
<Kamion> carl: immediately
<Kamion> but you can only scp to another host, not from another host - you'd need to fiddle with openssh-server-udeb and some extensive configuration to make the latter work, and I wouldn't recommend bothering
<sistpoty> elmo: please sync childsplay-alphabet-sounds-ca from unstable, which is not yet in dapper
<sistpoty> elmo: please sync childsplay-alphabet-sounds-de from unstable, which is not yet in dapper
<sistpoty> elmo: please sync childsplay-alphabet-sounds-es from unstable, which is not yet in dapper
<sistpoty> elmo: please sync childsplay-alphabet-sounds-fr from unstable, which is not yet in dapper
<sistpoty> elmo: please sync childsplay-alphabet-sounds-it from unstable, which is not yet in dapper
<sistpoty> elmo: please sync childsplay-alphabet-sounds-nl from unstable, which is not yet in dapper
<sistpoty> (only 3 more *g*)
<sistpoty> elmo: please sync childsplay-alphabet-sounds-pt from unstable, which is not yet in dapper
<sistpoty> elmo: please sync childsplay-alphabet-sounds-ru from unstable, which is not yet in dapper
<sistpoty> elmo: please sync childsplay-alphabet-sounds-sv from unstable, which is not yet in dapper... thx!
<ogra> sistpoty, did you think about this invention called email ? 
<ogra> :)
<sistpoty> ogra: sorry for spamming... next time I got a bunch of syncs, I'll do it by email ;)
<LaserJock> maybe we need an ubuntu-elmo ML ;-)
<ogra> sistpoty, its more likely to get his attention :)
<sistpoty> :)
<ogra> (i dont care about the spam)
<slomo_> he doesn't do syncs currently anyway
<sistpoty> maybe I should have written childsplay-alphabet-sounds-*
<ogra> slomo_, and he wont forget them if you mail ... irc is easily lost ...
<slomo_> ogra: yes... that's why i mail them now instead of saying it here ;)
<ogra> yup ...
<ogra> :)
<mjg59> Treenaks: Uh. Have you actually built this driver under Ubuntu?
<dholbach> good night
#ubuntu-devel 2007-02-12
<shaya> is this a bug, that O_DIRECT does not seem to be defined in sys/types.h sys/stat.h or fcntl.h
<oslo> i manage to use my acx chipset with feisty !!!!!!!
<blanky> what's up
<Mez> infinity, ping regarding sponsored upload to debian for unrar to fix new "grave" bug
<alephant> #ubuntu refuses to get this deep into .deb rebuilding :-(  Anybody able to /chat about howto rebuild kernel .deb from apt-get source linux-image-* ?
* alephant realizes he is off-topic, but begs for mercy
<Fujitsu> alephant, you may have slightly better luck in #ubuntu-motu
<alephant> Thanks a ton.  The /topic made me chuckle.
<infinity> Mez: This probably isn't the best channel to be pinging me about Debian sponsorship. :)
<Mez> infinity, lol - nvm now anyways :D got my other sponsor on the ... blower
<Mez> pitti: ping
<Mez> pitti isnt here
<Mez> grr ;) 
<Mez> whats the -security process for ubuntu these days ?
<Fujitsu> Hey infinity, haven't seen you around in a while.
<infinity> Fujitsu: Been avoiding random prattle on IRC, s'all.
<infinity> Mez: Pretty much the same as it always was.
<Mez> infinity, I've never gone through that process :P where can i find info ? :P
<infinity> Mez: Is this for a universe security update?
<Mez> infinity, multiverse
<jdong> is a DNS lookup time of 7ms fast or slow?
<jdong> what should I typically expect?
* jdong wonders if he should be OpenDNS'ing
<jdong> infinity: can you do that magical rebuild give-back thingie on gpac?
<jdong> (it seems like ia64 xulrunner is installable again
<infinity> Mez: Should be more or less the same process for anything.  You'll want to talk to pitti or kees to get approval for the upload (and to let us know that it's on its way), then they can inform you of where you're uploading to.
<infinity> Mez: In theory, I can do the approval too, but I trust pitti and kees to make the time to properly go over your upload (and walk you through the process), while I don't trust myself to do anything outside of what I'm currently doing.
<Mez> infinity, lol... Well it's a security update for a CVE (which was just posted in debian, and I'm working on doing the seurity updates for that!)
<Mez> keescook, you around (scrollback)
<fabbione> morning
<Fujitsu> Hi fabbione.
<keescook> hiya Mez.  cool, yeah, saw that update go by on #debian-security, but I haven't had a chance to look at it yet.  If you've got a tested debdiff for it, I can easily get it built and uploaded.
<keescook> thought pitti will be awake before me, I'm about to go to bed.
<keescook> Mez: also, do you have a reproducer I can test with?  (if so, just email me directly)
<dilinger> apeirophobia -     A fear of infinity
<fabbione> dilinger: !
<dilinger> fabbione: hiya :)
<fabbione> dilinger: sup dude?
<fabbione> keescook: night man :)
<dilinger> not much.  just was looking through http://www.islandnet.com/~egbird/dict/a.htm
<keescook> g'night fabbione
<dilinger> and figured infinity should know that there's a proper word to describe the fear of him
<dilinger> if he didn't already
<dilinger> fabbione: how's life?  you back to work?
<fabbione> dilinger: i didn't stop for a while actually :) only had a short break for Xmas, but i am heading off for vacation next week
<infinity> dilinger: Cute.
<dilinger> infinity: aw shucks, thanks.  you're not my type, though.
<infinity> dilinger: That's not what you were screaming in that hotel room in Sydney...
<dilinger> you promised never to speak of that night
<elkbuntu> rofl
<fabbione> aha
<fabbione> infinity: feel like processing bug #81598 ? (missing to accept into updates)
<Ubugtu> Malone bug 81598 in lvm2 "[SRU]  lvm2 check if device is md is broken on big endian machines" [High,Fix committed]  https://launchpad.net/bugs/81598
<infinity> I'd be thrilled.
<fabbione> infinity: i would love your processing :)
<infinity> That sounds filthy.
<fabbione> infinity: i know you love when i talk dirty to you ;)
<kylem> heh. dilinger is here. hooray.
<infinity> fabbione: Processed.
<fabbione> infinity: danke
<pitti> Good morning
<dholbach> good morning
<fabbione> hey dholbach 
<Hobbsee> hey dholbach, fabbione!
<dholbach> hey fabbione
<fabbione> hi Hobbsee 
<Hobbsee>  /nick DrownedWaterRat
* pitti hugs Hobbsee
* Hobbsee hugs pitti :)
<Hobbsee> hey pitti :)
<tfheen> morning Daniel, Fabio, Sarah, Martin
* tfheen yawns.
<tepsipakki> morning all!
<Hobbsee> hey tfheen!
* Hobbsee drops icecubes down tfheen's back
<Hobbsee> hey tepsipakki :)
<Hobbsee> tepsipakki: that X patch got into the feisty archives :)
<Hobbsee> tepsipakki: my machine hasnt crashed today :)
<tepsipakki> Hobbsee: yes I saw that. It isn't in 7.2 so they fixed it in some other way (seems that the first chunk of that patch _is_ applied)
<Hobbsee> tepsipakki: right.  cool
<mdke> fabbione: got a moment?
<fabbione> mdke: yes
<mdke> fabbione: cool. you're the right person to ask about server related things?
<fabbione> mdke: it depends what you need to know
<mdke> fabbione: ok, I'll try
<mdke> fabbione: the docteam prepares a server guide (preview is here - http://doc.ubuntu.com/ubuntu/serverguide/C/index.html), much of which is shipped in ubuntu-docs for desktop users. I wanted to know whether you'd be interested in us making a standalone package which might be seeded in the server install
<mdke> I sent an email to -server a few weeks back but it never got moderated
<fabbione> mdke: up to the docteam.. it makes no diff to me
<fabbione> mdke: i am ok with whatever decision you take
<mdke> fabbione: we'd like to
<fabbione> mdke: ok.. go ahead and do it then..
<mdke> fabbione: we'll try and do a binary like ubuntu-serverguide from the ubuntu-docs source, if that makes sense to you
<fabbione> mdke: sounds fine to me
<mdke> great, thanks. I'll let you know when it's done
<jsgotangco> mdke: have it on html instead of source?
<fabbione> mdke: once you are done, just find somebody to seed it
<mdke> jsgotangco: html yes
<mdke> fabbione: great
<mdke> maybe txt too
<jsgotangco> man page?
<jsgotangco> cool
<pitti> mjg59: I imported your hal change to the bzr repo; please use that for uploading
<dholbach> somehow my 2nd port on the kvm is unhappy and keeps repeating certain keyboard/mouse signals for some reason: [ 8101.304614]  psmouse.c: bad data from KBC - timeout
<dholbach> and this is the 2nd kvm i'm unhappy with
<dholbach> does somebody have similar experiences and knows how to 'fix it'?
<fabbione> dholbach: buy a better kvm :((
<dholbach> this wasn't a cheap one
<dholbach> oh well
<dholbach> since my amd64 broke on saturday, I might as well unplug the kvm for now :-(
<fabbione> dholbach: i did try several.. i had to wait for a really expensive one to be donated
<dholbach> i hate hardware
<fabbione> unfortunatly it's a sad truth
* dholbach goes to buy a new amd64 today
<tepsipakki> amd dropped prices right on time, then ;)
<dholbach> still it was a depressing saturday
<dholbach> first I get strange     ? ??   ??  ???   owner/permissions on files, then decide to backup and buy a new disk, add the new disk and the damned piece of hardware doesn't start anymore
<popey> isnt there *still* a kernel bug with respect to kvm switch boxes?
<popey> which stops switching working, loses mouse etc
<popey> that aside, can anyone tell me where the changelogs that you see in update manager are kept? i.e. if someone wants to read those after they have upgraded, to see what was upgraded by reading all those change logs (and thus learn what new features/fixes are in) can they do that using a standard text editor?
<Hobbsee> popey: changelogs.ubuntu.com
<mvo> dholbach: my kvm is from "aten" and works quite well
<mvo> popey: synaptic has a feature to download the changelogs for you (aptitude as well) - otherwise what Hobbsee said
<rawler> heya
<popey> for packages that have already been installed?
<popey> i.e. after the upgrade
<rawler> eric3 seems to be broken in Feisty
<tepsipakki> popey: /usr/share/doc/*/changelog.Debian.gz
<rawler> or maybe it's the python-qt-bindings..
<Hobbsee> rawler: ho'ws it broken?
<Hobbsee> eric3 doesnt exist in feisty
<rawler> I get unresolved symbols when i try to start it..
<popey> thanks tepsipakki mvo, Hobbsee 
<rawler> huh? doesn't exist?
<TuxCrafte1> hello, i have a question I have a VIA EN12000E motherboard with xubuntu 6.10. The system is unstable when I start a program sometimes the everything total freezes and I need to press the reset button. I have been trying to debug this problem but with no succes. I need help. with a total checklist how to debug my problem.
<Hobbsee> TuxCrafte1: support is in #ubuntu
<rawler> well, it's the "eric"-package, but entering a channel saying "eric is broken" might easily be misunderstood.. ;)
<TuxCrafte1> Hobbsee: this is the devel chanel correct? I have a devel question
<Hobbsee> rawler: ah.  see if there's a bug in debian.  also, see #ubuntu+1
<Hobbsee> TuxCrafte1: it is, yes
<rawler> Hobsee: *ahh* thanks.. :)
<Hobbsee> rawler: tab completion is your friend, btw.
<Hobbsee> rawler: we sync that straight from debian
<Hobbsee> !debug
<Hobbsee> TuxCrafte1: try [20:11]  <ubotu> For help debugging your program, please see https://wiki.ubuntu.com/DebuggingProcedures
<tfheen> rawler: unresolved symbols such as?
<rawler> ImportError: /usr/lib/python2.5/site-packages/qtcanvas.so: undefined symbol: PenE4QPen
<rawler> /usr/bin/python: symbol lookup error: /usr/lib/kde3/plugins/styles/light.so: undefined symbol: _ZN18QMetaObjectCleanUpD1Ev
<TuxCrafte1> Hobbsee: I need some more help. I am pretty familiar with debugging. But can't find any logs of the froze system problem
<rawler> tfheen, Hobbsee, might of course be something broken in my setup as well, but I can't really see what..
<tfheen> rawler: hmm, it wasn't what I thought it was, at least.
<rawler> oh, what did you think? The QSize-problem?
<tfheen> no; there's a bug in python somewhere which causes python 2.4 to try to import 2.5 modules
<Fujitsu> tfheen: Would that cause API version warnings?
<rawler> tfheen: interesting anything I can do to debug?
<tfheen> Fujitsu: it can cause unresolved symbols at least.
<Fujitsu> 'causes I was packaging a python module a couple of days back, and it appeared that 2.4 was loading the 2.5 modules (judging by the API version warning). I presumed it was my fault somehow.
<tfheen> rawler: it seems to start for me at least; which architecture are you on?
<rawler> x86
<tfheen> rawler: amd64 here, so it might be specific to i386 then.
<TuxCrafte1> Hobbsee: I run these log systems klogd bootlogd sysklogd are there some more I can use to try to find the program?
<rawler> one interesting observation; installing the python-kde bindings removed the second undefined symbol-part, but instead gave me a segfault..
<rawler> tfheen: ^^
<rawler> tfheen: well, actually it's a amd64 host, but running 386 ubuntu, if that helps..
<tfheen> rawler: doesn't help, no.
<Fujitsu> Starts for me on i386.
<TuxCrafte1> pci=routeirq what is the function of this boot option
<Fujitsu> TuxCrafte1: This isn't a support channel.
<TuxCrafte1> Fujitsu: sorry but they do not now the answer on #ubuntu and #ubunt-bugs
<Treenaks> TuxCrafte1: that doesn't make this channel a support channel
<rawler> tfheen: do you have python-kde installed?
<TuxCrafte1> Treenaks: thats true i am sorry 
<Fujitsu> TuxCrafte1: I must concur with Treenaks.
<TuxCrafte1> bye
<tfheen> rawler: no.
<rawler> hehe, this is funny.. "sudo apt-get remove python-qt && sudo apt-get install eric" did the trick..
<rawler> spooky
<tfheen> rawler: something which was slightly wedged on your system, then. :-/
<rawler> I wonder why.. I certainly have not been fiddling with those files, I installed eric to start learning Python.. :D
<rawler> well, well.. not all is rotten in the state of denmark.. :)
<mjg59> pitti: Oh, crap, sorry
<pitti> mjg59: no worries, I just wanted to point out the bzr
<doko> pitti: libwps ping
<pitti> doko: hi
<doko> pitti: needs to be approved for main
<pitti> doko: as I said, the source package is an utter mess, I'll dig through it
<doko> pitti: hmm, didn't you want to mark this as "later"?
<pitti> erm, 'mark later'?
* pitti reviews now
<pitti> hey heno
<heno> hey pitti
<pitti> doko: do you have some testing feedback for this lib?
<Mez> omfg... why do closed source people have to be so confusing
<Treenaks> Mez: ?
<Mez> damned rar CVE
<doko> pitti: the OOo build succeeds, the libwps tests succeeds, but I don't have a works document.
* Hobbsee is still amazed that her machine hasnt crashed yet today...
<Hobbsee> tepsipakki: that fix sure works!
<pitti> doko: but at least .odt -> .wps -> .odt works?
<doko> pitti: if this works, this doesn't use the new libwps, but the old binfilter; for libwps only an import filter is added
<Mez> are there any buildd admins here?
<Mez> if so, can someone poke rar to build for amd64, it builds under that now
<tkamppeter> I have the feeling that something is not correct with the building and archiving servers
<tkamppeter> 1. "apt-get update" did not load anything new fo three days
<seb128> what mirror are you using?
<tkamppeter> 2. For all these three days the mirror fr.ubuntu.com is missin some Python packages ("apt-get dist-upgrade" fails on that)
<Fujitsu> That's simply a problem with the fr mirror.
<seb128> tkamppeter: change mirror
<tkamppeter> 3. foomatic-db-20070207-0ubuntu2 was uploaded and never reached the server (https://launchpad.net/ubuntu/+source/foomatic-db), same for last foomatic-db-hpijs
<tkamppeter> seb128, will change it, seems that the french guys have given up maintaining it.
<pitti> doko: hm, I goggled a bit, couldn't find a demo .wps either
<pitti> I wonder whether there is someone on a Windows box where we could grab a .wps
<pitti> hi tkamppeter 
<tkamppeter> hi pitti
<tkamppeter> seb128, thanks, the spanish mirror (es.) updated my system without problems.
<seb128> tkamppeter: np
<tfheen> BenC: if you want the new kernel in for herd 4, please upload new -meta ASAP.
<seb128> could we get apport fixed for herd4?
<tfheen> sure, we're not frozen until tomorrow.
<seb128> good ;)
* cjwatson evilly wonders if he can sneak man-db 2.4.4 past UVF
<tfheen> cjwatson: any interesting changes we want?
<cjwatson> bug fixes, but I'm mostly kidding, the majority of it is in our package already
<tkamppeter> pitti, doko, what is the state of the upload of the last foomatic-db and foomatic-db-hpijs packages?
<pochu> hey guys, do you know why the .20-7-generic-386 kernel is not in the repos, but it has built fine?
<pochu> build log: https://launchpad.net/+builds/+build/300654
<tfheen> pochu: I just accepted it.
<tfheen> it was in binary new,
<pochu> tfheen: ok, thanks :) then we should just wait a little, right?
<pitti> tkamppeter: not sure, it's not in the archive yet?
<Hobbsee> pochu: yep
<doko> tkamppeter: foomatic-db was uploaded by pitti, will do foomatic-db-hpijs today
<tfheen> pochu: correct.  It'll be published in an hour or so.
<pochu> well, ty :)
<Mez> tfheen, any reason rar hasnt hit the archive, but unrar has ?
<tfheen> Mez: which version, which suite, which pocket?
<Mez> https://launchpad.net/ubuntu/feisty/+source/rar/1:3.7b1-0ubuntu11
<Mez> so 1:3.7b1-0ubuntu11, feisty, multiverse
<tfheen>        rar | 1:3.7b1-0ubuntu11 | feisty/multiverse | source, i386
<tfheen> seems to be there?
<Mez> tfheen, weird, I just did an update, and it#s pulling unrar, but not rar
<Mez> possibly a mirror issue then ?
<Mez> (though it's using archive.ubuntu.com)
<Hobbsee> tfheen: what are you using to generate that output, btw?
<tfheen> Hobbsee: madison-lite
<cjwatson> Mez: your sources.list could be incorrect
<Mez> cjwatson, then why would it be pulling the new unrar version, which is in the same place ?
<cjwatson> Hobbsee: ^-- it's a package in the archive, but you need to be running it on a system with at least a mirror of dists/
<cjwatson> Mez: *shrug* no idea
<Hobbsee> cjwatson: right
<cjwatson> Mez: unless you're on non-i386
* Mez just figured it out
<tfheen> Mez: http://archive.ubuntu.com/ubuntu/pool/multiverse/r/rar/ certainly has the binary.
<cjwatson> rar's only available on i386, unrar's there for other architectures too
<Mez> I dont have rar installed
<cjwatson> Hobbsee: output of apt-cache madison is similar, I believe
<Hobbsee> cjwatson: yes, it's similar.
<Hobbsee> cjwatson: doesnt tell me which arches it's on, etc
<Mez> cjwatson, rar *should* be available on amd64 too... but it's not being built on that arch for some reason
* Hobbsee uses that most of the time
<cjwatson> right, it can't because it's only looking at your apt cache
<cjwatson> rar: i386                                                            # shareware for i386 only
<Mez> cjwatson, ok, so that needs updating, but we got it to build and run on amd64
<cjwatson> Mez: mail elmo, lamont, and/or infinity if Packages-arch-specific needs to be changed
<Mez> Package: rar
<Mez> Architecture: i386 amd64
<pitti> Mez: unrar exists on amd64 (and is usually enough :) )
<tkamppeter> pitti, foomatic-db really did not hit the archive yet, I checked on https://launchpad.net/ubuntu/+source/foomatic-db, should be 0ubuntu2
<Mez> pitti, :P
<tfheen> mez: soyuz (and sbuild) doesn't care about what the arch says.
<tfheen> that is, the arch field in the source package.
<Mez> tfheen, yeah, It's p-a-s
<Mez> I did look at getting it updated in debian but that doesnt make any difference as they're not built in non-free anyways
<Mez> cjwatson, would it be easier for me to email launchpad-buildd-admins@lists.ubuntu.com
<cjwatson> Mez: no
<cjwatson> Mez: I'm quoting the instructions at the top of the file.
<cjwatson> Mez: you should get it updated in Debian since our P-a-s is precisely in sync with Debian's
<cjwatson> also it's possible to get Debian non-free autobuilt; there was an announcement on debian-devel-announce a while back, IIRC
<cjwatson> it's on a case-by-case basis
<Mez> cjwatson, yes, I remember that - but that doesnt use P-a-s does it ?
<cjwatson> er, it's orthogonal to P-a-s
<Mez> cjwatson, I believe you're referring to http://lists.debian.org/debian-devel-announce/2006/11/msg00012.html ?
<Mez> cjwatson, orthogonal ?
<Mez> so, yes, I was right
<pitti> hey hey Keybuk 
<Keybuk> heyhey
<Mez> I never actually got any reply about that yet though
<cjwatson> Mez: independent
<Mez> cjwatson, as I said, I was right ;) :P
<cjwatson> to be more precise, I don't know whether the non-free autobuilders use P-a-s or not, but that's totally irrelevant
<cjwatson> in order to get it built in Ubuntu, you must get P-a-s updated. Or you could just continue to focus on irrelevant details I suppose ...
<infinity> Mez: For future reference, when emailing us about P-a-s, please use the addresses from that file, as it's not an Ubuntu/Canonical resource.
<infinity> Mez: Makes little difference for me, but for elmo or lamont, you may have landed in a mailbox they didn't want it in. :)
<Mez> infinity, I dont know where the file is... I just got
<infinity> http://cvs.debian.org/srcdep/Packages-arch-specific?rev=1.673&root=dak&view=markup
<infinity> ^--- It's there.
<Mez> <cjwatson> Mez: mail elmo, lamont, and/or infinity if Packages-arch-specific needs to be changed
<Mez> <cjwatson> Mez: I'm quoting the instructions at the top of the file.
<elkbuntu> ogra ping? see PM
<Mez> infinity, apologies :D
<Mez> but cheers for the change
<tfheen> Riddell: https://bugs.launchpad.net/ubuntu/+source/adept/+bug/82651 ; any chance you could get this fixed?
<Ubugtu> Malone bug 82651 in adept "File overwrite problem" [High,Confirmed]  
<tfheen> it should be trivial
* Hobbsee thoguth that got fixed.  twice.  maybe not...
<tfheen> maybe it's fixed and the bug is just not closed.
<tfheen> mvo: https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/70683 should be marked as fix released, shouldn't it?
<Ubugtu> Malone bug 70683 in update-manager "Upgrader needs better free-space checking for /boot " [High,Fix committed]  
<mvo> tfheen: yes, thanks!
<Hobbsee> tfheen: i think it's fixed, i cant reproduce it (on ubuntu14)
<geser> doko: could you look at the debdiff in bug #69967 and upload it if it's OK?
<Ubugtu> Malone bug 69967 in python-pam "python-pam contains NO PYTHON!" [Undecided,Confirmed]  https://launchpad.net/bugs/69967
<tfheen> Hobbsee: please close the bug, then
<Hobbsee> tfheen: just did :)
<tfheen> thanks
<pitti> $ gnome-default-applications-properties 
<pitti> GLib-ERROR **: gmem.c:135: failed to allocate 18446744073699154385 bytes
<pitti> aborting...
<pitti> seb128: ^ I don't have *that* much memory :/
<seb128> lol
<Hobbsee> pitti: THEN GET MORE MEMORY!!!
<Treenaks> BUY MORE
<Hobbsee> simple solution, really!  :D
<seb128> pitti: can you get a valgrind log?
<pitti> Hobbsee: I have 3 GB, that ought to be enough
<StevenK> That's only 18 Exabytes
<tfheen> works fine on amd64, must be an i386 problem. :-P
<pitti> tfheen: as you can see on the size_t value, this is an amd64 :)
<tfheen> hm.
<pitti> seb128: switch to 'user defined' browser, and wait two seconds
<seb128> pitti: WFM
<seb128> pitti: what text do you write to the entry?
<pitti> seb128: hm, I dist-upgraded, I should maybe restart
<pitti> seb128: this works for me:
<pitti> seb128: start app, switch to 'user defined', empty command, click on 'user defined'
<tfheen> indeed
<seb128> pitti: ok, same here
<seb128> please open a bug ;)
<pitti> seb128: I'll file a bug if you want
<pitti> heh, snap
<pitti> seb128: oui, Monsieur
<seb128> ;)
* seb128 hugs pitti
<Riddell> tfheen: doing
<tfheen> Riddell: Hobbsee said it was fixed already, though
<Hobbsee> well, i cant seem to reproduce it here
<Hobbsee> and i bugged manchicken about it during one of his recent uploads of it, so i think it got done.
<Riddell> tfheen: doesn't seem to be
<Hobbsee> hrm
<tfheen> Riddell: ok, please get it fixed then. :-)
<tfheen> Riddell: thanks.
<Hobbsee> Riddell: how are you reproducing that?  should i shoot this pbuilder or something?
<Riddell> Hobbsee: well I just looked at the debian/control file and saw that there wasn't a replaces for adept-notifier on adept-common
<Hobbsee> Riddell: ah.  
<Chipzz> seb128: do you maintain libnotify etc?
<seb128> Chipzz: no, we don't really have a maintainer for them
<seb128> I can update or patch them if required
<Chipzz> hrrrrm
<seb128> mvo and dholbach also
<seb128> why?
<Chipzz> I just had a notification popup in the upper left corner of my screen, while my notification area is in the bottom right corner
<StevenK> seb128: I wonder if you've read the spec yet.
<seb128> StevenK: what is the URI for the spec again? I'll have a look now
<StevenK> seb128: http://wiki.ubuntu.com/AboutUbuntu ; thanks
<seb128> Chipzz: there is several bugs open about notification-daemon bubble placement
<seb128> patches are welcome ;)
<seb128> StevenK: np
<Chipzz> seb128: ah ok, known issue :)
<seb128> StevenK: looks like a good idea
<StevenK> seb128: It's mostly written, I have just hit a wall about putting into the System menu
<StevenK> I doubt I can get it into main this release, though. :-/
<seb128> well, it's past feature freeze now
<seb128> that looks like something for next cycle
<seb128> get it to universe for now to start
<seb128> and get it on the specs list for next UDS so it get discussed
<seb128> or maybe mail ubuntu-devel about it
<StevenK> Yup. But it still needs to be put on the menu...
<seb128> StevenK: menu changes should be discussed, that's why I suggest mailing the list to get opinions about that
<BenC> tfheen: ok
<BenC> tfheen: I've just been waiting for it to process so lrm would build
<BenC> tfheen: Done
<pitti> hey BenC 
<seb128> BenC: would the crash handler problem be fixed for herd4?
<BenC> pitti: Hey
<seb128> BenC: if not we should consider stopping using apport :/
<BenC> seb128, pitti: No, the kernel tfheen pointed out is the last one I uploaded
<BenC> I have a fix for it, but it's not uploaded yet
<seb128> could you get it uploaded before herd4?
<pitti> seb128: I disabled apport last Friday in 0.52
<seb128> pitti: ah ok, cool
<BenC> seb128: Might be best to ask tfheen
<seb128> I would prefer getting linux fixed and apport used again for herd4 if possible though ;)
<BenC> I'll do an upload and talk to him about getting it in
<seb128> BenC: thank you, that would be useful to get valid bugs for herd4
<tfheen> BenC: cheers.
<BenC> tfheen: oops, forgot to account for last upload version...reuploaded
<Liberax> Hi guys.. anybody know what part of the system control the wireless led blinking on the laptop
<Ng> Liberax: usually the wireless driver itself
<Liberax> Ng: beacause on windows works right but on link is blinking too too fast
<Liberax> on ubuntu
<Ng> Liberax: maybe ubuntu is making your wireless go faster! or it might be a bug ;)
<Liberax> Ng :) usually the led blink when searching wireless network
<mvo> Chipzz: hmmm ... most of the placement of the notifications *should* be fixed
<mvo> Chipzz: any way to reproduce it?
<doko> geser: uploaded, IMO a rebuild is sufficient
<Chipzz> mvo: I got it with a notification of "battery full"
<Chipzz> not sure if I can reproduce it
<Chipzz> mvo: ah I get it
<Chipzz> my panel died a couple of days ago, and the power manager icon got it's own window
<Chipzz> which is in the top-left corner (on another desktop even)
<mvo> and where did the bubble pointed too now?
<geser> doko: I tried a rebuild, the deb contained the files but the package had no depends on python
<hunger> Is there a reason for needing aspell-ss all of a sudden?
<seb128> grumpf
<seb128> $ quilt next
<seb128> 99_configure
<seb128> and there is no mention of 99_configure to that source package
<Chipzz> seb128: wrt g-p-m's icon not returning to the panel notification area, should I file a bug in launchpad or in upstream bug tracker?
<seb128> Chipzz: upstream
<seb128> hate quilt :/
<Chipzz> seb128: oh, apparently a bug is already filed :)
<Chipzz> makes it easier for me :)
<Chipzz> http://bugzilla.gnome.org/show_bug.cgi?id=375377
<seb128> good ;)
<Ubugtu> Gnome bug 375377 in gnome-power-manager "gnome-power-manager does not reattach to the notification area after gnome-panel has crashed or has been killed" [Minor,New]  
<Chipzz> oh sigh
<Chipzz> this is not a bug in g-p-m, but in GtkStatusIcon :S
<tfheen> BenC: there's a fairly large amount of bugs targetted for herd 4; what's happening with those?
<BenC> tfheen: Most of them are fixed in the current kernel
<tfheen> BenC: ok, coolie
<BenC> if they are fix commited, most like they are fixed
<BenC> I'll run through the bug list soon
<tfheen> there's a bunch of them from cr3 at least.
<BenC> ah, some of those are fixed, but not verified yet
<tfheen> ok.  It'd be nice to have them verified, but I'll nag cr3 about that.
<tfheen> cr3: ^^ nag. :-)
<cr3> tfheen: that worked, I'll spend some time verifying today
<tfheen> cr3: thanks.
<bddebian> Heya
<ogra> tfheen, when do you plan to freeze ?
<tfheen> ogra: tomorrow.
<ogra> i guess thursday is eta for herd4 ?
<ogra> ok, thanks
<ogra> tfheen, i need the pulse esound compat stuff moved to main to make ltsp installable, could you do that before ? and pitti can you review the sound related packages (alsa-plugins and gst-pulse) for main inclusion ? 
<ogra> dtrask, !! nice to see you around !
<dtrask> Hi!
<dtrask> just poppin' in for a sec....my students are working on a project so I had some down time
<Liberax> Hi guys i'm testing festy
<tfheen> ogra: pulseaudio-esound-compat promoted.
<dtrask> ogra, how goes fiesty?
<ogra> tfheen, TA
<Liberax> there is a problem in the WINDOWS_MANAGER environment variable that point on .gnome-compiz-manager/openbox
<ogra> dtrask, could be better ... auth server didnt make feature freeze
<tsmithe> Liberax, filed a bug?
<Liberax> this lock the gnome session startup
<ogra> Liberax, we dont ship compiz (and this is not a support channel)
<Liberax> on gnome-wm launch
<dtrask> orga, oh shoot!  What was the hang up?
<ogra> dtrask, i dont like the pam handling of the plugins at all, i'd like to fix that before starting to implement anything on top 
<Liberax> ogra: so i tried to uninstall ubuntu desktop-effects package
<Liberax> ogra: i doesn't need support i think that festy was a development release
<ogra> Liberax, file a bug or give us a patch ... this channel is for development only 
<dtrask> ogra: nice thing is that we at least have a working "situation" so not all is lost, we just have to wait....
<ogra> right
<ogra> oh, and edsadmin isnt feasable without a lot of rewriting ... it depends on the wrong ssl libs, misses licenses etc ...
<ogra> dtrask, ^^
<ogra> so that needs fixage as well ...
<dtrask> ogra:  there is a LOT of buzz in this area about Fiesty....people are anxiously awaiting it.  Matt and I are doing 3 conferences this summer....one in Maine....one in New Hampshire and a new one in Washington D.C.  We expect that Fiesty will get a LOT of coverage  :-)  
<ogra> thats awesome!
<dtrask> ogra:  any ideas on a replacement for edsadmin or write our own?  Maybe even a webmin module?
<dtrask> ogra:  We'd love it if you and maybe RichEd could come....  :-)
<dtrask> at least to one of them
<dtrask> :-)
<dtrask> Matt and I are having dinner with Maddog on Sunday to discuss summer plans....evidently he has big news....I'm on "pins and needles"
<ogra> i'D love to come ... i think there is a conf in portland in the summer as well i have to attend 
<dtrask> ogra: how does the sound look....I noticed you were talking to tfheen about pulse
<dtrask> cool
<ogra> sound is done so far, just waiting for some paperwork ... (main inclusion and promotion of some packages)
<dtrask> ogra:  multi-media and fat clients are also garnering a lot of attention here as well
<ogra> pulse is a *huge* improvment ... even its not perfect yet
<Liberax> anybody know where it is set the WINDOWS_MANAGER environment variable?
<dtrask> ogra:  I'm hoping to do some serious testing after Feb vacation....(2 weeks from now)....I have a dual processor server sitting doing nothing right now and it needs a "job"
<ogra> (i need to revisit the microphone stuff in feisty+1, for feisty we have fully working volume contol and a lot more stable sound transport)
<ogra> Liberax, please ask in #ubuntu for support
<pochu> Liberax: #ubuntu+1
<dtrask> ogra: anyone tested it with Flash?
<Liberax> ogra: i want to create a patch
<Liberax> ogra: i need to know somthing about gnome internal to fix it i need to ask to the user channell? 
<ogra> dtrask, with 7 it worked fine ... i need to update and check 9, but since pulse emulates an alsa card now, it should just work
<ogra> Liberax, no, file a bug first ... the right people should be autosubscribed ... 
<Liberax> ogra: but if doesn't know the right package the create this issue..
<ogra> aoart from that dholbach or seb128 are the gnome gods that stem the world for us
<dtrask> ogra:  that's awesome news!  People are struggling with esd and Flash right now...Gadi wrote a workaround, but it's "cludgy".....I gotta' go....class is over, but I'll be on a lot over the next 2 weeks....I'll try to catch up with you   :-)
<ogra> *apart
<ogra> dtrask, ciao then :)
<ogra> mdz, about your gpm issue, it looks like bug 81407, could you provide the info i request there ? seems hal doesnt like IBM, all settings in the FDI file apart from one model are for lenovo instead :)
<Ubugtu> Malone bug 81407 in gnome-power-manager "[Feisty]  Thinkpad (all models) LCD brightness control cycles between lowest settings only" [Medium,Confirmed]  https://launchpad.net/bugs/81407
<mdz> ogra: yes, that sounds like my bug
<ogra> seems its a trivial leftout in the fdi file ... we need to get a good list or some good matching for the different models affected
<ogra> kylem, didnt you adress bug 62308 with your latest edgy kernel ? 
<Ubugtu> Malone bug 62308 in linux-source-2.6.17 "Permission Denied on nfs clients for only some files" [High,In progress]  https://launchpad.net/bugs/62308
<ogra> s/your/our/
<geser> doko: your rebuild of python-pam contains the files now but has no dependencies anymore
<mdz> ogra: I'll get it when I unpack my laptop
<ogra> great, thanks :)
<doko> geser: I see
<BenC> tfheen: Is there time for a non-ABI bump kernel for Herd4?
<ogra> kwwii, do you have a cropped version of the edubuntu logo ? 
<kwwii> ogra: nope, but I can make one
<kwwii> btw, it would work as a usplash too (ie 256 colors)
<ogra> that would be cool ... i'm just playing with svg support for ldm ... so we could put it in front of an svg
<ogra> yep, i thought i'd take the one you sent me already as usplash 
<kwwii> cool, I'll export a version with a transparent bg
<kwwii> ogra: still need to make a progress bar for it
<kwwii> ogra: i am working on the ubuntu usplash atm, so I can make your today as well
<ogra> wow
<ogra> that would rock :)
<kwwii> ;-)
<kwwii> I'll have one ready in like an hour or so
<kwwii> then you could put it on the next Herd to get peoples reactions
<ogra> yep
<kwwii> I'll ping you when it is done, ok?
<iwj> Robot101: Xen checksum crack> Well, I got some reply but it was hopelessly inconclusive.
<Robot101> iwj: they appeared to commit a patch but I'm unconvinced it's that much better
<iwj> You could follow it up by cut-and-pasting my writeup and reposting it to some relevant list.
<iwj> Robot101: Oh, what does that patch do ?
<Robot101> iwj: http://xenbits2.xensource.com/xen-unstable.hg?rev/4ad317429111
<iwj> That does sound lime an improvement.
<iwj> In particular `Yet another change is to allow netback to disable tx checksum
<iwj> offload, just as we already could for netfront.'
<iwj> That sounds like we could use the wossname tool to turn this misfeature off.
<Robot101> right, so even if whatever it is he just did doesn't work, we can properly turn it off :D
<Robot101> but he also changed from NO_CSUM to IP_CSUM, and frobbed some flag that gets sent with the buffer to explain if it's checksums are bogus or not
<iwj> That sounds like an improvement too but evidently you have a situation where it's still buggy.
<iwj> I bet it's when you do forwarding.
<iwj> So let me guess your failure case: packets sent by your guest to places outside the host get csum offload as they go through the virtual interfaces and nothing recalculates the csum on the way out of the real hardware ?
<tsmithe> !netsplit
<tsmithe> :S
<kylem> ogra, well, it was fixed for someone.
<Robot101> iwj: even stupider than that, we're using routed stuff and you can't use tcp between the dom0 and the domU
<iwj> Freaky.
<Robot101> iwj: it works if you use their bridge madness but it's fragile as hell so we'd prefer to route it
<iwj> Quite so.  I don't like the bridge stuff either.
<Robot101> (also we can do rp filters on customers etc, and avoid address stealing nasties)
<iwj> File a bug against the Ubuntu/Debian version saying `we should disable this nonsense' ?
<iwj> Robot101: Indeed. 
<iwj> Route (+proxy-arp if necessary) is the way forward.
<elmo> eh, what's wrong with the bridge stuff?
<iwj> It's just a bit crazy.
<zul> iwj: patch you need?
<Robot101> on one SMP box with e100 we got weird deadlocks in the bridge driver which resulted in it going "the physical interface disappeared, removing from the bridge" randomly, and then never putting it back
<ogra> kylem, hmm, the last comment doesbt indicate that
<ogra> *doesnt
<iwj> Difficult to filter, manipulate and generally entrap properly.  And it messes freakily with the host's networking setup because it has to slide the bridge in under the host networking stack.
<Robot101> and then any ifconfig/brctl commands went to D state
<iwj> zul: WDYM `patch [I]  need?' ?
<zul> iwj: never mind...i jumped in the middle of your conversation
<iwj> I would like the csum offload disabled but I don't care _that_ much whether it is by default because I've wedged it off on my system.
<Robot101> switched to routed configuration; improvements in reliability and understanding; happiness ensues :)
<iwj> Robot101: Yay!  I didn't know the bridge stuff had kernel bugs.#
<elmo> hmm, weird - I used bridging firewalls for several years, including on e100 machines, SMP and UP without problems *shrug*
<iwj> Speaking of kernel bugs I need to talk to some kernel person about whether my theory about why my colo wedged on Friday night is true.
<Robot101> elmo: yeah the bridge driver has always worked fine for me in other scenarios
<iwj> elmo: The Xen stuff does a lot of interface renaming and constantly bringing up and down virtual interfaces.
<iwj> And perhaps the Xen vif code is buggy ...
<Robot101> elmo: it's just adding xen+bridge resulted in pain
<iwj> colo wedge> AFAICT the problem is that 1. pvmove did dmsetup suspend; 2. dmsetup suspend is never guaranteed not to wedge the machine.
<iwj> (Well, err, maybe dmsetup suspend is safe on ro devices.)
<andreasw> why is ffmpeg not compiled with x11grab support?
<doko> tfheen, infinity: I cannot reproduce the openoffice.org build failure on amd64 on ronne. please could you requeue the package, maybe on another buildd?
<sabdfl> /info #mercurial
<sabdfl> erk
<kwwii> ogra: do you really use the colored bg in your current usplash?
<ogra> kwwii, you mean the yellow rangish one ? 
<kwwii> ogra: or is the usplash on edubuntu only shown at 640x480?
<ogra> *orangish
<kwwii> ogra: yepp
<ogra> thats the one i got from our arttem for edgy, yes ...
<ogra> we had a separate 16cols one for amd64 in edgy
<kwwii> ogra: how has that worked out? is it often shown in the middle of the screen with black on the outside?
<ogra> no
<kwwii> ogra: the 16 color for amd64 is no longer necessary
<ogra> its scaled fine 
<ogra> yep, i saw that 
<kwwii> ogra: you realize that the one I am making has a black bg, right?
<ogra> yep
<kwwii> cool
<kwwii> the colored bg is a pretty good idea, I think
<ogra> i prefer the black one after one release that i had to look at this eye hurting yellow :)
<kwwii> lol
<ogra> the colored bg is fine, but not the way we have it in edubuntu atm
<ogra> its way to saturated
<kwwii> yeah, I would think that something like the gdm bg would be much better
<ogra> i would have fixed it myself in edgy, but ran out of time to play with artwork
* kwwii always knew that an artist was hiding deep in your soul :p
<ogra> and at least itr fits the rest of the distro
<kwwii> ture
<kwwii> erm s/ture/true
<ogra> kwwii, i wored two years as grphics designer for an agency :)
<ogra> *worked
<kwwii> cool
<ogra> http://www.atelier-kamp.de/
<kwwii> nifty gif animation
<kwwii> but the swf is not embeded properly :-)
<ogra> http://www.gieseler-maler.de/ was the first website i ever designed commecially :)
<ogra> they started with flas after i left ... not my fault :P
<ogra> *flash
<kwwii> the graphics in that are pretty cool
<kwwii> good ideas
<ogra> but te programming is horrible :)
<ogra> today i'd use css everywhere ... 
<kwwii> yeah
<keescook> mornin'
<BenC> tfheen: Can I do a kernel upload?
<bddebian> Who's got NEW duty this week? :-)
<pitti> bddebian: archive days are Monday (tfheen), Wednesday (seb128), and Friday (me)
<bddebian> Isn't today Monday? :)
<seb128> bddebian: looks like a good reason to let people do their work ;)
<bddebian> :'-(
<pitti> bddebian: source NEW usually lags behind a bit
<bddebian> Sorry, I know you folks are way swamped, it's just frustrating the lengthy process of getting these damn tilp packages in :-(
<seb128> what is tilp?
<kwwii> ogra: http://sinecera.de/edubuntu_pics.tar.gz I'll let you do the hard work :p
<ogra> thanks ... i know edubuntu-artwork isnt fun :)
<kwwii> erm, wait, I made a mistake
<bddebian> seb128: packages for talking to TI Calculators
<bddebian> seb128: But I'm having to do it in series because of build dependencies
<kwwii> ogra: ok, get it again, problem fixed
<ogra> ok
<cjwatson> bddebian: that's no reason to do it in series; upload the lot, and any that can't build yet will simply dep-wait
<bddebian> cjwatson: But I need to run them through REVU, get them OK'd there, then have you folks review them as NEW and I don't want some mass confusion of what's accepted and what's not.
<cjwatson> I don't know about REVU, but as far as the archive is concerned there is absolutely no need for serial uploads, and no meaningful confusion caused
<bddebian> Well like with REVU, people can't test build libfoo if libbar isn't in the archive (at least not without some effort)
<iwj> I've just uploaded a new mdadm which I think will fix the md inappropriate degraded assembly bug which has been popping up.
<iwj> If I break anyone's booting completely then I apologise.  If so I'll fix it properly tomorrow :-).
<iwj> Off for dinner now.
<elmo> iwj: those kind of uploads are much better scheduled for 6pm on a Friday, FYI
<kylem> elmo, no no no, 6pm on a friday, before a 2-week vacation.
<kwwii> now I know why I wait a day before applying updates
* ogra watches sudo rm -rf /var/cache/pbuilder/build/* .... working since more than 5min already ...
<ogra> wow .... 7.5 G free space ! we should have pbuilder notificatin for left behind build trees :)
<ogra> mjg59, around  ?
<mjg59> ogra: Hi
<ogra> mjg59, seen bug 81407 ?
<Ubugtu> Malone bug 81407 in gnome-power-manager "[Feisty]  Thinkpad (all models) LCD brightness control cycles between lowest settings only" [Medium,Confirmed]  https://launchpad.net/bugs/81407
<ogra> seems there realy isnt *any* matching for smbios.chassis.manufacturer = 'IBM' in the fdi file 
<ogra> do you think adding the missing bits suffices ? 
<ogra> (i'm not sure its a hal only issue)
<mjg59> ogra: I think there are multiple issues
<mjg59> The hal one needs fixing regardless
<ogra> right, i was suspecting that
<mjg59> There's no point matching on IBM. Match on Thinkpad.
<ogra> right
<ogra> apart from the X31
<ogra> which i silly ... so i'll drop the X31 from that line and we should be set with this issue
<ogra> *is silly
<ogra> at least for most of te thinkpads ...
<ogra> even though "smbios.system.version = 'Not Available'" doesnt look nice either ...
<dholbach> if you didn't vote yet, vote: http://launchpad.net/~ubuntu-dev/+polls
<dholbach> good night
<bhale> good bye dholbach 
<dholbach> bye bhale
<BenC> pitti: the apport fix is in git, but it's an ABI bump, and I'm not sure tfheen will let me do another upload for Herd4
* bluefoxicy direct upgrades dapper -> feisty
<ogra> bluefoxicy, you know that this is not supported, right ? 
<bluefoxicy> ogra:  not supported == doesn't work?
<kylem> not supported == you keep both pieces when it breaks.
<ogra> not supported == dont complain about thinks not working
<ogra> etc etc
<Riddell> mvo_: ok if I commit dist upgrader fixes to bazaar.launchpad.net/~ubuntu-core-dev/update-manager/main ?
<tfheen> BenC: ugh, yes, I guess you can.  Urgent fixes?
<BenC> tfheen: Fixes apport
<BenC> tfheen: but it is an ABI bump :/
<BenC> I have it ready to upload now
<tfheen> BenC: ok, get it in ASAP.
<BenC> tfheen: Thanks
<tfheen> doko: given-back
<doko> tfheen: ohh, and if you're still awake, please could ack the new ecj binaries, and move them to main?
<linxeh> hi - I've had a whole bunch of problems with the latest kernel update and the nvidia non-free drivers. it looks to me like the /etc/init.d/linux-modules-restricted-common script is broken - the --quick option needs to be removed from lrm-manager to make it generate the nvidia.ko volatile driver
<linxeh> is there osmewhere I can report this properly ?
<linxeh> (this was edgy with 2.6.17-11-generic btw)
<[knap] > www.launchpad.net
<Burgwork> linxeh: are you using a stock system?
<linxeh> yes, its a stock system 
<linxeh> im not the only person with the problem - I just helped someone in #ubuntu fix it 
<tfheen> doko: yes, I'll do it.
<Burgwork> ok, then launchpad
<linxeh> well, relatively stock - ive installed a couple of things manually
<Burgwork> under the linux-restricted-modules package
<linxeh> but nothing that will interfere with the nvidia / kernel stuff
<Burgwork> is your lrm stock?
<linxeh> yes
<linxeh> definitely
<linxeh> I just had it automatically update the kernel, and when it rebooted the nvidia stuff failed to work, claiming it couldnt find the nvidia.ko file in modules/volatile
<BenC> linxeh: Sounds to me like you didn't get the new linux-restricted-modules-2.6.17-11-generic to go with it
<linxeh> nah I did
<BenC> nothing changed in lrm, it was just rebuilt
<linxeh> I dropped back to an older kernel, removed the packages, cleaned the cache, and then redownloaded them
<BenC> if it worked before, it should now, unless something is broken on your system
<linxeh> ive done that twice 
<linxeh> it works until I reboot
<linxeh> at reboot the volatile modules get recreated, but not the nvidia ones
<_ion> You have the linux-generic metapackage installed?
<linxeh> if i remove the --quick it works
<BenC> dpkg --get-selections | grep linux-restricted-modules
<BenC> let me see that
<linxeh> _ion: yes definitely
<linxeh> BenC: ok sec 
<linxeh> linux-restricted-modules-2.6.17-10-386          deinstall
<linxeh> linux-restricted-modules-2.6.17-10-generic      deinstall
<linxeh> linux-restricted-modules-2.6.17-11-386          deinstall
<linxeh> linux-restricted-modules-2.6.17-11-generic      install
<linxeh> linux-restricted-modules-common                 install
<linxeh> linux-restricted-modules-generic                install
<[knap] > having to update the nvidia kernel module after each kernel update is a major pain in the ass, would not be possible to do this in another way?
<BenC> knap: you don't have to
<BenC> if you install the meta packages, it will upgrade automatically
<[knap] > the problem is that i'm not using the drivers from the repositorie but the latest from nvidia website
<BenC> linxeh: it should work...if the others get created, then so should nvidia.ko...sounds like something is amiss on your system
<BenC> [knap] : then we can't help with that
<[knap] > yeah i know :)
<linxeh> BenC: well its a stock install with some standard software, plus a custom java6 package
<linxeh> other than that everything came from the stock repos, or from the beryl-project repo
<BenC> linxeh: sh -x /etc/init.d/linux-restricted-modules-common start
<linxeh> other people have had the problem  - I know of 1 guy in #ubuntu so far (that also had success with the removal of --quick fix), and at least 1 more on quakenet
<BenC> linxeh: Use paste-bin to get that out to me
<linxeh> well, ive modified that now so it doesnt have --quick 
<linxeh> do you want me to change it back first?
<BenC> the --quick just tells it not to run depmod, that shouldn't affect whether it gets built or not
<BenC> is it that it isn't built, or that it's not found by modprobe?
<linxeh> nvidia.ko doesnt appear to get put into /lib/modules/`uname -r`/volatile if --quick is on the command line 
<tfheen> doko: accepted.
<linxeh> benc:   the output of the command you asked for is at http://rafb.net/p/NU4fBq24.html
<BenC> linxeh: sorry, sh -x /sbin/lrm-manager --quick
<linxeh> ok
<linxeh> http://rafb.net/p/oT8Hmq42.html
<BenC> + . /etc/default/linux-restricted-modules-common
<BenC> + DISABLED_MODULES=nv
<BenC> that there is your fault
<BenC> edit that file and remove the nv from it
<linxeh> ah
<linxeh> ok
<linxeh> how come it works without --quick though ?
<BenC> because without --quick, it doesn't source the default conf file
<BenC> quicker == only building the modules you need
<linxeh> ahhhhh
<linxeh> yeah ok I see now
<linxeh> many thanks :D
<BenC> np
<linxeh> I've said it before, but I'm going to say it again - the community surrounding ubuntu is one of the best I've come across 
<linxeh> I'm forced into using redhat enterprise at work, and it positively sucks :(
<linxeh> many many thanks for the help :)
<sistpoty> sabdfl: thanks for your comment on but #83348 (and I hope you don't mind that I just assigned it to you;)
<linxeh> I suspect quite a few people will get caught out by that though
<sistpoty> sabdfl: I'm just about to mail craig (he had the idea about games...) any canonical ml I should refer him to?
<BenC> linxeh: here's where the community gets better...now you can pass on your experience to others and help them :)
<linxeh> definitely
<linxeh> I'll be passing it on to the #quakenet ubuntu community
<BenC> tfheen: linux-source 8.14 uploaded...lrm is on it's way now, and linux-meta right behind it
<Fujitsu> linxeh, we have a community there? What's it doing there?
<linxeh> Fujitsu: quakenet is a large network (the largest IRC network I believe, 200,000 users typically) - some of the gamers there use ubuntu, so it makes sense there is a channel there
<Fujitsu> Unfortunate that the community is fragmented like that.
<linxeh> yes, a little
<linxeh> its bound to happen though - it happens with everything really
<johanbr> Fragmented... was that a pun?
<linxeh> and there is almost a guarantee that people on #quakenet are using linux to play games, so will know about the issues involved etc
<BenC> yeah, I think it's probably a good thing that there's an ubuntu specific channel there...shows how pervasive we are :)
<linxeh> :)
<linxeh> ubuntu is really popular at work with staff
#ubuntu-devel 2007-02-13
<BenC> tfheen: All uploaded...in your capable hands now
<sabdfl> sistpoty: start with Malcolm Yates <malcolm.yates@canonical.com>
<sabdfl> he handles new ISV's, and game publishers would fall into that category
<sistpoty> sabdfl: ok, thanks, will do
<doko> tfheen, infinity: the OOo build did fail again on amd64; please could you retrieve the preprocessed source of the failing file?
<alex-weej> what is gparted being replaced with in the ubuntu installer?
<givre> alex-weej: a brand new partitionner : https://wiki.ubuntu.com/Ubiquity/AdvancedPartitionerRewrite
<alex-weej> is there a post-installation counterpart tool?
<Burgwork> alex-weej: with parted directly
<alex-weej> i'm just a little bit concerned
<alex-weej> that having done all the setup in the nice fancy ubiquity wizard
<alex-weej> users won't have a clue how to change any of the stuff they set up
<Burgwork> right
<Burgwork> most of the time, users have no need to changing any of the formatting they just did
<alex-weej> right, but it would be beneficial to have SOME consistency with a general purpose tool
<alex-weej> it's also things like choosing locale
<alex-weej> the post-installation tool is completely different to the installation tool (last time i checked it was anyway)
<alex-weej> or has this changed?
<Burgwork> right, that is not parititioning
<alex-weej> but it is the same issue
<Burgwork> not really
<alex-weej> ok
<Burgwork> the ability to change stuff after install is done via the control centre
<Chipzz> [knap] : the answer to that is really simple I guess: drivers from the nvidia site are not supported. if it break, you get to keep both pieces
<Chipzz> and it *is* bound to break
<Chipzz> in short: don't do it
<Chipzz> which makes me wonder; has anyone bothered to contact nvidia to tell them we have our own drivers, and to ask them to change their instructions to refer to the ubuntu packages?
<Chipzz> or would that be the wrong approach?
<TheMuso> c
<_ion> c++
<tsmithe> python?
<_ion> No, ruby.
<bddebian> VB
<LaserJock> Fortran!
<_ion> INTERCAL!
* ajmitch wonders how offtopic it will get
<jsgotangco> heh
<LaserJock> ajmitch: offtopic?!? in here?
<ajmitch> it never happens, right?
<LaserJock> no way
<Kano> hi, what could be the problem when lshal does not show volume and other info with a 2.6.20 kernel but works with 2.6.18? are there specific patches needed which are not in debian?
<_ion> Ooo, look what the apt-get brought in: upstart 0.3.5
<_ion> Although i've been using 0.3.5+bzr for a while already. :-)
<bluefoxicy> hmm damn
<bluefoxicy> my feisty generated no initrds
<bluefoxicy> holy crap that was ugly.
* bluefoxicy finally got xen to boot.. module <kernel>, module <initrd>
* pitti frees the new kernel from NEW
<ajmitch> hi pitti 
<pitti> hi ajmitch
<dholbach> good morning
<dholbach> ogra: new gnome-power-manager for you
<dholbach> ogra: new gnome-screensaver for you
<dholbach> ogra: (and new dia for you) :-)
<jsgotangco> wooo
<pitti> dholbach: yay delegation :)
<tfheen> BenC: what about the new lrm?  Just needs an ABI bump?
<dholbach> pitti: he always did these - I'm just the messenger :)
<ajmitch> pitti: doing source NEW today?
<pitti> iwj: I filed a bug for this dpkg thing, btw (bug 84850)
<Ubugtu> Malone bug 84850 in dpkg "does not interpret X[SBC] -* fields when building binary control files" [Undecided,Unconfirmed]  https://launchpad.net/bugs/84850
<pitti> ajmitch: no, not really; on Friday
<ajmitch> ok
* ajmitch just wants a couple of things through :)
<ajmitch> though ndesk-dbus will also need MIR as well
<ajmitch> it's code shipped in main already, just not as a separate package
<pitti> ajmitch: if it's a mere split out, it doesn't need a separate MIR
<pitti> ajmitch: just add it to the Queue, saying from which package it was split out
<ajmitch> heh
<ajmitch> 'several'
<ajmitch> I'll note that though, thanks
* ajmitch heads off for some food
<ajmitch> pitti: so I'll need to fix up any packages that have Maintainer: ajmitch@debian.org for it to build in the future?
<pitti> ajmitch: don't worry, I just finished a script which will do the mass-upload transition
<ajmitch> that's fine, it'll just make maintaining the source package a bit more annoying
<pitti> right, we have to care for this delta
* pitti -> reboot, brb
<seb128> ogra: new gnome-screensaver and gnome-power-manager to package
* pitti gives BenC a big hug -- -8 works *perfectly* for apport again \o/
<sivang> morning
<sivang> giftnudel: ping
<giftnudel> hi sivang
<sivang> giftnudel: oh, I see the topic got a bit upgraded since last time I'e been here :)
<giftnudel> how are you?
<sivang> let's continue in prvmsg since hubackup is not ubuntu development per se
<giftnudel> ok
<sivang> (e.g. specifically mentions not to talk about application development on ubuntu ;-))
<giftnudel> oh, I see, that's also new to me
<giftnudel> although hubackup is a spec, so that should still work
<_ion> Not that i have anything to say in the matter, but if there's absolutely zero discussion going on about the development of Ubuntu, casual conversation probably doesn't hurt.
<giftnudel> it would soon turn out into a discussion about hubackup, but still
<tkamppeter> pitti, doko, can you check what happened with the uploads of the last versions of foomatic-db and foomatic-db-hpijs?
<pitti> tkamppeter: ok, which version numbers?
<ogra> seb128, thanks for the hint
<seb128> np
<tkamppeter> pitti, foomatic-db-20070207-0ubuntu2, foomatic-db-hpijs-20070207-0ubuntu1
<seb128> ogra: would be nice to do them today so we have GNOME 2.17.91 for herd4 ;)
<ogra> ok
<tfheen> mvo: hiya, can you please do the GnomeAppInstallDesktopDatabaseUpdate process?
* ..[topic/#ubuntu-devel:tfheen] : Development of Ubuntu (not support, even with feisty; not application development on Ubuntu) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Main frozen for Herd 4
<mvo> tfheen: I will do this now, thanks
<seb128> tfheen: grraaa, main already frozen?!
<seb128> tfheen: do we have exception fro GNOME 2.17.91? need like 3 extra hours to get it packaged
<tfheen> seb128: yes, but since you're French, I'm fine with you uploading your gnomy bits.
<tfheen> :-)
<seb128> ah, good
* seb128 hugs tfheen
<tfheen> I just don't want random other crap in now.
<seb128> ok
<pitti> tfheen: we certainly want a new l-r-m for the ABI bump?
<ajmitch> oh well, f-spot fixes can wait a week
<tepsipakki> tfheen: so we shall push the xorg-bits post-herd4?
<tfheen> tepsipakki: yes, that was my plan.
<tepsipakki> yeah
<tfheen> pitti: the one I accepted about an hour or so ago? :-)
<ajmitch> tepsipakki: good work on getting them in shape
<pitti> tfheen: erm, yes :) thanks
<tepsipakki> debian has just uploaded libxcomposite, libxcursor, libxevie, libxdmcp to experimental, so it's getting easier all the time :)
* pitti hugs tepsipakki
* tepsipakki hugs pitti back
<tepsipakki> ajmitch: thanks!
* tepsipakki is updating the CV first time in six years
<cjwatson> pitti,iwj: and patch for bug 84850 attached
<Ubugtu> Malone bug 84850 in dpkg "does not interpret X[SBC] -* fields when building binary control files" [Undecided,Unconfirmed]  https://launchpad.net/bugs/84850
<pitti> cjwatson: yay
<ogra> pbuilder-satisfydepends is killing me :/
<seb128> stop using pbuilder ;)
<ajmitch> blame apt :)
<fabbione> ogra: use sbuild.. it's much better
* ogra wont switch build systems in the middle of a set of package upgrades
<ogra> but thanks, i'll look into sbuild
<seb128> ogra: I think that debian pkg-gnome guys use cowbuilder and they said it's much faster than pbuilder
<ogra> ah, i'll look at that one as well ... even though, given the amount of pbuilder users in ubunt we should probably just fix it :)
<ajmitch> ogra: apt-get --simulate takes a *long time* now, I can't recall the bug #
<fabbione> ogra: well.. to be hounest.. given that sbuild is used on buildd.. i would prefer it compared to others
<fabbione> and to some degrees is faster than pbuilder
<ogra> i knoe mvo was working on something to fix that ...
<ogra> *know
<iwj> cjwatson, pitti: Nice and freaky bug that.  Thanks, Colin.
<tkamppeter> pitti, can the packages foomatic-db-20070207-0ubuntu2 and  foomatic-db-hpijs-20070207-0ubuntu1 still go into Herd 4?
<tfheen> tkamppeter: do they fix any bugs targetted for herd 4?
<pitti> tkamppeter: foomatic-db is not in NEW, and new version does not exist on the archive; are you sure that they have been uploaded?
<pitti> tkamppeter: (likewise for hpijs)
<tkamppeter> pitti, I have asked you and doko to upload them last week and you told me that you will do so, as it was my intention to get them in before UVF.
<pitti> tkamppeter: hm, I remember uploading some packages, but not foomatic-db
<tkamppeter> tfheen, the two packages assure that there will be PPDs for all printers which are supported by HPLIP 1.7.1 which is our current HPLIP for Feisty.
<Riddell> pitti: could you promote apport-qt to main when you have a free moment
<pitti> tkamppeter: oh, in fact I did upload it
<tfheen> Riddell: I did that last night.
<pitti> tkamppeter: I wonder where that went to...
<pitti> Riddell: how does it work under KDE so far?
<tkamppeter> tfheen, the foomatic-db fixes also a bug of the 0ubuntu1 version with renaming of binary packages.
<tfheen> tkamppeter: what are the bug numbers?
<tkamppeter> tfheen, there are no bug numbers as I have found the problems by myself.
<pitti> tkamppeter, tfheen: I'm pretty sure I uploaded it, but it has never arrived as it seems; hmm
<Riddell> tfheen: oh, excellent, thanks.  can I upload a kubuntu-meta to include it?
<tkamppeter> For the foomatic-db and the uploading I made a new package the same day, as soon as I discovered it.
<tfheen> Riddell: please.
<pitti> tfheen: the diff between ubuntu1 (in the archive) and ubuntu2 (mysteriously lost) is adding transition packages for the renamed packages
<tfheen> tkamppeter: in the future, please do file bugs and get them targetted to the relevant milestone or the release if they are important.
<tfheen> pitti: please reupload it and I'll review it.
<ogra> pitti, no MIR review for my sound parts :/ i'd have loved to have them in herd4 
<tfheen> tkamppeter: since I'm terrible at reading other people's thoughts it does not help me or the release that you know about a bug if you do not tell me about it.
<Riddell> pitti: it works great, but still lacks the adept-notifier integration
<pitti> Riddell: right
<tkamppeter> tfheen, so in the future I will create a bug report along with the package submission.
<pitti> tfheen, tkamppeter: reuploaded foomatic-db
<tfheen> tkamppeter: yes, or rather when you discover the bug.
<tfheen> pitti: cheers.
<pitti> argh, I take that back; wrong source.changes
* pitti makes a mental note that uploading source packages is *hard* when you have sudo vi /usr/bin/dpkg-source open
<pitti> uploaded for real now
<tfheen> pitti: heh. :-)
<tkamppeter> pitti, thanks. Did you also upload foomatic-db-hpijs
<pitti> tkamppeter: no, I never touched it (doko claimed it)
<pitti> tkamppeter, tfheen: ^ shall I?
<pitti> (I cannot test it at all, mind you)
<pitti> but neither can doko, so *shrug*
<doko> hm ...
<tfheen> seb128: you'll tell me when you have all your new GNOME shiny in?
<tfheen> pitti: please do
<seb128> tfheen: yep, we are almost there, 3-4 tarballs left
<ogra> tfheen, g-p-m woud be ready, ok to upload ? 
<ogra> *would
<tfheen> ogra: please.
<pitti> tfheen, tkamppeter, doko: f-d-hpijs uploaded
<ogra> thanks :)
<seb128> pitti (and probably other people who asked for it): with the new gnome-menus/gnome-panel/control-center combo just uploaded you have the menus back, you just have to unmask them from the menu editor
<seb128> enjoy ;)
<pitti> ah, but we won't do that by default?
<pitti> seb128: great, thanks!
<seb128> pitti: not decided yet, but looks like it'll be shell by default which is better for standard users and the menus which are better for power user are a few click away to the menu editor
<seb128> pitti: feel free to start a discussion on ubuntu-devel(-discuss) list if you think we should use menus by default
<pitti> seb128: 'k
<pitti> hi carlos 
<jwendell> seb128, is there any way to use menus (a gconf key, for example)?
<carlos> pitti: hey
<seb128> jwendell: did you read what I wrote 10 lines ago?
<jwendell> seb128, no hehe
<seb128> jwendell: the "you just have to unmask them from the menu editor"
<jwendell> seb128, so, i guess it should be like it's right now...
<jwendell> seb128, advanced users who want menu back can do this step
<seb128> right
<tfheen> cjwatson: could I have a d-i upload synced with the -8 kernel ABI?
<tkamppeter> pitti, thanks.
<ogra> tfheen, gnome-screensaver ready as well ...
<zakame> hmm did anyone experience their swapspace double due to devmapper readding to swapon?
<ogra> tfheen, ok to upload ? 
<tfheen> ogra: yes, please.
<ogra> there we go
<seb128> tfheen: if I want to sync libsoup on Debian (they packaged the new version for the new GNOME yesterday) should I open a bug first for the record or just syncing is fine?
<tfheen> seb128: I've just synced such packages as myself in the past.
<seb128> tfheen: ok, thanks
<tfheen> fabbione: your ltp upload ftbfs.
<fabbione> tfheen: doh!... 
<fabbione> tfheen: ok.. i will look into it, but it's not fatal for herd4
<tfheen> fabbione: no, not fatal, I just noticed it off the top of my mailbox
<Chipzz> mvo_: ping?
<StevenK> Directory debian/ltp-commands-test does not exist, aborting
<StevenK> Hrrm
<cjwatson> tfheen: sure
<mvo> Chipzz: hello
<tfheen> Riddell: adept seems to ftbfs.
<fabbione> StevenK: strange because nothing did change what's built or installed..
<cjwatson> tfheen: done
<tfheen> doko: you're aware sun-java5 ftbfs on ppc and sparc?
<tfheen> cjwatson: thanks
* Hobbsee waves
<Riddell> how peculiar
* tfheen hugs Hobbsee 
<doko> tfheen: yes =)
<tfheen> doko: could you get it PaS-ed?
<doko> tfheen: just don't try to build it
* fabbione scratches his head
* Hobbsee hugs tfheen back, then falls over
<tfheen> doko: same build failure for ooo, btw.
<tfheen> Hobbsee: tired?
<Hobbsee> yup
<Hobbsee> its' 11pm - dinner time
* Hobbsee curses damned lazy coworkers.
<tfheen> Hobbsee: whenever you have the time, you touched kxgenerator last.  It fails to build now.
<Hobbsee> tfheen: yes, i saw that, i think :(
<Hobbsee> something else failed, too...
<doko> tfheen, infinity: seen, and I asked for the preprocessed source file; the package just builds fine for me on two machines
<tfheen> doko: hm, true.  You need infinity for that, I don't have access to it.
<seb128> tfheen: I'm done with my GNOME updates, dholbach is still working on gnome-terminal and gnome-netstatus and slomo on tomboy and seahorse
<dholbach> seb128: both uploaded
<seb128> after that we should be set for herd4
<seb128> ok
<dholbach> i'll upload a new usplash-theme-ubuntu next
* dholbach high-fives kwwii
<tfheen> seb128: ok, cheers.
<tfheen> dholbach: woo.
<seb128> ok, lunch time for me, bbl
<slomo> seb128: seahorse is universe anyway, tomboy will be uploaded in < 10 minutes :)
<tfheen> slomo: excellent! :-)
<tfheen> seb128: I presume you're aware, but your beagle upload fails to build.
<slomo> tfheen: i'll look at the beagle build failure after tomboy/seahorse
<tfheen> slomo: cheers.
<mjg59> pitti: Any chance you can enable macbookpro support in hal?
<StevenK> tfheen: Anything you can throw at me?
* Hobbsee throws tfheen at StevenK 
<pitti> mjg59: is that a patch from git head?
<StevenK> Hrm, maybe I should re-phrase that... :-P
<StevenK> Hobbsee: He's not my type. :-P
<tfheen> StevenK: you want some build failures to grab?
<slomo> pitti: while at it... https://bugs.freedesktop.org/show_bug.cgi?id=9343 might be of interest for you too :)
<Ubugtu> Freedesktop bug 9343 in misc "hal-device-manager: [patch]  cosmetic issues with dbus-python 0.80" [Trivial,New]  
<StevenK> tfheen: Yup
<tfheen> StevenK: amarok.
<Hobbsee> StevenK: apt-cache unmet.  get fixing :)
<Hobbsee> eep, amarok ftbfs?
<tfheen> yup, across all arches.
<ogra> oh, CC meeting in the UTC afternoon ... thats new :)
<Hobbsee> ogra: means the aussies can attend every once in a while
<StevenK> tfheen: Aye
<dholbach> tfheen, kwwii: uploaded
<ogra> Hobbsee, :)
<mjg59> pitti: No, it just needs enable-macbookpro rather than disable-macbookpro in rules
<mjg59> Oh, and a build-dep on pciutils-dev
<pitti> mjg59: ah, I see
<pitti> mjg59: no problem; I leave convincing tfheen to you :)
<ogra> mjg59, apparently the hal fdi change fixed the brightness key issue for a lot of people ... but it doesnt feel right somehow that we need this many overrides in hal 
<ogra> mjg59, do you have any idea how we could avoid it more from the ground up than adding tons of matches to fdi files ? 
<mjg59> ogra: Hardware behaves differently. fdi files exist to tell hal how the hardware behaves.
<mjg59> It should only be two matches for the Thinkpads.
<ogra> well, in the bug people with asus and toshiba laptops showed up with the same prob
<slomo> tfheen: tomboy and seahorse uploaded
<tfheen> slomo: tomboy already accepted.
<mjg59> ogra: No, that's a different problem
<ogra> ah, k
<ogra> what about the thinkpads that dont know they are thinkpads ? 
<mjg59> They lose
<raphink> anybody aware of kernel panic with 2.6.15-28.51 on dapper?
<ogra> heh
<raphink> I guess I'll go tell that on #ubuntu-kernel rather
<pitti> raphink: since latest security update? no
<raphink> since 2 days ago pitti
<raphink> my mom just got a kernel panic with it
<pitti> raphink: ugh, regression
<raphink> which blah
<pitti> raphink: please file a bug and mark it security
<raphink> so I'll go shout on #ubuntu-kernel
<raphink> I don't have trace though
<pitti> raphink: or that, thanks!
<raphink> she's 1000km away
<ogra> mjg59, well, there seem to be some with
<ogra>  smbios.system.product = '236697U' (string)
<ogra>   smbios.system.manufacturer = 'IBM' (string)
<raphink> so I can't have her note everything she sees
<ogra> or other numbers as the product name
<ogra> tfheen, i have an updated edubuntu-artwork as well, ok to upload ? 
<tfheen> ogra: sure
<ogra> thanks :)
<fabbione> pitti: ping?
<pitti> hey fabbione 
<fabbione> hey dude
<fabbione> pitti: the ltp FTBFS is caused by pkg-create-dbgsym
<fabbione> pitti: mind to take a look at it?
<pitti> fabbione: of course not
<tfheen> Riddell: do you want the new adept in for herd 4?
<fabbione> you also want /bin/sh pointing to bash to build.. i am uploading a fix for that doesn't show up in the buildd
<Riddell> tfheen: yeah, that would be nice
<fabbione> tfheen: fixed ltp uploaded (universe).. it will still need pitti's love to build
<tfheen> fabbione: cheers
<slomo> tfheen: ok to upload beagle fix in some minutes?
<tfheen> slomo: please.
<ogra> tfheen, there is on fuse fix i'd like in herd4, ok to upload ? 
<ogra> http://flomertens.keo.in/merge/debdiff_ubuntu1-ubuntu2 in case you want to look at it ...
<tfheen> ogra: what's the reasoning for changing the udev priority?
<ogra> tfheen, it was a leftover from a former version ... 80 is usersetup already, 45 is the system 
<ogra> (in a former version te fusectl filesystem was also mounted from the udev rule, we now do that from a modprobe.d script)
<tfheen> ogra: hm, ok.  Upload away.
<ogra> somehow the 80-fuse file didnt get deleted ...
* ogra uploads
<ogra> thanks
<Riddell> StevenK: did you look into amarok fail to build?
<StevenK> Riddell: Looking at it now
<Riddell> StevenK: that .desktop file installed on my local build, I'm not sure what governs when it gets installed and when it doesn't
<StevenK> Riddell: The last ten lines of debian/amarok.install don't start with debian/tmp
<Riddell> ah, that would be it then
<StevenK> I'll throw you a debdiff?
<Riddell> please
* StevenK ponders a test build, considering it will take about 20 minutes
* StevenK kicks it off
<ogra> tfheen, one last upload (apart from possible ltsp or edubuntu-meta changes for the CD), i needed to add a transitional package for student-control-panel to thin-client-manager ... ok to upload ? 
<tfheen> ogra: go ahead.
<ogra> thanks :) 
<giftnudel> I now spent 2 hours trying to get some patch to configure and it always complained about AC_PROG_LIBTOOL being undefined - the solution was to actually install libtool ...
<pitti> fabbione: 'k, I think I fixed ltp hard enough now
<fabbione> pitti: ok thanks... you rock dude
<pitti> fabbione: interesting package, btw
<pitti> tkamppeter: do you think that you can get a basic source package for printerdriver-autodownload working for feisty?
<cjwatson> pitti: (see my mails on the subject)
<pitti> cjwatson: weird, I just have Till's reply
<pitti> 08.02.07 20:42 Till Kamppeter    Printer driver autodownload - how to proceed?
<pitti> cjwatson: ^ this thread?
<cjwatson> yeah, I only sent it recently
<pitti> ah, got them now
<cjwatson> mvo: we were to talk about dist-upgrader autobuilding. When would be a good time?
<cjwatson> mvo: and where can I check out the code you use to produce your dist-upgrader uploads at the moment?
<mvo> cjwatson: whenever it is most convinient for you
<Kagou> hi
* givr1 hugs ogra :)
<ogra> givr1, the upload was overdue :)
<ogra> thanks for the patch :)
<cjwatson> mvo: is it in http://bazaar.launchpad.net/~mvo/update-manager/main ?
<mvo> cjwatson: yes, under DistUpgrade/build-dist.sh
<cjwatson> rather s/mvo/ubuntu-core-dev/
<mvo>  sftp://mvo@bazaar.launchpad.net/%7Eubuntu-core-dev/update-manager/main/
<mvo> yes
<cjwatson> mvo: is there any reason not to just build it on every update-manager upload?
<mvo> cjwatson: sure, we could do that. but its not a source-deb and it does not produce a binary deb but a tarball. if we can make soyuz to deal with that, that would be good
<pitti> tfheen, fabbione: new ltp uploaded (fixes FTBFS, universe)
<mvo> cjwatson: have you read my proposal about the special upgrader deb packages? it would be a alternative approch to the problem
<cjwatson> mvo: so what I'm thinking is that the dist-upgrader tarball could just be another one of the objects spat out by the update-manager source package, along with its .deb(s)
<cjwatson> mvo: there's a perfectly standard process for doing that kind of thing, which shouldn't need soyuz modifications
<cjwatson> mvo: haven't read your proposal, no. Where is it?
<mvo> cjwatson: https://wiki.ubuntu.com/UpdateManagerArchDependent
<mvo> cjwatson: about building the tarbal on each update-manager source upload, that could certainly be done. the disadvantage is (AFAICS) that for selected backports (like a new apt) we would have to include it into that build-process as well. the alternative approach with using packages is more modual because we could update individal packages independantly for the upgrdaer
<ogra> cjwatson, i stopped getting daily CD health check mails on saturday, is that intentional ? 
<StevenK> Riddell: Right. Test build sucessful.
<StevenK> Riddell: Debdiff is at http://wedontsleep.org/~steven/test/amarok_1.4.5-0ubuntu4.debdiff
<Riddell> thanks
<BenC> tfheen: I uploaded new lrm and linux-meta
<BenC> tfheen: Everything looks built and ready
<pitti> BenC: morning
<tfheen> BenC: the "linux" package looks uninstallable on sparc, as does the linux-backports-modules packages.
<BenC> pitti: Hey...-8 kernel should fix apport
<BenC> tfheen: Let me check that real quick...at worst, I'll do another linux-meta upload
<mvo> iwj: could you please have a look at bug #84894 when you have a bit of time? 
<Ubugtu> Malone bug 84894 in devmapper "File overwrite problem" [High,Confirmed]  https://launchpad.net/bugs/84894
<pitti> BenC: right, see my hugging and cheering from this morning
<pitti> BenC: you rock, thanks!
<BenC> pitti: Hehe, np..so you've tested it and it passes?
<pitti> BenC: yep, and I uploaded another apport to reenable it again
<pitti> BenC: I tested with several small and large core dumps
<BenC> excellent
<doko> tfheen: please allow python2.4 and python2.5 into the archive; the changes are in the -dbg packages only. allows us to continue with our work on the other -dbg packages
<BenC> pitti: I'll push these changes upstream soon then
<pitti> BenC: cool!
<BenC> tfheen: I don't see what about linux should be uninstallable on sparc
<tfheen> BenC: http://people.ubuntu.com/~cjwatson/testing/feisty_probs.html claims it is
<tfheen> doko: doesn't look relevant for herd 4, so no, I won't let them in.
<tfheen> Keybuk: did you notice upstart ftbfs on sparc?
<Keybuk> tfheen: yeah, I got the spam about that
<Keybuk> bloody toy architectures
* ogra wonders what to do with gnome-power-amanger on sparc
<ogra> its ftbfs as well ...
<ogra> likewise on ia64
<Keybuk> is just some signal names missing on sparc used in a table so it can say "killed by TERM signal" ... just needs an ifdef or two
<tfheen> ogra: fix it? :-)
<ogra> tfheen, well
<ogra> gpm-light-sensor.c: In function 'gpm_light_sensor_get_hw':
<ogra> gpm-light-sensor.c:114: warning: cast increases required alignment of target type
<ogra> isnt really informative
<tfheen> ogra: yes, and?  Force alignment, then?
<ogra> grmbl, i was so happy that our gpm package is patch free now ...
<BenC> tfheen: sparc lrm isn't NEW'd yet or something
* ogra goes to try
<BenC> it's built, but not available
<tfheen> BenC: they ended up in failed-to-move; I'll rescue them
<BenC> tfheen: And linux-backports-modules uploaded as well
<BenC> should be instant builds
<cjwatson> ogra: no, it's certainly still supposed to be sending them to you
<tfheen> BenC: isn't l-b-m built from the regular source now?
<ogra> cjwatson, hmm
<BenC> tfheen: "regular source"?
<cjwatson> mvo: would it be possible to split the dist-upgrader source out entirely from update-manager, then?
<tfheen> BenC: l-s-2.6.20
<BenC> tfheen: No, separate package
<BenC> Need to add it to the list of ABI bump uploads
<cjwatson> mvo: I think UpdateManagerArchDependent is kind of separate, really; in any case isn't it too late for that sort of major redesign for feisty now?
<cjwatson> mvo: whereas a simple reorganisation of the source package to allow autobuilding would be quite easy and can certainly happen after feature freeze
<seb128> ogra: any reason for hwdb-client to be a native Debian package?
<ogra> seb128, not any particular oe apart from it not being used anywhere else than ubuntu systems
<ogra> *one
<seb128> ogra: usually when a package is Debian native the version has no revision though
<seb128> hwdb-client_0.6-0ubuntu23.tar.gz is weird ;)
<ogra> hmm
<pitti> Keybuk: if you have a minute, could you please look at bug 76077 and my explanation in comment 5 and tell me whether this weird behaviour is actually a feature and not a bug?
<Ubugtu> Malone bug 76077 in udev "Permissions on /dev/usblp* don't agree with cupsys" [High,Confirmed]  https://launchpad.net/bugs/76077
<mvo> cjwatson: I agree that it is too late for feisty now for the UpdateManagerArchDependent spec. how would the re-orga work? is it enough if the source package spits out a .changes file and .tar.gz for the release-upgrader? is that enough to make it work? 
<ogra> seb128, i guess its because my packaging skill were not really great when i started it ... its been like that since the beginning ...
<Keybuk> (random: how do I tell dch now that I just want -1 to become -2 ?)
<Keybuk> pitti: yeah, permissions don't seem right across the board in feisty
<Keybuk> cdroms aren't showing up in the right group, etc.
<pitti> Keybuk: also due to this rule?
<ogra> seb128, i'll fix it after herd4, thanks for the pointer, i didnt even recognize
<pitti> indeed, my CD-ROM is group 'floppy'
<seb128> ogra: no hurry, I'm looking at it because hwdb has a menu item to applications, system tools and we are supposed to have that category not used by default for menu simplication
<seb128> I'm looking on where to move it
<Keybuk> pitti: I think it has something to do with the new toplogical sysfs model
<Keybuk> some rule which never previously applied now applies
<seb128> ogra: looks like pitti did that
<ogra> seb128, yep
<pitti> Keybuk: I meant, is it really right that ATTRS{idVendor}=="0000" matches *any* vendor ID?
<pitti> seb128: hm?
<ogra> seb128, i'm not keen to have it in control-center .... but thats my personal disliking of it sinc ethe change ...
<pitti> ah, read scrollback now
<seb128> pitti: could we put the hwdb menu item somewhere else that System Tools? you unmask the menu category we try to not use for MenuSimplication
<Keybuk> pitti: define "any" -- that will match every idVendor from the device and all of its parents
<ogra> so if it belongs there put it there ...
<pitti> ogra, seb128: right, I wondered about hwdb-client being native as well, but I didn't change it when I touched it
<ogra> well, native is fine ... just not with a -XubuntuX version :)
<seb128> yeah, that was just a side note
<pitti> Keybuk: ah, so something in the chain has idVendor=0000
<Keybuk> pitti: perhaps
<Keybuk> you probably want ATTR{} in those rules anyway
<Keybuk> not ATTRS
<pitti> Keybuk: thanks; seems we might actually want ATTR
<pitti> heh
<Keybuk> the "floppy" problem, I don't know about
<pitti> seb128: I don't mind much where to put it
<Keybuk> that might be a similar bug with the scsi checking bit
<pitti> seb128: however, synaptic is also in that menu (apart from vmware)
<seb128> ogra, pitti: is that something we want to run several time or once only?
<seb128> pitti: yeah, I'm going to make mvo fix synaptic next :p
<pitti> seb128: more or less just once, except if your hw changes
<pitti> seb128: ah, I see :)
<seb128> bah
<seb128> that sucks to have a menu item for something that we run once
<mvo> seb128: hu?
<seb128> can't we have a notification area icon or something?
<seb128> mvo: we try to get Applications, System Tools not listed by default for menu simplication
<seb128> mvo: and you changing synaptic to be there apparently
<seb128> changed
<ogra> seb128, we hav a notification
<ogra> telling you to click on the menu entry
<seb128> ogra: why do we need a menu item then?
<seb128> bah
<seb128> any problem with having a notification area icon to click on?
<mvo> seb128: erh, so some apps will not be displayed anymore at all?
<ogra> it was specced like that 
<seb128> mvo: ?
<pitti> seb128: it's not what notifications are meant for
<seb128> mvo: we used to have synaptic to system, administration
<pitti> seb128: and the user might not want to go through this hassle as the very first thing he does with the computer
<seb128> pitti: menu items are not meant for things that need to be runned once neither ;)
<mvo> seb128: right and there is now this control-center that makes everything very hard to find IMHO
<pitti> seb128: I have no problem with moving it to control-center, hardware section
<seb128> mvo: could be try to adress that rather than having people doing random changes to workaround the problem?
<seb128> pitti: that feel wrong if that's something you are likely to run once
<seb128> it's going to be "in the way" and create extra confusion all the time
<cjwatson> mvo: it would just be like the debian-installer binary .changes
<mvo> seb128: fair enough, I was not aware that system tools should go away
<seb128> mvo: we did that for dapper ;)
<pitti> seb128: most of the settings in that control-center aren't run more often either
<seb128> pitti: I disagree, most are config tools
<pitti> right :)
<cjwatson> mvo: you just do 'dpkg-distaddfile whatever.tar.gz dist-upgrader -' in debian/rules
<pitti> how often do people change their screen resolution, language, or prefered fonts?
<seb128> still, those are config dialog you might want to use
<seb128> hwdb is of no use for an user
<pitti> seb128: well, if that would be the case, then we should not install it at all
<seb128> we install it because we want users to submit their config once
<pitti> people who buy new hardware or plug in another USB devices might even want to submit it again, etc.
<seb128> not because they need the tool to do something
<mvo> cjwatson: interessting, thanks! I check this out next. what would be the scope? we certainly want to not include all the backports for kde in there? 
<Riddell> mvo: oh, it doesn't need backports any more, I managed to get it to work with just a patch
<Riddell> or 4
<pitti> seb128: as I said, I don't mind moving it somewhere else or redesigning the notification etc. I just want a clear and signed-off instruction document that tells me what to do :)
* pitti hugs seb128 and thanks him for thinking about usability
<mvo> Riddell: right, and those will go into -proposed?
<Riddell> mvo: that's my plan
<mvo> Riddell: cool! thanks
<seb128> pitti: I'm going to move it to the hardware control-center category for now, I'm not happy with it though, I'll think about it
* seb128 hugs pitti back
<seb128> imho that should not be a menu item
<pitti> seb128: btw, it's already there for me
<seb128> maybe an option somewhere like popcon
<seb128> pitti: weird, it's to applications, system tools on my box
<pitti> oh, no, that thing is hal-device-manager
<pitti> seb128: right, I thought it was *also* in c-c, but that's only h-d-m (which allows you to run hwdb-client)
<mvo> I'm not very happy with the way the control-center looks currently. its just overwelming how many icons are in there
<seb128> ah ah
<seb128> h-d-m allow you to run it
<seb128> -> NoDisplay=true for hwdb-client ;)
<seb128> no need several way to do the same thing
<seb128> and it's not used often enough to justify a separate menu item
<pitti> seb128: right, we just need people to find it somehow
<seb128> h-d-m looks good enoguh if you have a notify popup pointing users there
<cjwatson> mvo: well, I was just thinking of reorganising the build process to be more like everything else in the archive, not a scope change at all
<mvo> ok
<ogra> seb128, eeek
<seb128> ogra: what?
<ogra> seb128, thats five clicks then instead of three
<seb128> well
<seb128> do you really things it makes sense to clutter the menu or shell all the time for something most users will run never or once?
<ogra> you have to open control center (takes about a minute for me with a 4200 disk and lots of applets)
<ogra> then you have to find h-d-m and click and wait another 15-20 secs 
<Riddell> tfheen: new amarok upload which fixes fail to build, I'm good for herd with that in
<seb128> we are trying to simply menus and shell to make them usable
<ogra> *then* you can click hwdb and wait again
<seb128> adding random item for things user need to run once is not the way to do that
<ogra> latest at the second click you would hae lost me if i were a new user
<seb128> yeah
<mvo> c-c has (in the default install) ~50 entries
<seb128> and as an user you would like to have that extra item in the way making your menu or shell longer and things harder to use?
<ogra> i agree that it would be fine to have a start button for it in the popup
<ogra> additionally with a hint where to find it in h-d-m 
<ogra> in case i dont want to do it now 
<seb128> ok, guys, stop focusing on the shell please
<seb128> we have menus back with uploads from today (just unmask them with alacarte)
<seb128> and we are likely to have menus by default for feisty
<ogra> YAY 
<seb128> so the question is not how slow the shell is to start
* ogra gives seb128 a loong big hug
<ogra> great decision
<bddebian> Heya
<seb128> try focusing on "do you think having that menu item is useful for an user"?
<seb128> or is it going to make the menu longer and harder to use
<seb128> for something users are likely to never look for out of the first time they are pointed to it?
<ogra> well, without the shell the most slowing down factor is gone ...
<seb128> (the shell remains available for those who want to use it BTW :p)
<ogra> but a shortcut from the popup would still be nice though ... even if it breaks policy
<ogra> does it have an extra menu entry ? 
<seb128> what has an extra menu entry? the shell? it has a menu item yes
<ogra> ah
<seb128> pitti: do you have some notification atm the moment indication to use applications, system tools?
<ogra> i think so ... there was a bug about it 
<seb128> s/indication/or indication
<seb128> ok
<ogra> pitti fixed it to say the right path ...
<seb128> so changing the menu item category would be wrong
<seb128> something else needs to be updated according to that
<ogra> not if we fix hwdb alongside
<ogra> right
<seb128> let's fix that after herd4 then
<pitti> seb128: yes, in update-notifier
<ogra> yep, i'll make a note to change it with the versioning scheme 
<ogra> pitti, not in hwdb ? 
<pitti> seb128: if we move the menu entry (or remove it), then we need to update the notification text; that's trivial, though
<pitti> ogra: no, the notification is in update-notifier
<seb128> pitti: that can wait after herd4
<pitti> seb128: *nod*
<ogra> ah
<seb128> I'll probably note the hwdb item on the topics list for the meeting
<pitti> seb128: right, thanks; it's changing a spec, so we should sign that off
<seb128> np
<seb128> mvo: the synaptic menu change can wait after herd4 as well probably ;)
<mvo> seb128: ok
<seb128> tfheen: could you approve the libxfont and control-center uploads for herd4?
<mvo> tfheen: could you please approve update-manager? its a bugfix only upload
<seb128> mvo: looks like the vte update fixed gnome-terminal ;)
<mvo> seb128: ha! great
<ogra> woah, is that still the CC meeting going on in -meeting ? O_o thats nearly 4h now ....
<Keybuk> 4h?
<Keybuk> wow
<Keybuk> they're almost half way already
<kylem> jeez.
<ogra> heh
<Keybuk> does anybody know what a type-punned pointer is?
<Keybuk> or why dereferencing one would break strict-aliasing rules?
<cjwatson> info gcc-4.1, ctrl-s type-pun
<Keybuk> cjwatson: the thing I can't figure out, is that neither pointer is a union
<dholbach> kwwii: uploaded
<cjwatson> Keybuk: and there lies the problem
<kwwii> dholbach: killer, thanks :-)
<cjwatson> Keybuk: with -fstrict-aliasing you aren't allowed to access the same bit of memory through two differently-typed variables
<Keybuk> not even if you cast them? :p
<cjwatson> Keybuk: see C99 6.5(7)
<cjwatson> no
<cjwatson> it's not about type-checking, it's about optimisations, AIUI
<Keybuk> pointer to struct, and pointer-to-first-member-of-struct are always supposed to be equivalent
<Keybuk> in fact, they're required to be
<Keybuk> isn't that important, since the warnings only coming up in test cases where I'm just stealing a random pointer and stuffing it in, on the basis that I know it's not used for anything :p
<cjwatson> I'd need to do more reading to work that out, and I need to conduct an interview in one minute ;-)
<Keybuk> heh, I have a copy of C99 here I can hit myself with if I feel so inclined
<iwj> mvo: re bug 84894> oh how annoying.  Fixing it.
<Ubugtu> Malone bug 84894 in devmapper "File overwrite problem" [High,Confirmed]  https://launchpad.net/bugs/84894
<mvo> iwj: great, thanks!
<Keybuk> tfheen: may I upload new upstart to correct sparc ftbfs
<janimo> gpocentek: hi
<janimo> could any of the source NEW reviewers take a look at hal-cups-utils please? thanks
<pitti> janimo: next archive day is tomorrow
<janimo> pitti: ok thanks. I wasn;t aware of the new schedule
<janimo> at least to me it's new :)
<pitti> tfheen: ok to upload http://pastebin.ca/353789? It fixes two easy, but very important bugs in libgphoto
<pitti> tfheen: one ruins device permissions of *all* usb devices
<iwj> mvo: Fix uploaded I think.
<mvo> iwj: nice, thanks. I will verify by re-runing the test tonight or tomorrrow
<tkamppeter_> pitti, a small detail is still needed for the renamed packages of foomatic-db to work: ubuntu-desktop needs now to depend on openprinting-ppds instead of linuxprinting.org-ppds. Can you (or someone with appropriate rights) change this? Thanks.
<pitti> tkamppeter_: can do
<pitti> ogra: I merged above change (and some previous ubuntu seed changes which look ok) into the edubuntu seeds, no conflicts; ok for me to commit or do you want to merge yourself?
<pitti> ogra: the only questionable thing IMHO is the addition of espeak
<pitti> gpocentek: here?
<ogra> pitti, if there were no conflicts its fine ...
<ogra> just go ahead
<pitti> ogra: thanks; done
<pitti> gpocentek: can you please merge the Ubuntu seed changes to xubuntu? it's nontrivial, so I didn't want to screw up
<pitti> tkamppeter_: seeds changed (except for xubuntu); this requires another -meta upload, but I think that's not important for herd-4
<pitti> tfheen: libgphoto2 tentatively uploaded, since I really recommend those fixes; please feel free to lart me and reject the upload if necessary
<pitti> mjg59: do you think we need to push the hal change for macbook into herd-4?
<tfheen> Keybuk: how invasive?
<tfheen> pitti: ok, looks relativetly sane to me.
<pitti> tfheen: justification for the patch is in the bug, if you are interested
<Keybuk> tfheen: http://rafb.net/p/xGvxOh87.html
<tfheen> Keybuk: go ahead.
<tfheen> pitti: ok, accepted.
<pitti> tfheen: merci
<pitti> mjg59: hal FTBFSes with --with-macbookpro ((.text+0x4c3): undefined reference to `gzopen')
<Keybuk> tfheen: thanks, done
<pitti> mjg59: looks like a bug in pcutils-dev (since a function from that lib wants gzopen())
<Keybuk> wow, if I reboot my mail server, I can't keep reading the mailbox
<Keybuk> who'd've thought?
<ivoks> strange strage MTA :)
<geser> pitti: if you are interested I've modified pkgmaintainermangler to work on source packages. The modified script is at http://members.ping.de/~mb/srcmaintainermangler/
<Keybuk> seb128: so, err
<Keybuk> I updated my laptop
<Keybuk> and rebooted
<Keybuk> and have no GNOME session
<BenC> cjwatson: There's no eject command in the CD's initrd...is there some other way to eject CD's that I don't know about?
<BenC> cjwatson: This is the desktop CD
<Keybuk> seb128: might not be your fault, hang on
<mvo> tfheen: if you could approve update-manager 0.57.2 that would rock. its a one-line fix
<tkamppeter__> pitti, thanks for updating the seeds, but I have still a little problem:
<cjwatson> BenC: you can't really eject the desktop CD except from break=top :-)
<tkamppeter__> If I do a general update also the update of linuxprinting.org-ppds-extra is held back though it does not have a dependency in ubuntu-desktop
<cjwatson> BenC: powerpc?
<BenC> cjwatson: No, I need to eject the CD so people can load the driver CD :)
<cjwatson> oh
<BenC> from casper-premount
<cjwatson> BenC: depend on eject and have casper's hook script copy it in
<BenC> Ok
<tkamppeter__> pitti, I have Replaces:, Provides:, and Conflicts: lporg... in the openprinting packages and in addition the transient lporg packages, is this correct?
<BenC> cjwatson: Should I do any sanity checks after they re-insert the install media to make sure it's the right CD?
<BenC> and if so, what's the best check
<cjwatson> BenC: hmm, maybe remember the contents of /cdrom/.disk/info
<cjwatson> it's not exactly a UUID but it should be a pretty good signature for this purpose
<BenC> cjwatson: Is /dev/cdrom valid at this point?
<BenC> or should I check mtab to see what the cdrom device is
<tsmithe> PriceChild, mmhmm?
<cjwatson> BenC: casper doesn't use /dev/cdrom
<tsmithe> he wants a mailing list and doesn't know where to ask
<cjwatson> BenC: see find_livefs in scripts/casper
<cjwatson> it iterates through devices and tries to guess which one to use
<cjwatson> maybe make it remember which one it used and use the same one again
<pitti> tkamppeter__: that should be fine
<BenC> cjwatson: So what device would I use for ejecting, mounting, and checking for driver-updates?
<BenC> cjwatson: I'll look around in there...maybe it does store the sys2dev
<cjwatson> shouldn't be too hard to make it store it
<sladen> it's an optical drive, there are the ioctl()s for the disk-id
<sladen> however that might make testing harder if you're using a disk-image to test
<cjwatson> which casper already does. no need to reinvent the wheel
<cjwatson> (it uses /lib/udev/cdrom_id)
<PriceChild> I'm sorry I haven't a clue where else to ask this, but how would I go about requesting the creation of a mailing list?
<BenC> cjwatson: cdrom_id might be a good way to check for the install media being re-inserted
<cjwatson> PriceChild: rt@admin.canonical.com
<PriceChild> Thanks cjwatson :)
<cjwatson> BenC: cdrom_id just gives you the capabilities of the drive
<alex-weej> does anyone have any idea how i can debug/get more info on this? https://bugs.launchpad.net/ubuntu/+source/hal/+bug/83842
<Ubugtu> Malone bug 83842 in hal "Sound devices not detected by HAL after upgrade to Feisty" [Undecided,Unconfirmed]  
<cjwatson> doesn't tell you anything useful about the disk
<BenC> ah, thought it was some if for the media
<BenC> *id
<seb128> Keybuk: GNOME b0rkage?
<Keybuk> seb128: no
<Keybuk> iwj's udev update restored the udev init script which I'd deleted
<tkamppeter__> pitti, can you test then whether your system updates smoothly, as soon as the new ubuntu-desktop is on your mirror?
<Keybuk> so I had udev being run twice => bad /dev/null permissions
<seb128> Keybuk: ok, cool
<BenC> cjwatson: livefs_root isn't run before casper-premount
<BenC> Guess I'll have to reimplement find_livefs() as a find_driver_updates()
* iwj 's ears burn.
<iwj> Keybuk: Err, did I do something wrong ?
<iwj> Also,
<iwj> python--
<iwj> Why does  x += 3  count as a binding of x and make the function fail with an UnboundLocalVariable error ?
<Keybuk> iwj: not at all, update-rc.d did something wrong as usual
<iwj> OIC
<iwj> And why is there no way of saying `I want "x" to refer to the "x" in the enclosing scope' ?
<iwj> You can only say `global' which is not the same thing at all.
<BenC> cjwatson: I have a question about the ubiquity-driver-updates spec. It mentions search for drivers in ubuntu/, but that seems to conflict with our own CD's
<BenC> cjwatson: Should I change that to ubuntu-drivers/ ?
<cjwatson> BenC: oh, right, maybe livefs_root needs to be refactored yes
<cjwatson> BenC: hmm, I'd forgotten about the ubuntu symlink on our CDs. Yes, pick something reasonable and short that doesn't clash
<BenC> cjwatson: I'm actually thinking about expanding it a little, so that the script only checkes ubuntu-drivers/<kver-abi>/
<BenC> no reason to load what might be a ton of the same package for different versions of the kernel
<BenC> cjwatson: How safe is it to assume that the installer kernel version (not flavour) is the same as the installed kernel?
<BenC> Then I also need to account for architecture
<cjwatson> BenC: in the desktop CD, you can assume that they're the same
<BenC> Is there an easy way to get the dpkg arch from initrd?
<BenC> cjwatson: I'll have to assume it everywhere or copy all of ubuntu-drivers/*/*_<arch>.deb
<cjwatson> BenC: yeah, just assume it I think
<cjwatson> BenC: oh, hmm, what if they provide multiple versions and expect those to be used on upgrade?
<cjwatson> BenC: maybe *_<arch>.deb *should* be copied to the installed system ...
<cjwatson> BenC: the architecture is DPKG_ARCH in the environment, within the initramfs
<BenC> cjwatson: Ok, thanks
<BenC> cjwatson: Would make sense, since the new packages might be needed for known security update
<cjwatson> right
<BenC> cjwatson: how about ubuntu-drivers/<kver>/*_<arch>.deb, where kver would be something like 2.6.20 (no ABI or flavour)?
<gpocentek> pitti: xubuntu seeds updated, but not shown on LP yet
<gpocentek> gpocentek: sorry for the delay
<gpocentek> err
<gpocentek> pitti: sorry for the delay ^^
<pitti> gpocentek: thank you! no need to excuse :)
<cjwatson> BenC: while you mentioned security updates, I was actually thinking of feisty -> feisty+1 upgrades ...
<cjwatson> BenC: the other option would be to save a Packages file and arrange for an apt-cdrom-style entry to appear in sources.list, but I'm a bit worried about designing that on the fly
<cjwatson> BenC: are the drivers really going to be all that huge?
<BenC> cjwatson: I'm a little worried about the potential size that ubuntu-drivers/*/*_<arch>.deb might become
<cjwatson> BenC: if you think <kver> is the best compromise, that's OK by me
<chezz99> hello
<cjwatson> tfheen: you might want to give-back debian-installer where it failed
<cjwatson> tfheen: hmm, or not, possibly
<cjwatson> BenC: could you please make storage-core-modules Provides: loop-modules?
<BenC> cjwatson: Sure thing
* cjwatson works around it for now
<cjwatson> no idea why this only just started breaking now
<BenC> cjwatson: In git
<cjwatson> thanks
<Kano> hi, where is  splitconf.pl ?
<BenC> Kano: The script for the kernel configs?
<Kano> yes
<Kano> i want another config, but how to split
<BenC> It's in the tarball for linux-source-*
<BenC> or in git
<Kano> no it is not
<Kano> pulled git
<BenC> Yes, it is
<BenC> debian/bin/splitconfig.pl
<Kano> but not under ubuntu-2.6
<BenC> yes, it is
<cjwatson> it really is, I pulled the git tree a couple of hours ago and I see it
<Kano> hmm then find must be stupid..
<cjwatson> what find invocation did you use?
<BenC> you mispelled it :)
<Kano> ubuntu-2.6# find -name splitconf.pl
<BenC> it's splitconfig.pl not splitconf.pl
<cjwatson> splitconf != splitconfig
<Kano> # Common config options automatically generated by splitconf.pl
<Kano> so who is stupid...
<cjwatson> nobody used the word "stupid" except you. kindly stop.
<BenC> Kano: Direct further questions to the ubuntu wiki, KernelTeam entry
<cjwatson> tfheen: please accept iso-scan 1.18ubuntu1 and give-back debian-installer once that's built and in the archive
<Kano> BenC: splitconf(ig).pl search has no result
<BenC> Kano: ls -l debian/bin/splitconfig.pl
<Kano> yes but how to use it
<BenC> you don't use it directly
<BenC> if you really want to, read debian/rules
<BenC> that's where it gets used
<Kano> but i have a new generic full config
<Kano> i want to try all pata drivers and no old ide code
<BenC> actually it gets used in debian/bin/oldconfig
<Kano> as even a pure sata system got a hdx device
<BenC> Kano: pure sata wont have a hdX device...it's not possible
<BenC> Kano: Most likely you have your sata controller in legacy/compatible mode
<Kano> i think the currect selection of drivers is really suboptimal
<BenC> that's a nice baseless statement
<BenC> considering we've tuned that driver list based on past releases and suggestions by upstream kernel, I wonder where you come up with that
<Kano> when cdroms stop working and even normal boot required irqpool cheat then it is not really optimal
<BenC> that has nothing to do with drivers
<BenC> well, the irqpoll option doesn't
<BenC> that's most likely a broken driver, a broken BIOS on your system, or a crappy device
<wasabi> Or a wonderful combination of all three. =)
<BenC> Kano: Either way, file bug reports...compiling your own kernel for PATA vs. IDE wont help you with those issues, nor will it allow us to fix the problem
<Kano> BenC: well i have to compile the kernel because i want to use it with etch
<BenC> Kano: Uh, you're compiling an Ubuntu kernel to use on Debian?
<Kano> yes, and i found out that that required a patch to hal, maybe because of some different config or so
<BenC> No, it required a patch to hal because upstream changed things
<BenC> it's Not ubuntu specific
<Kano> i added patch 58 or so
<wasabi> Debian's HAL/Kernel is just older.
<zakame> did anyone experience something similar to bug #84668?
<Ubugtu> Malone bug 84668 in devmapper "adds misleading double entry to swapon" [Undecided,Unconfirmed]  https://launchpad.net/bugs/84668
<Kano> sysfs something
<Kano> 2.6.20 with differnet config settings does not require that change but have no idea what option it is
<BenC> Kano: well, if you're mixing your system with ubuntu source + self compiled kernels + debian userspace with self compiled binaries, then I'm afraid I can't help you much anymore
<BenC> you're creating way more problems than I intend to help overcome
<wasabi> Yes, what part of this is Ubuntu anymore, anyways?
<Kano> BenC: to make me work with ubuntu let mc work correctly, but this tool is not always able to change dirs there
<BenC> Kano: I suggest you rm -rf debian/ in the ubuntu-2.6 git and just use make-kpkg
<Kano> hmm would be possible
<Kano> btw. ubuntu -6 kernel was not able to build with pbuilder/etch
<siretart> iwj: I'm currently trying to follow your instructions, but with the massive debug output, I'm unable to reproduce the behavior :(
<iwj> siretart: Hmmm.
<siretart> iwj: I do notice however that it becomes quite likely that one or more raid devices become degraded, so I have to add the 'missing' disc by hand
<iwj> The degraded thing is fixed in ubuntu4.
<siretart> currently I need to wait ~20min to get the device synced
<siretart> iwj: this IS with ubuntu4
<iwj> Really ?  That's odd.
<iwj> Very odd.
<iwj> Because I added --no-degraded so it oughtn't to do that at all.
<siretart> currently fscking, will recheck soon
<siretart> iwj: the funny thing is: I returned home earlier, and I did succeed to but with ubuntu3 that very one time
<siretart> without interaction that is
<Kano> BenC: btw. i do not use any ubuntu entry in debian. i look for specific patches only
<ajmitch> siretart: what behaviour were you trying to reproduce?
<siretart> ajmitch: bug 75681
<iwj> ajmitch: Failure to start md devices properly.
<Ubugtu> Malone bug 75681 in lvm2 "initramfs script: race condition between sata and md" [Undecided,Unconfirmed]  https://launchpad.net/bugs/75681
<ajmitch> hm, looks familiar
<iwj> siretart: You have something different because with yours some of them aren't arriving at all.
<siretart> ajmitch: yeah, actually you pointed me to that one ;)
<iwj> succeed that very one time> It's a race, so you're not guaranteed to lose.
<siretart> iwj: as said before, I have both stripes and mirrors, and lvm on top of the stripe
* ajmitch has an 'inactive' /dev/md1 at the moment, yet /usr/local is up & running on /dev/mapper/md|md1, which is very odd :)
<iwj> Urrr.
<siretart> actually, 2 vgs, with the root lv on the vg on the stripe
<iwj> I haven't done anything that would cause that, I think.
<iwj> And I don't understand how your lvm things aren't working either.
<iwj> Without the udev debug output it's very hard to debug these races.
<iwj> And I'm really perplexed as to what's calling mdadm without --no-degraded or whether it's starting them degraded anyway.
<siretart> I'd love to give you the debug output, and I'd love to give it another try, but I need to wait ~20min for the raid device to be resynced right now :/
<iwj> Right.
<iwj> I'm afraid it's about time for my dinner here; if you manage to get some useful info I'll be around again tomorrow.
<siretart> k, have a nice evening!
<cjwatson> tfheen: targeted https://launchpad.net/ubuntu/+source/ubiquity/+bug/84597 at herd-4, FYI; I'll sort it out tomorrow
<Ubugtu> Malone bug 84597 in ubiquity "[apport]  ubiquity crashed with AssertionError in subst()" [Undecided,Confirmed]  
<iwj> siretart: Goodnight and good luck ...
<tfheen> cjwatson: thanks; looking at iso-scan now, will give-back d-i afterwards.
<seb128> evince used to Depends on "gs-esp | gs"
<seb128> now it needs gs-esp-x
<seb128> "gs-esp-x | gs" doesn't work because "gs-esp" provides "gs" by example
<tfheen> seb128: gs-esp-x | gs (>= 0)
<seb128> would you consider that as a gs-esp bug that should not provide gs? or a new "gs-x" should be used?
<seb128> or evince Depends gs-esp-x?
<seb128> tfheen: gs (>=0) ?
<seb128> Provides are not versionned and gs-esp (non-x) Provides gs ...
<tfheen> seb128: correct, but if you have a versioned depends, you depend on the real gs.
<seb128> well, "gs-esp | gs" was gs-esp or anything else providing "gs" no?
<seb128> like gs-gpl
<tfheen> ah, ok
<tfheen> make something like gs-x, then
<seb128> right
<seb128> I'll make evince Depends on "gs-esp-x" without the "|gs" for herd4
<seb128> or we will have no gs-esp-x since it's not seeded and nothing else depends on it
<seb128> tfheen: looks fine to you?
<tfheen> hn
<tfheen> hm
<tfheen> so you need a main promotion too?
<seb128> hum?
<seb128> gs-esp-x is a new binary split for gs-esp
<seb128> and kubuntu-desktop seeded it
<seb128> so it should be fine
<tfheen> ahkay
<visik7> hi
<BenC> tfheen: Did you do the herd4 release notes?
<BenC> tfheen: If not, who could I forward an email to in order to get something added to it?
<tfheen> BenC: no, ubuntu-marketing traditionally does them.
<visik7> which memory subdivision use ubuntu kernel generic 1/3 3/1 2/2 or 4/4 ?
<tfheen> BenC: you can just edit the wiki page; /FeistyFawn/Herd4
<BenC> visik7: stock
<BenC> tfheen: what about http://www.ubuntu.com/testing/herd4 ?
<visik7> stock means 3/1 ?
<kylem> none of the above.
<kylem> we use HIGHMEM_4G...
<tfheen> BenC: it'll be moved there eventually.
<kylem> well, i guess 4/4 is what you mean.
<Nafallo> tfheen: hi! have anyone asked for a gnome-terminal give-back on amd64, ppc, ia64 and sparc?
<tfheen> Nafallo: given-back
<Nafallo> tfheen: thanks
<visik7> mmm seems 1/3
<cyberix> Aaargh. Feisty has a "Control Center".
<cyberix> It hurts me so much, I feel my soul burn
<kylem> haha.
<cyberix> Using a menu is soooo much easier than using a separate window that looks complicated.
<cyberix> Is this an upstream evil from gnome?
<kylem> indeed.
<ogra> cyberix, the menu should be back with the most recent version
<cyberix> Thank god
<ogra> yeah
<ogra> there will be a control center menuitem though ... 
<ogra> so people can still have it
<cyberix> I feel having the items in two places may be confusing.
<cyberix> But it is a _LOT_ better than having just a control center
<ogra> yep
<ogra> its a compromise
<seb128> it's all about choice
<seb128> the fact that you don't like something doesn't make it bad
<seb128> some other people like it
<ogra> rigth
<ogra> its a totally personal preference
<seb128> having the choice between menus or shell is a quite good solution
<ogra> yup
<cyberix> "I like _____ a lot because Microsoft made me like it!"
<seb128> cyberix: those users exist and there is no reason to denigrate them
* cyberix wonders, if network manager will start working with wired connections before Feisty release.
<elmo> lamont: ping
<lamont> elmo: ack
<elmo> lamont: could/why doesn't bind do the ssh style stop+restart in postinst?
<elmo> bind being down for long  periods of time over a dist-upgrade makes me cry
<lamont> sigh.  it used to do that.  /me checks yet again to rationalize things one more time
<lamont> elmo: 9.3?
<elmo> lamont: whatever's in edgy
<lamont> 9.3 then
* lamont notes in passing that in a few more releases, his firefox shortcut of 'dap' to pull up ubuntu source reports is going to be harder to explain
<lamont> elmo: ah.. 'twas dropped in going from bind 8 to bind 9
<lamont> sigh
<lamont> for the moment, I won't upload that to etch, though
<kylem> god. beep-media-player is horribly broken.
<elmo> lamont: fair enough, feisty/unstable would be nice tho ;-)
<Guardian> hello
<Guardian> i tried to boot the feisty herd3 cd
<Guardian> check for cd defects reports no error
<Guardian> right after keyboard detection, it loads modules then hangs
<Guardian> is there anything useful i can report and how ?
<lamont> elmo: bind 9.3.4 is waiting a few more days to snap from unstable to etch, is the reason
<elmo> does evince have horrific kerning for everyone or am I special?
<elmo> actually, specifically, anything exported as a PDF from abiword or OO in ubuntu, has horrific kerning when viewed in evince
<lamont> elmo: I switched back to xpdf about 2 seconds into evince-hell.  I'll consider switching back in a year or 2
<elmo> yeah, but dude, you're still using whatever the precursor to twm was :-P
<tormod> tepsipakki: I am running xorg 7.2 now, on a laptop with ATI Radeon X700. Great, all seems to run fine!
#ubuntu-devel 2007-02-14
<mjg59> crimsun: Core 2 Macbook Pro - no sound with current feisty kernel. What do you need?
<crimsun> mjg59: the realtek issues are in my queue (mentioned to Ben yesterday when I emailed him the first batch)
<mjg59> crimsun: Winning, thanks!
<crimsun> sigmatel, too.
<TheMuso> c
<LaserJock> TheMuso: oh no, not this again
<TheMuso> LaserJock: heh
<pochu> mdz: do I leave open bug 84992 (apport)
<Ubugtu> Malone bug 84992 in apport "Apport not working due to network problem" [High,Confirmed]  https://launchpad.net/bugs/84992
<Eons> hi, does anybody know if nvidia-drivers are ok in feisty? last time I used them, they crashed when an app went fullscreen 
<jdong> could a archive deity perform backport bug 83554?
<Ubugtu> Malone bug 83554 in edgy-backports "KTorrent 2.1" [Undecided,In progress]  https://launchpad.net/bugs/83554
<jdong> (high demand)
<Kano> so tested a kernel without IDE support and PATA full active. on P965 and P865 no problems - but with former selection
<Kano> formerly problematic
<jdong> Kano: sweet, that's awesome to hear :)
<Kano> btw not my systems
<Kano> but others reported it
<jdong> aww Kano , no Core 2 Duo at your disposal? :)
<Kano> http://kanotix.com/files/fix/kernel-update-pack-noide/source/changes.tar.gz
<Kano> jdong: no, x2
<Kano> abi change for generic only 
<Kano> precompiled for etch too, but i think you would not use that ;)
<Kano> as long as mc does have problems with changing into long dir names (not always, but too often), i prefer etch
<Kano> have no idea what the problem is with feisty
<Kano> btw. that test changes are very extreme, maybe use it only for testing 
<Kano> enabled experimental drivers too
<Kano> no problems ripping audiocd here, that has been problematic with old pata code
<Kano> i tested it on nforce3
<keescook> who do I need to talk to about universe UVFEs?
* keescook moves to #u-motu
<stub> Launchpad will be going down in 15 minutes for a scheduled code update. Estimated downtime is 15 minutes.
<fabbione> morning
<dholbach> good morning
<Burgundavia> morning dholbach
<dholbach> hey Burgundavia
<dholbach> hmmmm, shiny usplash on amd64
<tfheen> argh, when did ubuntu-desktop become uninstallable?
<kwwii> dholbach: just pushed a new usplash - the final one it seems :-)
<dholbach> kwwii: yoohoo :)
<kwwii> now that is a good way to start the day ;-)
<dholbach> kwwii: uploaded
<kwwii> dholbach: excellent, thanks :-)
<Kagou> hi
<tfheen> dholbach: are you sure?  I can't see it.
<dholbach> usplash-theme-ubuntu 0.12?
<tepsipakki> sweet i810 and -modesetting are about to merge -> -intel
<dholbach> i definitely uploaded it
<dholbach> Successfully uploaded usplash-theme-ubuntu_0.12.dsc to upload.ubuntu.com.
<dholbach> Successfully uploaded usplash-theme-ubuntu_0.12.tar.gz to upload.ubuntu.com.
<dholbach> Successfully uploaded usplash-theme-ubuntu_0.12_source.changes to upload.ubuntu.com.
<dholbach> tfheen: I can re-upload if you like
<tfheen> dholbach: hmm, weird, it's not in unapproved
<tfheen> dholbach: please.
<dholbach> done
<dholbach> tfheen: better?
<tfheen> no, I need to investigate.
<tfheen> but first I need to pop out for an hour or so.
<dholbach> kwwii's mail address is Kenneth Wimer <wimer@kde.org> and I sponsored with my usual key
<dholbach> hmmh
<dholbach> I think we're seeing this only with sponsored uploads, right?
<dholbach> ok see you later
<dholbach> brb
<robitaille> Anyone knows the actual title of sabdfl at canonical?  ceo?  president? person in charge?
<mdke> "Mark"?
<kwwii> boss-man :p
<robitaille> I'm trying to be factually correct for a fridge article.  Right now I have "the man behind Ubuntu and Canonical" :)
<mdke> "founder of Ubuntu" seems to appear on the Linspire press release
<Lure> robitaille: CEO, according to other news sites: http://www.redherring.com/Article.aspx?a=20495&hed=Linux%3A+Ubuntu+Founder+On+Microsoft+%E2%80%9CChallenge%E2%80%9D+
<kwwii> sounds better than "Fearless leader of merry men"
<robitaille> Lure...I have seen CEO before, but never in actual ubuntu sites...and his official bio doesn't say.
<mdke> CEO is also on https://wiki.ubuntu.com/CanonicalStaff. no doubt someone who actually works at Canonical will answer your question :D
<pitti> Good morning
<pitti> ugh, why is my desktop so damn slow after yesterday's dist-upgrade?
<dholbach> pitti: what especially?
<crimsun> if you're experiencing audio glitches and hitches in the mouse cursor movement, try stopping apport.
<pitti> dholbach: switching desktops, typing characters into terminal/xchat etc.
<pitti> crimsun: hm, mouse works fine, and apport is not running ATM
<dholbach> pitti: i wondered myself - I did a fresh install on my new amd64 and expected it to be blatantly fast, but ... hm - I'm not so very much impressed right now :)
<pitti> dholbach: I switched from nvidia to nv yesterday (new kernel didn't yet have lrm), and it got a little slower; but today it's really sluggish...
<dholbach> i usually use nv
<mvo> freedom lover!
<dholbach> yeah
<pitti> dholbach: nv with Xv is broken at least for me (comb effect), but mplayer with SDL backend works fine
<pitti> dholbach: I just can't use Totem with nv, but that's something I can live with
<dholbach> hmmm strange
<dholbach> totem works fine for me (xv with nv)
<pitti> dholbach: even fullscreen?
<pitti> dholbach: as soon as I scale a video to more than, say 1.5 times the original size, I get huge comb effects
<pitti> hmm, X.org uses 100% cpu if I merely scroll down some lines in a terminal
<cjwatson> tfheen: process-upload is commented out in lp_queue's crontab, which is why usplash-theme-ubuntu_0.12 isn't appearing. Do you know why?
<cjwatson> I see the publisher's commented out too
<tfheen> cjwatson: no idea.
<tfheen> cjwatson: do you have any idea why /testing/feisty_probs claims ubuntu-desktop is uninstallable?  It's not from a freshly bootstrapped chroot.
<cjwatson> tfheen: it says that linuxprinting.org-ppds is uninstallable, so I'd start there
* siretart noticed yesterday that aptitude felt like removing ubuntu-desktop. might be a related problem. 
<cjwatson> tfheen: IIRC from conversations yesterday that was being changed to openprinting-ppds, so maybe just a metapackage update is needed
<tfheen> : tfheen@golem ~ > apt-cache show linuxprinting.org-ppds | grep Task
<tfheen> : tfheen@golem ~ >
<tfheen> so it's not part of ubuntu-desktop any more.
<cjwatson> ubuntu-desktop still depends on it here
<pitti> cjwatson, tfheen: I changed the seeds yesterday
<tfheen> argh
<tfheen> pitti: you need to upload -meta too.
<pitti> cjwatson, tfheen: but yesterday's foomatic-db upload reintroduced the old names as transitional packags
<tfheen> can you do that now?
<cjwatson> pitti: ... which apparently are uninstallable
<tfheen> pitti: yes, which C/F/R the old ones.
<pitti> that's why I didn't bother with a -meta upload, since it's not too important
<pitti> ah, indeed
<pitti> tfheen: sorry; doing now
<cjwatson> fixing openprinting-ppds' Conflicts to be versioned << first-transitional-version would be good too
<cjwatson> (and -extra)
<cjwatson> Replaces should probably be versioned too
<pitti> right
* pitti does that as well
<pitti> cjwatson: http://paste.stgraber.org/60
<pitti> cjwatson: (had to change Maintianer: too, my local dpkg already refuses to build the previous one)
<pitti> tfheen: ^ ok for uploading?
<tfheen> pitti: yes.
<tfheen> pitti: and if we have to set original-maintainer, it should be possible to just set it sans 
<pitti> tfheen: foomatic-db, {,k}ubuntu-meta uploaded, edubuntu-meta in the works
<tfheen> X-SBC-blah
<cjwatson> it should? will it appear in the .dsc if you do that?
<pitti> tfheen: how so?
<cjwatson> I would have thought dpkg-gencontrol would ignore i
<cjwatson> t
<pitti> only XS- will make it appear in the .dsc
<tfheen> pitti: having to add X-SBC-headers to anything we upload is crack.
<tfheen> it should then just be a regular header in dpkg.
<pitti> B is not strictly necessary since pkgbinarymangler does it, but it ensures consistent local builds
<cjwatson> oh you mean "should" as in "ought to, in the future"
<tfheen> cjwatson: yes.
<pitti> ah, sure
<pitti> tfheen: this topic will appear on tomorrow's distro team meeting anyway, I have some things to discuss about it
<tfheen> pitti: goodie
<pitti> tfheen: edubuntu-meta is up
<tfheen> kwwii,dholbach: I just rejected the second usplash-theme-ubuntu which showed up.  No need to get worried about getting both an accept and a reject mail.
<tfheen> kwwii,dholbach: JFYI.
<dholbach> alright
<Riddell> pitti: would you be able to do another kubuntu-meta update, I had to change the seeds to save size but the source to your recent upload isn't on launchpad yet
<pitti> Riddell: sure
<pitti> tfheen: xubuntu-meta updated as well (oh my, this was very out of date)
<tfheen> pitti: cheers
<giftnudel> Is there a good point to start when a "make" fails but a second "make" (without anything else) succeeds?
<dholbach> Happy HugDay!
<pitti> Riddell, tfheen: new kubuntu-meta uploaded with Jonathan's recent change
<tfheen> pitti: ook
<ogra> OH CRAP !
* ogra just rsynced the serveraddon CD over his server CD
<jsgotangco> crap indeed
<ogra> pitti, i see you did a lot of -meta uploads, are you planning to do edubuntu as well ?
<pitti> ogra: I did
<ogra> ohg, my evo filter sorted it wrong
<ogra> indeed
<ogra> thanks :)
<ogra> seb128, bug 76632, any idea why the socket isnt there ?
<Ubugtu> Malone bug 76632 in gnome-screensaver "screen does not unlock after locking" [High,Confirmed]  https://launchpad.net/bugs/76632
<ogra> (third last comment)
<seb128> ogra: we moved it to /var/run
<ogra> ouch, ok
<ogra> i'll check gss ....
<seb128> I didn't realize gnome-screensaver was using it, sorry
<ogra> me neither :)
<seb128> ogra: it must have /tmp/.gdm_socket hardcoded
<ogra> looks like
<pitti> urgh
<seb128> change it to /var/run/.gdm_socket
<ogra> i'll fix
<pitti> seb128: that smells like an easy gdm DoS 
<seb128> pitti: what do you mean? using a socket? or storing it to /var/run?
<pitti> seb128: hardcoded file names in /tmp
<ogra> src/cut-n-paste/gdm-queue.c:#define GDM_SOCKET_FILENAME "/tmp/.gdm_socket"
<ogra> tsk
<tfheen> seb128: why .gdm_socket?  Hidden files are ugly.
<seb128> pitti: well, now they are hardcoded to /var/run :p
<pitti> seb128: that's fine, /var/run is only root-writable
<seb128> tfheen: I was thinking the same, I'll change it for "gdm_socket" but after herd4
<seb128> or do you want gdm and gnome-session changed now?
<tfheen> seb128: no, after herd 4 is fine.
<seb128> ok
<tfheen> but I'd like a working gss now.
<tfheen> ogra: ^^ can you do that now?
<seb128> tfheen: ogra is on it apparently
<ogra> tfheen, uploading
<tfheen> cheers
<seb128> tfheen: I've done a gnome-cups-manager upload which install the .desktop at the correct place so it's listed by the new control-center shell (with a fixed category) if you want to approve it for herd4
<tfheen> seb128: accepted.
<seb128> thank you
<ogra> pitti, bug 85006, seems there is a bashism in hal
<Ubugtu> Malone bug 85006 in gnome-power-manager "gnome-power-manager and gnome-brightness applet not changing brightness" [Undecided,Unconfirmed]  https://launchpad.net/bugs/85006
<pitti> ogra: that was fixed in hal 0.5.8.1-4ubuntu3 three weeks ago
<pitti> ogra: thanks for the pointer, I dup it to 68617
<ogra> pitti, ah, ok, sorry for the noise then
<ogra> yeah
<ogra> pitti, and husghsie asked me if we plan to ship hal-info in feisty
<pitti> ogra: no worries, thanks for the pointer -- one bug less :)
<pitti> ogra: ~/ubuntu/hal/hal/build-tree/hal-0.5.8.1$ find -name hal-info* -> no hits
<ogra> strange ... he knows which version we ship .... is it a separate source ?
<janimo> ogra, apparently yes http://gitweb.freedesktop.org/?p=hal-info.git;a=summary
<ogra> aha
<ogra> thats a lot of fdi files ...
<ogra> which incorporate some of our patches even .... nice
<K-Rich> i think there is an isure with the archives.ubuntu.com servers .... i keep getting tcp hits from archive.ubuntu.com on random ports in the 40000 - 60000 range.
<K-Rich> s/isure/issue
<ogra> pitti, i think it makes sense to have these extra fdi files ... but they will clash with some of our existing hal patches
<pitti> ogra: aaaah
<tfheen> mjg59: would it be painful to make usplash use 16bpp images and/or would it break suspend/resume?
<pitti> ogra: you mean the hal-info git repo
<ogra> yep
<pitti> ogra: the hal upstream release is the hal plus the hal-info git repos combined
<tfheen> K-Rich: what are the source ports?
<ogra> aaah !
<pitti> ogra: it's just separate that guys like us can commit to hal-info, but not to hal
<pitti> s/that/so that/
<ogra> so we actually ship it
<pitti> ogra: yes, of course
<pitti> these FDIs are very important
<pitti> ogra: I regularly submit new music players as git patches against hal-info and such
<K-Rich> tfheen, one sec
<ogra> well, some of our patches look a bit different ... 
<pitti> ogra: sorry, I thought you meant a new program hal-info
<pitti> ogra: right, that's mostly because 0.5.8.1 is really ages old
<pitti> upstream should really do a new release
<ogra> well, since i never heard of it before hughsie asked i didnt know if its a program or what :)
<pitti> then we can drop 80% of our giant patch collection
<ogra> would you pull it into feisty ?
<pitti> asac: I would love you forever if you could take a look at bug 81207; I'm lost with that...
<Ubugtu> Malone bug 81207 in apport "webbrowser fails to open for system crash when it runs as root" [High,Confirmed]  https://launchpad.net/bugs/81207
<pitti> ogra: you mean using hal-info git head and rebasing our patches? well, if it helps us to fix some bugs, sure
<pitti> ogra: but I guess that would need to be accompanied by source code patches
<pitti> hi tkamppeter 
<ogra> pitti, i meant a new upstream :)
<tkamppeter> hi, pitti
<asac> pitti: looking
<pitti> ogra: oh, not sure; it has the potential for a lot of bug fixes, but also a lot of regressions; it's a core part of our system now...
<ogra> yep
* asac has fear to run pittis script ;)
<ogra> seb128, wow, not having the socket available has really weird sideeffects in gss
<pitti> asac: of course you should take a look at it frist
<pitti> asac: and remove all the rm -rf ~ commands :-D
<seb128> ogra: yeah :/
<ogra> like if i kill gnome-screensaver from the console after i cant unlock, the dialog window stays
<janimo> tkamppeter: hi, for bugs such as 83960 is it enough to post an xml to lp? Or do you prefer directly to openprinting upstream?
<Fujitsu> ogra: You need to kill g-s and g-s-d.
<ogra> Fujitsu, well ... g-s-d should die with its parent :)
<Fujitsu> It should.
<Fujitsu> (and it should also unlock when asked :P)
<ogra> but it hangs looking for the socket ... 
<Fujitsu> Sounds like fun to debug.
<ogra> easy to debug ... 
<ogra> but that code needs a lot of overhaul ...
<pitti> Hobbsee: happy Valentine's day! 
<ogra> it should use different searchpaths for the socket and refuse to lock if its not there ...
<K-Rich> tfheen, where do i find my firewall log files (i use firestarter)
<tfheen> K-Rich: no idea, I don't use firewalls.
<Hobbsee> hey pitti :)
<Hobbsee> pitti: happy valentine's day to you too :)
* Hobbsee doesnt have a valentine :P
* Hobbsee hugs pitti, ogra and tfheen 
* tfheen bounces around Hobbsee and is hugged.
<Hobbsee> hehe
<tfheen> how's Sydney today?
* ogra hugs back
* pitti got a self-made chocolate cake from his gf *yummy*
<Hobbsee> nice!
<Hobbsee> tfheen: dunno, havent seen much of it.  been working
<Hobbsee> brb, lunch
<Hobbsee> (yes, it's 10.07pm here)
<tfheen> I got slightly confused about that, yes.
<Hobbsee> hehe
<janimo> pitti, for a typical main incl review are the debs perused as well or just the source package? I was wondering if NEW source processing and MIR can happen in one step :D
<ogra> slomo, wow, you are fast :)
<K-Rich> tfheen, well it seems to be random ports in the 30000 - 60000 range
<pitti> janimo: I always check the .debs for promotion
<tfheen> K-Rich: I doubt the source ports are in that range.
<janimo> pitti, ok thanks
<slomo> ogra: i just saw the bug in #ubuntu-bugs by accident ;)
<pitti> janimo: so binary NEW and promotion can happen at the same time
<ogra> heh
<mneptok> Hobbsee: you can be *MY* valentine!
<K-Rich> tfheen, Time: Feb 14 04:10:53 Source: 91.189.89.182 Destination: 10.0.0.3 In IF: eth0 Out IF:  Port: 60518 Length: 44 ToS: 0x00 Protocol: TCP Service: Unknown
<Hobbsee> mneptok: you wish.
<asac> pitti: thats a bit strange ... indeed
* mneptok watches Hobbsee re-assess homosexuality
<Hobbsee> mneptok: errrr.....?
<pitti> asac: it works fine if I run 'firefox <url>' directly
<mneptok> Hobbsee: ... as an alternative.
<K-Rich> tfheen, Time: Feb 14 04:12:22 Source: 91.189.89.182 Destination: 10.0.0.3 In IF: eth0 Out IF:  Port: 52343 Length: 44 ToS: 0x00 Protocol: TCP Service: Unknown
<pitti> asac: so there must be something ffox wants from the environment or parent process that I don't know about
<Hobbsee> mneptok: oh, in response to you.  gotcha.
<asac> pitti: yep
<tfheen> K-Rich: I don't think that's the source port, just the destination port.
<pitti> asac: hm, it just occured to me that in the sudo script, the calling process does not have all the auxiliary groups that the running firefox has
<K-Rich> Time: Feb 14 04:13:23 Source: 91.189.89.182 Destination: 10.0.0.3 In IF: eth0 Out IF:  Port: 52352 Length: 44 ToS: 0x00 Protocol: TCP Service: Unknown
<StevenK> Which probably means it's an ACK.
<StevenK> Based on the port, destination and length.
<asac> pitti: firefox detects the lock in profile dir, but fails to run the remote command against the already running instance
<K-Rich> tfheen, very odd, happens when i 'sudo aptitude update'
<pitti> asac: if I call epiphany -n in the script, then it works and returns immediately, so it's not something deep in the mozembed stuff
<tfheen> K-Rich: so it's legal traffic.
<tfheen> K-Rich: you have a misconfigured firewall; go to #ubuntu for support, please.
<pitti> Riddell: could you download http://people.ubuntu.com/~pitti/tmp/ubuntu-bug and check whether it correctly invokes apport-qt in bug filing mode for you? (e. g. 'ubuntu-bug -p bash')
<Riddell> pitti: apport-qt pops up briefly saying "uploading" then konqueror starts up
<tfheen> cjwatson: you were going to get https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/84597 fixed this morning, weren't you?
<Ubugtu> Malone bug 84597 in ubiquity "[apport]  ubiquity crashed with AssertionError in subst()" [Undecided,Confirmed]  
<pitti> Riddell: that sounds right
<pitti> Riddell: and the dialog was okay, looked like apport-qt?
<pitti> Riddell: I plan to stuff this script into /usr/bin, so that people can call it from the shell, and we also need it for firefox 'Report a bug...' menu integration
<pitti> Riddell: a quick eyeballing of the script is appreciated, too
<cjwatson> tfheen: yeah, working on it
<tfheen> cjwatson: thanks.
<pitti> Riddell: first I test pgrep -u `id -u` -x ksmserver >/dev/null, and fall back to pure [ -x apport-qt ]  if neither gnome-session nor ksmserver is running
<StevenK> pitti: What if gnome-session is the process that just crashed? :-)
<Riddell> pitti: all looks good to me
<pitti> StevenK: then it'll still DTRT in the usual case
<Riddell> unless the user has two X session running, one with gnome and one with kde
<Riddell> but even so it's not a problem to have the gtk frontend on kde
<pitti> StevenK: worst case is that if you run KDE and have apport-gtk installed, then you'll get the gtk interface. No big deal, I'd say
<pitti> Riddell: right
<StevenK> Riddell: I thought KDE rolled over and killed Gnome in that case? :-P
* pitti rings the bell for "DE war, round 8320427"
<Riddell> KDE doesn't roll over for anybody
<StevenK> pitti: :-)
<pitti> Riddell: thanks for checking
<StevenK> Riddell: I won't reply what I'm thinking. :-P
<seb128> pitti: .de war? you german guys... :p
<StevenK> Bwahaha
<pitti> seb128: DE, not .de !!!111!
<seb128> ah :)
* pitti hugs seb128
* seb128 hugs pitti back
* pitti ponders abandoning Gnome, it still cannot open the Rhythmbox cover and lyrics plugins
<pitti> seb128: (just kidding)
* tfheen kicks the slacking buildds.
<Ng> pitti: it's kicking ass in feisty here. the cover one at least, not tried lyrics ;)
<seb128> pitti: I think you might face http://bugzilla.gnome.org/show_bug.cgi?id=404932
<Ubugtu> Gnome bug 404932 in Programmatic interfaces "Python modules do not work on 64-bit  and Python 2.5" [Normal,Resolved: fixed]  
<pitti> Ng: it worked before, and suddenly stopped working a while ago; however, (kicks ass)++
<seb128> pitti: which is fixed upstream and will be fixed for feisty
<Ng> pitti: harsh :(
<pitti> seb128: aaaah
<seb128> pitti: while ago being the switch to python2.5?
<pitti> seb128: entirely possible
<seb128> I'll ping you to test when the new version will be to feisty
<pitti> seb128: btw, do you use rb yourself?
<seb128> yep
<seb128> but on i386 :)
<pitti> seb128: I find it quite annoying that an album doesn't start playing any more when I double-click on it
<pitti> seb128: is that a bug or a feature?
* pitti is in whining mood today, sorry
* pitti fixes some apport bugs in exchange
<Fujitsu> pitti: I'd hope that it was a bug, as it was nice to be able to do that.
<seb128> a bug I would say, I double click on the first track usually, I didn't know that double click on the album was doing something ;)
<seb128> pitti: no problem don't worry ;)
* pitti files a 'Low' bug
<Fujitsu> Artist/Album double-clicking played all the tracks listed.
<pitti> Fujitsu: right, that was really handy
<seb128> pitti: don't bother
<seb128> pitti: http://bugzilla.gnome.org/show_bug.cgi?id=404753 fixed in SVN
<Ubugtu> Gnome bug 404753 in general "Can't double click artist/album in browser to play" [Normal,Resolved: fixed]  
<pitti> seb128: these Gnome dudes rock
<seb128> ;)
<cjwatson> Riddell,mvo: software-properties appears to be telling people to report bugs on ubiquity. Could you please make it stop doing that?
<cjwatson> ./data/designer/crashdialog.ui:102:        <string>&lt;a href="https://launchpad.net/ubuntu/+source/ubiquity/+filebug">https://launchpad.net/ubuntu/+source/software-properties/+filebug&lt;/a></string>
<Riddell> cjwatson: oh sorry, my fault, I'll fix it now in bzr
<cjwatson> tfheen: please let a fix for that through - it's beginning to seriously piss me off :)
<tfheen> cjwatson: will do.
<cjwatson> Riddell: note a number of crash reports that I've been getting, reassigned
<geser> pitti: have you had time to review my script to modify the Maintainer field in source packages?
<pitti> geser: oh, I wasn't even aware of it
<geser> pitti: http://members.ping.de/~mb/srcmaintainermangler/
<pitti> geser: I wrote my own script on Monday (just took me some 15 minutes, not a biggie)
<pitti> geser: thanks!
<geser> it's based on pkgmaintermangler
<pitti> geser: doko already had a script for doing mass uploads, so I just adapted that
<geser> is it available somewhere?
* pitti scp's
<pitti> geser: http://people.ubuntu.com/~pitti/tmp/update-maintainer-transition
<davmor2> Query:  can anyone let me know what is currently happening with nm not  working with rt2500 wireless cards?  Is there anything that can be done?
<mvo> Riddell: will you fix it in the ~ubuntu-core-dev repo?
<Riddell> mvo: yes
<cjwatson> geser: I'm not really happy with mass uploads for this
<cjwatson> we shouldn't be causing that kind of mirror hit
<geser> cjwatson: I don't plan to mass-upload anything
<cjwatson> and we definitely should only be modifying packages that already have *ubuntu* versions, which that script doesn't seem to do
<geser> my script only automates the changing of the maintainer field
<cjwatson> ok, just saying :)
<pitti> cjwatson: right, I doubt the usefulness of mass-upload as well
<seb128> tfheen: I've uploaded a control-center update which fixes gnome-default-applications-properties (it was looking for the applications list to the wrong place), would be nice to accept for herd4
<pitti> cjwatson: mdz asked me to do that, but the request was a bit ambiguous
<Fujitsu> Shouldn't there be some way for DDs to say `I don't want my fields mangled'?
<pitti> cjwatson: that's why I'll put it on tomorrow's agenda
<StevenK> There is
<Fujitsu> StevenK: Not for source packages.
<geser> pitti's script also misses packages using debian/control.in to generate debian/control
<tfheen> seb128: ok
<pitti> geser: oh, right
<elmo> I will track down and hurt anyone who mass uploads packages just to change the maintainer field
<Fujitsu> elmo: That's the spirit.
<StevenK> elmo: Is that a promise? :-)
<seb128> pitti: run away from elmo ;)
<pitti> seb128: as I said, I don't think it makes sense
<kwwii> pitti can run faster than elmo, I think
<pitti> seb128: but I'll do it if mdz wants me to :)
<seb128> pitti: I was just joking, don't worry ;)
* seb128 hugs pitti
<tfheen> pitti: nope, running away from James doesn't make sense.  He'll get to you eventually. :-)
<pitti> heh
<pitti> 'huh, I can't login to the DC any more, nor upload shit'
<pitti> tfheen: you read BofH as well, I figure :-D
<tfheen> pitti: not for a long time, but yeah.
<cjwatson> tfheen: fixed that ubiquity bug in bzr, I think, but I need to arrange to test it somehow
<tfheen> cjwatson: please.
<jsgotangco> greetings sabdfl
<tfheen> cjwatson: just take your time, we need get soyuz fixed too.
<sabdfl> hi all
<Fujitsu> Hey sabdfl.
<geser> I've a question about mozilla-browser (universe) in feisty: Debian removed it already from unstable and replaced it by iceape (aka seamonkey). IMHO we should do the same and replace it also by iceape. Any other opinions on this?
<pitti> geser: mdz recently wrote the current state of affairs to -devel: we don't need to rename our firefox/tbird/moz apps
<geser> this way it would be less work for the MOTUs as we didn't to rebrand iceape back to seamonkey
<pitti> geser: right, it'd be easier to sync
<geser> it's not only about renaming mozilla-browser is abandoned upstream
<pitti> geser: I would actually prefer to entirely remove it
<pitti> not sure if reverse dependencies allow that
<Riddell> tfheen, cjwatson, mvo: software-properties uploaded
<pitti> geser: actually doesn't look too bad
<sabdfl> howdy Fujitsu
<pitti> geser: gnash, gtk2hs, swfdec0.3, videolink, webhttrack
<pitti> geser: these are the sources we need to fix, and then there's a whole bunch of packages (plugins, translations) that could just be removed as well
<pitti> geser: most packages can hopefully be built against firefox-dev instead of mozilla-dev
<geser> pitti: will check the rdepends of mozilla-browser and file bugs for removal or upload fixed packages
<pitti> geser: wait, I have a script for that, I'll put the output somewhere
<pitti> geser: http://people.ubuntu.com/~pitti/tmp/mozilla-rdepends.txt
<geser> pitti: thanks
<pitti> geser: most important are those five r-build-deps on mozilla-dev
<pitti> geser: thanks for taking care of this; the current mozilla is so old, noone should use it any more in feisty
<mvo> tfheen: the latest dist-upgrader fixes bug #66783 (targetted herd-4). please consider it for approval
<Ubugtu> Malone bug 66783 in update-manager "considers dapper-commercial a third party repository and disables it" [Medium,Fix committed]  https://launchpad.net/bugs/66783
<tfheen> mvo: oh, good.
<mvo> thanks
<mjg59> jono: Excellent, I will be seeing you in Ireland
<pitti> tfheen: not sure what you think about http://paste.ubuntu-nl.org/5710/? it adds a script and fixes some bugs
<pitti> tfheen: (test suite passes and everything, of course)
<tfheen> pitti: I'd like to get herd 4 out soonish so unless there are bits there you really want, can it wait?
<tfheen> pitti: I'll be happy to take it if we need to wait for other bits to hit the archive, though
<tfheen> pitti: actually, just upload it, since we need ubiquity
<pitti> tfheen: not terribly urgent as long as edge.launchpad.net doesn't break again
<pitti> oh, great
<pitti> tfheen: uploaded; feel free to accept or defer as you see fit
<tfheen> cheers
<cjwatson> ok, so half of my ubiquity fix worked ...
* cjwatson hunts down the bug in the other half
<sabdfl> seb128: anyone already reported a bug in gnome-screensaver where unlocking the screen fails?
<seb128> sabdfl: it has been fixed like 2 hours ago
<pitti> that sounds like the /tmp -> /var/run socket change from this morning?
<seb128> I'm not sure how a running gnome-screensaver handle the socket change though :/
<cjwatson> tfheen: http://paste.ubuntu-nl.org/5714/
<sabdfl> kill means it's no longer running :-)
<sabdfl> thanks seb128
<seb128> np
<cjwatson> tfheen: tested, works for me
<pitti> asac: yay, there's a solution for bug 81207
<Ubugtu> Malone bug 81207 in apport "webbrowser fails to open for system crash when it runs as root" [High,In progress]  https://launchpad.net/bugs/81207
<tfheen> cjwatson: upload away
<pitti> asac: as simple as using firefox' sudo support instead of working around it :)
<davmor2> does anyone know the current status of rt2500 cards not working with network manager?  Is there anything that can be done to make them work together?
<jdong> rt2500 doesn't like interface bouncing when under a PREEMPt or SMP kernel.
<jdong> i.e. you can't bring it up, down, up
<jdong> and that pattern is pretty common in NetworkManager usage.
<davmor2> so is the only fix to remove network manager then?  Only there are a few bugs about this issue.
<Treenaks> jdong: also, that's a _bad_ driver bug then
<jdong> Treenaks: VERY BAD driver bug
<jdong> kernel panic on bouncing
<asac> pitti: great ... but could you track down what went wrong?
<jdong> radio loss after a few minutes
<jdong> of torrent strength activity
<pitti> asac: no, I couldn't
<jdong> davmor2: it's an open source driver so you can work with rt2x00.serialmonkey.net community
<asac> pitti: i however ... afaik if you just run sudo firefox ... it will still take profile dir from root user
<jdong> davmor2: but it's not something we here at Ubuntu have the resources or power to fix :)
<jdong> sorry 
<asac> pitti: if that is ok, then all is fine.
* jdong much rather have his madwifi blobs :D
<davmor2> jdong: not me specifically with the problem I'm just trying to stay on top of some bugs
<pitti> asac: no, the whole point of that juggling is to take the user's profile dir
<pitti> asac: however, 'sudo -u martin firefox url' seems to DTRT
<davmor2> jdong: So is it worth asking everyone with issues in this set up to post bugs there?
<asac> pitti: interesting ... maybe I forgot to remove some tweaks in your python script when I last tried
<seb128> ok, time for lunch and some sport, bbl
<jdong> davmor2: they know about it
<jdong> davmor2: at least they did 2 years ago when I bugged them about it
<jdong> davmor2: I used to be a rt2500 user
<mjg59> The driver's been basically rewritten since then
<mjg59> But if there are bugs, then yes, please do file them
<mjg59> Assuming there isn't a duplicate already
<tfheen> mjg59: did you see my question about usplash and 16/24 bit from this morning?
<tkamppeter> pitti, biff
<mjg59> tfheen: Nope
<mjg59> tfheen: Ah, got it. 
<mjg59> tfheen: By default, usplash on x86/amd64 will use 16-bit unless it can't get the 16-bit mode
<mjg59> tfheen: So it's not impossible to use 16-bit pictures. However, there's no guarantee that you'll get a 16-bit picture, and I'm not sure what the situation is on ppc
<mjg59> tfheen: Why do you ask?
<pitti> tkamppeter: can you get tfheen's approval for them? then I'll upload immediately
<tfheen> mjg59: because kwwii would like to use 16 bit pictures.
<mjg59> Hm.
<mjg59> I don't think we can guarantee it.
<tfheen> mjg59: is there hardware which doesn't like 16-bit vesa modes?
<mjg59> I expect that there's some amount. It's very hard to tell.
<Robot101> there's always some hardware that hates you :)
<mjg59> And there's still the framebuffer issue
<tfheen> which fb issue?
<mjg59> I think providing 16-bit artwork with a 256 colour fallback would be fine
<tfheen> ok
<mjg59> Though there'd need to be some code for dealing with that
<tfheen> kwwii: ^^ does this sound sane to you?
<tfheen> so hardware won't let us switch to 16 bit and then blow up?  Hopefully?
<kwwii> tfheen: well, it's double the work and means making two different layouts but it is a good start
<kwwii> for feisty we've got the 256 version looking pretty good
<tfheen> kwwii: if we discover that most of the hardware supports 16 bit, I presume we can have a 256 colour which you put less effort into
<kwwii> tfheen: right
<kwwii> this would be for feisty+1 anyway, or?
<tfheen> depends on whether I can sneak it past myself or not.  I suspect feisty+1
<kwwii> tfheen: lol
<tfheen> mjg59: also, do you have any qualms about adding jpeg and/or png support directly to usplash?
<tfheen> that is, about it being added, I'm not telling you to do it. :-)
<sladen> there's a single-file PNG loader here:  
<sladen> http://student.kuleuven.be/~m0216922/pngloader/
<kwwii> if we are going to go with so many colors it would be better to have jpeg support I think
<kwwii> the pngs might get quite large
<sladen> (with a DEFLATE decoder in there)
<tfheen> sladen: in c++
<sladen> tfheen: wouldn't take much to fix that
<mjg59> tfheen: Other than size, not really
<tfheen> mjg59: they could be optional, I guess.  And it's not like libjpeg is _that_ big.
<cjwatson> ogra: do you have a DTD anywhere for the hwdb XML files?
<ogra> nope
<cjwatson> OK, I'd kind of hoped that <!DOCTYPE hwinfo SYSTEM "http://www.ubuntu.com/hwdb"> actually meant something ;-)
<ogra> no, did you ever look at the xml files ? 
<cjwatson> briefly. Could you give me a quick summary of the known problems?
<cjwatson> all I've ever heard is "somewhat broken XML"
<ogra> well, its not really xml ...
<ogra> right
<ogra> it needs to be updated to write proper xml, then we'll have a dtd as well
<cjwatson> so my best bet is line-by-line parsing?
<ogra> and match tags, yes 
<cjwatson> ok, no problem
<xerxas> Hi all
<ogra> the tags should be relatively self eplaining
<ogra> *explaining 
<cjwatson> yeah, I can either guess those or just read the source :)
<ogra> just look at one of the files ...
<ogra> right
<cjwatson> thanks for your help
<ogra> well, sorry for the bad code 
<mjg59> tfheen: Yeah, fair enough
<kwwii> tfheen: look at the jpeg decoder used with the bootsplash
<tfheen> kwwii: do you happen to know what package that would be in?
<CapRiCoRN^80> hi ! any one there how has installed ubuntu on sun blade 150 ?
<kwwii> tfheen: not sure, the bootsplash kernel diff I guess
<iwj> mvo: When you're back, I have an error from gdebi I was wondering if you might be able to help me with.
<iwj> I say   gdebi /root/adt-downtmp/dsc0/mawk_1.3.3-11ubuntu2.dsc   and it says   ValueError: Problem Parsing Dependency
<iwj> (with stack trace)
<vinboy> is Herd 4 coming out today?
<mvo> iwj: can you put the stacktrace somewhere please? on a pastebin?
<iwj> mvo: http://paste.ubuntu-nl.org/5721/
<mvo> iwj: what package? a .deb or a .dsc?
<iwj> .dsc
<iwj> mawk_1.3.3-11ubuntu2.dsc from the archive, in fact.
<mvo> iwj: thanks, I'm checking this out now
<iwj> Thanks.
<iwj> I have a workaround for now so it's not blocking me.
<pitti> mvo: oh, what does gdebi do with a .dsc? some apt-get source -b magic? 
* tfheen goes to build the first candidate ISOs
<mvo> pitti: no, not that fanncy. it will just install the build-dependencies
<mvo> doing something like apt-get -b would actually be cool ..
* mvo hugs pitti
<pitti> heh
<mvo> iwj: I know why it happens, I will fix it now
<CapRiCoRN^80> wat SILO prompt ?
<iwj> mvo: Eventually I'm going to want a fix for this in dapper.  Is that going to be a problem ?
<iwj> If so then a backport I can pull out of my back pocket will do since I can just install gdebi_<my-weird-one>.deb in the testbed.
<iwj> Actually, that might be better anyway so I can have gdebi-core.)
<mvo> iwj: I think it shouldn't be, a backport should be straightforward mostly. there is IIRC only a single feature of the >dapper python-apts I use
<sacater> hey does anyone know a way for source-code packages to handle their dependencies themselves (eg. they get them and install them from the web automatically)
<CapRiCoRN^80> hi ! any one there how has installed ubuntu on sun blade 150 ?
<mvo> iwj: I'm happy to assit with the backport
<iwj> mvo: That would be very nice :-).
<_ion> Funny. In qemu, the text-mode Ubuntu installer detects my US keyboard layout to be JP.
<tfheen> _ion: known bug
<mvo> iwj: I guess you will need --assume-yes as well for the automatic mode in the package tester?
<iwj> Yes.
<mvo> ok, I'm add this too (while waiting for the test-upgrade to finish)
<iwj> Thanks.
<CapRiCoRN^80> any one there how has installed ubuntu on sun blade 150 ?
<mdz> pitti: anything which isn't rebuit in the normal course of Feisty development needs to be explicitly rebuilt to effect the maintainer changes
<bddebian> Heya
<_ion> usplash-theme-ubuntu is starting to look *really* nice, now that the progress bar was "fixed".
<mdz> pitti: note that this does not need to happen all at once; it should be spread out over time to avoid a big mirror hit
<pitti> mdz: right, I would have split it in chunks anyway
<pitti> mdz: let's discuss and coordinate that on the meeting; doko needs some rebuilds anyway for a new gcc, that seems like a good opportunity :)
<mdz> pitti: sounds good, please add it to the agenda
<asac> pitti: what should a "report bug" menu entry in firefox do? just run ubuntu-bug ?
<fabbione> seb128: ping?
<pitti> asac: 'ubuntu-bug -P <pid>', as I wrote in the bug
<pitti> asac: addditionally giving '-p firefox' saves apport some work for finding out the package name
<fabbione> pitti: ping? re: tcl/tk SRU...
<Riddell> tfheen, cjwatson: I tried creating a kubuntu live image and CD but the i386 one failed because installer-i386/current/images/udeb.list doesn't exist
<cjwatson> oh, bugger, that bug again
<cjwatson> I keep forgetting that we have to fix that damn thing up by hand
<cjwatson> tfheen: I'll fix
<cjwatson> tfheen: fixed, please run the publisher
<asac> pitti: ok, was just a bit confused because I could not see any obvious reason to pass <pid> to bug-report.
<tfheen> cjwatson: cheers; running.
<bluefoxicy> apport is annoying
<bluefoxicy> SORRY, THE PROGRAM <some gnome-game you've never run> HAS CLOSED UNEXPECTEDLY!
<bluefoxicy> SORRY, THE PROGRAM <some app that crashed 5 months ago> HAS CLOSED UNEXPECTEDLY!
<tfheen> bluefoxicy: then turn it off.
<cjwatson> pitti,Riddell,mvo: have you three already discussed Kubuntu edgy->feisty upgrade options, or has that action item from the last meeting become moot? ISTR Riddell saying something about the python-(qt|kde)* patch no longer being necessary
<Riddell> cjwatson: I've discussed it with pitti, that backports aren't necessary it's just 4 patches now, he said he'll review them
<Riddell> s/that/the/
<cjwatson> Riddell: ok, thanks, I'll mark that action item as done then
<pitti> fabbione: didn't look at it yet, is it properly filed as a bug with an SRU proposal?
<pitti> asac: you can omit it and just pass the package name with -p if you aren't interested in runtime information
<pitti> asac: however, runtime information will give you user groups, /proc stuff, etc., so it might be useful
<pitti> asac: also locales, etc.
<pitti> cjwatson, Riddell: I'm about to look at the patches now
<asac> pitti: ah ok ... thanks for the info
<fabbione> pitti: it's just a proposal in your inbox..
<fabbione> pitti: before filing everything i want to hear your/cjwatson opinion
<pitti> geser: ah, I saw your first uploads
<pitti> geser: tell me when I shall run the script another time
<pitti> fabbione: 'k, will look in a minute
<fabbione> pitti: sure.. even for tomorrow or friday
<fabbione> it's not urgent, but i am soon leaving for holidays
<fabbione> so i would like a go/no-go
<pitti> fabbione: hm, it doesn't look particularly SRUish to me, Tcl isn't something we need for desktops? if there are some bugs where users complain about being bitten by this, I would agree, but the patch length/risk/benefit ratio doesn't seem convincing to me
<fabbione> pitti: it bites bigendian machines.. and for desktop it's ppc
<pitti> fabbione: is there a sparc application (cluster management GUI etc) that needs it?
<fabbione> pitti: gitk
<fabbione> pitti: it happens only when parsing some UTF8 encoded Japanese text
<fabbione> difficult to trigger but it can happen somewhere else in the world
<pitti> Riddell: can you please add a proper SRU proposal to bug 84717 with the justification, potential impact, etc.?
<Ubugtu> Malone bug 84717 in update-manager "SRU: updates necessary for Kubuntu Upgrade Tool in Edgy" [Undecided,Unconfirmed]  https://launchpad.net/bugs/84717
<pitti> Riddell: urgh @ those patches -- does this really need backporting of completely new source files?
<Riddell> pitti: yes, it's new features
<pitti> Riddell: all this code is in Feisty already and has been tested?
<Riddell> pitti: yes
<fabbione> pitti: thanks for the reply
<pitti> fabbione: feel free to object if I misunderstood the severity and you actually need that fixed
<bluefoxicy> mm.  Would be nice if the installer could re-install, find existing installations and ask if you wanted to overwrite them
<fabbione> pitti: i tend to agree with you.. my only concern here is that it still affects 2 arches out of 4
<pitti> right, but even if it would affect all arches I wouldn't have the feeling that this is appropriate for SRU 
<fabbione> pitti: what about: i file a bug, we keep it there and wait for possible "me too"?
<geser> pitti: is a build-dependency on libxul-dev | mozilla-dev ok or should it be fixed?
<pitti> fabbione: if noone filed a bug yet, it doesn't seem to be important in the first place :)
<pitti> geser: that's fine
<fabbione> pitti: ehhehe fair enough
<pitti> geser: as long as one alternative remains installable and the package works with it
<iwj> This running two VMs on hardware with only 512Mb in total is a bit crunchy.
<pitti> iwj: urgh, I got annoyed with 1 GB and two vmware instances...
<jdong> iwj: everything's crunchy with Total!
<iwj> ??
<jdong> obviously not American?
<jdong> http://en.wikipedia.org/wiki/Total_%28cereal%29
<pitti> lol
<iwj> Not only not American, but no TV either.
<jdong> lol, that's a good thing. Two good things apparently :)
<iwj> If I had another G or so then it could dump all of the copy-on-write junk from the testbed modifications in RAM.
<_ion> I wouldn't mind another 3/8 G of mem. :-)
<iwj> 3/8 G is a rather strange quantity to be pining for.
<pitti> _ion: I just bought another 2 GB and am happy now :)
<iwj> I wonder if it would save time overall if I spent 45mins tomorrow morning fetching some RAM, or whether I should order it online and get it next week.
<jdong> "Train A departs southbound from New York with 2 512MB 667MHz DDR2 sticks of RAM while train B departs Northbound from Atlanta with 1 stick of 1GB DDR2 533MHz RAM"
<pitti> cjwatson, Riddell: I did the first round of reviews for bug 84717 and added some comments; I think we can consider the meeting action item as done now
<Ubugtu> Malone bug 84717 in update-manager "SRU: updates necessary for Kubuntu Upgrade Tool in Edgy" [Undecided,Unconfirmed]  https://launchpad.net/bugs/84717
<Chipzz> mvo: ping ;)
<doko> pitti, anybody else: what was the spec for the maintainer field for main? I do remember that we should use ubuntu-devel-discuss (because ubuntu-devel is moderated)
<pitti> re
<pitti> doko: https://wiki.ubuntu.com/DebianMaintainerField
<geser> is gcc-4.0 still in feisty?
<mdz> geser: yes (for future reference, you can look that up in Launchpad)
<mdz> doko: they're both moderated for non-subscribers, but -discuss is more appropriate for the kind of thing the Maintainer field is used for
<geser> I ask because only the source is available and the build status doesn't list anything
<pitti> geser: I guess it has just never been rebuilt in Feisty
<pitti> geser: hm, it has
<geser> the last upload was two days ago. the old binary are gone and it seems the last upload didn't reach the buildds
<doko> tfheen: please reject the python2.4 and python2.5 uploads (which are currently blocked); these are supserseded by now
<Windkracht8> Can someone explain me why the "root" option for the "kernel" command in the "menu.lst" of grub is replaced from a device name to an UUID number? the some goes for "file system" option in the fstab file
<_ion> The device names are free to change, the system is still going to boot properly.
<_ion> E.g. you might connect the HDD to another bus, or hda might change to sda when the PATA stuff is switched to libata-pata.
<Windkracht8> after the update to kernel 2.6.17-11-generic these numbers where changed to an incorrect number
<Windkracht8> gave the error message: "Begin: Waiting for root file system"
<Windkracht8> I had to change them back to "/dev/hda2"
<Windkracht8> to get an bootable system
<_ion> You should file a bug report with all the details.
<_ion> I.e. what are the UUIDs that were incrorrectly detected, what are the actual UUIDs (ls -l /dev/disk/by-uuid) etc.
<Windkracht8> ok, but what does that number represent? how do I find out what the number is for my /dev/hda2
<_ion> Each partition has an unique ID
<Windkracht8> and could those be changed?
<_ion> Not normally, unless you replace a partition with another.
<cjwatson> $ sudo /lib/udev/vol_id -u /dev/hda3
<cjwatson> 424fb11b-b062-4c5b-83bc-6ffd84c17ae7
<_ion> That is, create a new filesystem, overwriting an already existing one.
<cjwatson> ^-- finding out the existing UUID
<_ion> Or ls -l /dev/disk/by-uuid to get a list.
<Windkracht8> ok, I don't have the old menu.lst, but the fstab hasn't changed and the file systems are mounted correctly, so the number hasn't changed
<cjwatson> mjg59: bug 85169 is weird - it's segfaulting trying to inb from VGA register 0x3cc
<Ubugtu> Malone bug 85169 in usplash "[apport]  usplash crashed with SIGSEGV in __svgalib_get_perm()" [Undecided,Unconfirmed]  https://launchpad.net/bugs/85169
<cjwatson> mjg59: any idea why that might be happening?
<Windkracht8> thank you all for the information, not going to file a bug though, seems to be an unreproducible isolated incident
<TerminX> can someone fix package xinetd to provide inet-superserver?  everything that depends on inet-superserver wants to pull down openbsd-inetd when there's already a perfectly good inetd implementation on the machine
<okaratas> hea
<Burgwork> TerminX: you filed a bug?
<TerminX> Burgwork: yeah, a month ago, nobody ever responded to it
<Burgwork> TerminX: provide a debdiff yourself
<cjwatson> no point, it's trivial
<cjwatson> I'll prod it in a moment
<cjwatson> providing patches for trivial bugs is a waste of time - if it's a one-liner or thereabouts and already adequately described, anyone with the competence to apply the patch can also Just Do It
<TerminX> https://launchpad.net/ubuntu/+source/xinetd/+bug/79316 was the bug I filed; I don't know if it's in the right place or not (it was where someone in the #ubuntu-motu channel told me to post it)
<Ubugtu> Malone bug 79316 in xinetd "Package doesn't provide 'inet-superserver' dependency" [Undecided,Unconfirmed]  
<cjwatson> TerminX: fixed
<TerminX> cjwatson: sweet, thanks :D
<geser> what about update-inetd? does it work with xinetd?
<TerminX> geser: I think it prints out text notifying the user that they have to update the xinetd configuration manually
<cjwatson> right
<cjwatson> there's an inetd compatibility mode documented in xinetd too
<TerminX> that's just a one-time conversion of the inetd conf file to xinetd format, though, isn't it?
<TerminX> unless something has changed (it has admittedly been a while since I've migrated from inetd to xinetd)
<cjwatson> that's a different mode
<cjwatson> apparently an -inetd_compat switch was added it 1:2.3.11-2
<cjwatson> in
<cjwatson> no idea how well it works, as I don't use xinetd
<cjwatson> TerminX: meh, Soyuz is broken and rejected my upload. I'll complain
#ubuntu-devel 2007-02-15
<keescook> seb128: I've got a built vte (was about to test the fix for #85023), are you working on this too?
<seb128> keescook: nop, it's midnight and I was just sending the summary for the weekly meeting before going to bed :p
<seb128> keescook: you are welcome to upload a fixed package for that ;)
<keescook> okay, cool.  I'll get ubuntu2 uploaded.  :)
<seb128> bug #85023 (probably the screen problem)
<Ubugtu> Malone bug 85023 in vte "Screen corruption when used with screen" [High,Fix committed]  https://launchpad.net/bugs/85023
<seb128> right
<seb128> keescook: thank you, once it's uploaded try to convince tfheen to accept it for herd4 maybe ;)
<keescook> I'll leave that to you.  ;)
<seb128> though it's not really required for the CD
<seb128> that's a command line corner case and people are likely to pick the update after herd4 anyway
<keescook> right.  I'd like to see this LVM snapshot bug fixed.  really killing me since all my builds are on snapshots.
<seb128> good luck with that ;)
<seb128> time for bed here
<seb128> 'night everybody, see you tomorrow
<keescook> g'night!
<sistpoty> hm... I just got a reject for gv saying that 3.6.2-2ubuntu1 <= 1:3.6.2-2... however the epoch is there in the dsc... any clues?
<geser> sistpoty: it's bug #85201
<Ubugtu> Malone bug 85201 in soyuz "wrongly rejects epoched uploads" [Undecided,Unconfirmed]  https://launchpad.net/bugs/85201
<sistpoty> geser: thx... just found it :)
<keescook> uh-oh.  Rejected: vte_0.15.3-0ubuntu2.dsc: Version older than that in the archive. 0.15.3-0ubuntu2 <= 1:0.15.3-0ubuntu1
<sistpoty> welcome to the club keescook
<keescook> oh
<keescook> hey, look, I can read my scrollback, I should try it some time.  :)
<mjg59> cjwatson: Erm. Not really. Has iopl been called?
<poningru> did 2.17.91 get through the freeze?
* poningru assumes 2.17.90
<sparr> why doesnt ubuntu have 'moving target' repository names like debian's stable/testing/unstable?  having to modify my sources every 6 months to keep up to date is hella annoying
<HrdwrBoB> because you don't want to be running ubuntu unstable when it's first switched over
<sparr> no, YOU don't want that :-p
<HrdwrBoB> because your system will likely fail spectactularly
<sparr> ill be switching from feisty to gwhatever the day after feisty releases
<Hobbsee> [12:33]  <Hobbsee> !timebasedreleases
<Hobbsee> [12:33]  <ubotu> Ubuntu releases a new version every 6 months. Each version is supported for 18 months to 5 years. More info at http://www.ubuntu.com/ubuntu/releases & http://wiki.ubuntu.com/TimeBasedReleases
<Hobbsee> sparr: ^
<sparr> yes, im familiar with that
<Hobbsee> sparr: no you wont, the day after feisty releases, the new release isnt even started.
<sparr> akin to debian's named releases (etch, potato, sarge, etc)
<Hobbsee> they do get a couple of days off, you know.
<Hobbsee> then you've got to wait for the toolchain
<sparr> Hobbsee: then ill be ready when it happens :-p
<Hobbsee> go ahead.  as long as you file bugs, of course
<sparr> i do
<Hobbsee> good.
<sparr> when a new driver or library comes out, i cant wait 6 months for it
<sparr> i cant imagine anyone moving from debian unstable to ubuntu NOT doing what im doing
<HrdwrBoB> er
* Hobbsee can
<HrdwrBoB> they are so used to their systems breaking spectacularly every six months?
* Hobbsee notes that sparr sounds like a gentoo user.
<HrdwrBoB> or more frequently?
<Hobbsee> sparr: did you run feisty in the first few weeks of it's development?
<sparr> Hobbsee: yes, ish
<Ng> sparr: https://blueprints.launchpad.net/launchpad/+spec/grumpy-groundhog
<sparr> i didnt dist-upgrade
<sparr> i get my feisty one dependency at a time
<sparr> my system is probably at least 80% edgy still
<Hobbsee> that's just insanity.
<sparr> HrdwrBoB: the breakage isnt so bad, and well worth it
<sparr> ive only encountered two broken packages so far
<sparr> both already bug'd when i found them
<Hobbsee> sparr: only getting part of feisty is not the same as a new feisty, where all the core stuff is changing too
<sparr> very true
<sparr> if and when i want the core stuff, ill upgrade it
<sparr> i think flash 9 was the first thing i wanted that wasnt in edgy
<Ng> if you're just cherry picking a few apps and libs though, one global s&r in one config file twice a year doesn't seem to quite fit "hella annoying" ;)
<sparr> Ng: ok, mildly annoying :-p
<sparr> Ng: more so, because i dont remember to do it until the first time i try to upgrade something and i realize a new version is out
<sparr> just a random idea...  why not have aliases in the repository...  one points to the last LTS release, one to the last release, and one to the latest dev
<sparr> not exactly the same as debian, but thats not neccessarily a bad thing
<Hobbsee> sparr: because of the extra work.  and the idea of freezes then get thrown out the window.
<bddebian> Why don't you just run Deian then? :)
* Hobbsee --> out
<bddebian> Err debian even
<Hobbsee> bddebian: gentoo, really.
<Ng> it kinda invites disaster for people who have them set to that without realising the implications and happily let update-manager to a dist-upgrade
<bddebian> Ah, better
<sparr> bddebian: because i like kubuntu's out of the box software integration better
<bddebian> So either you live with it or you switch :-)
<sparr> for a long time i was torn between debian and gentoo...
<sparr> ubuntu improved on debian in a few key ways, enough to overcome the few failings like the instant case...  so now it would be ubuntu vs gentoo
<sparr> but gentoo's cutting edge is TOO broken for my tastes
<sparr> and the default configuration is poor.  getting a "complete" desktop experience set up like [k] ubuntu provides takes far more time than its worth
<Hobbsee> sparr: so's the first few weeks of the development release, btw
<Hobbsee> very cutting, very broken
<sparr> i like being able to plug in a usb drive and it auto mounts and i get a prompt about what to do.  i like having 'burn' as a context menu item for ISO files.  i like http links in my irc client opening the right browser, usually.
<sparr> Hobbsee: yeah, but i dont encounter those
<sparr> Hobbsee: the things i want to upgrade are rarely dependent on the things that are very broken
<poningru> https://lists.ubuntu.com/archives/feisty-changes/2007-February/005287.html
<poningru> dist-upgrader
<poningru>  - updated demotions
<Hobbsee> sparr: if you want to run the latest release all the time, then you're going to be upgrading *everything*
<poningru> what does that mean?
<Hobbsee> including stuff that breaks
<Hobbsee> poningru: demotions from main to universe
<poningru> what are demotions?
<poningru> ah gotcha
<sparr> Hobbsee: sure, but thats not what i want.
<Hobbsee> that's mostly what you're saying
* Hobbsee --> really out
<sparr> not at all
<sistpoty> well... if you dist-upgrade fast enough, it's safe, because nothing is broken yet... however I guess we're getting quite offtopic here
<sparr> i want ACCESS to the latest version of every package
<sparr> heh, i want to know how he can get a 104 that fast...  i have to time out to get one
<bddebian> sparr: Just grab the latest upstreams and build yourself :-)
<sparr> bddebian: heh, i do that for a few packages, stuff i have patches for
<Rohinton> HI why do we build so many full distro's would it not be better to have 1 base and then have the GUI ( G,K,X ) applied after?
<Burgundavia> Rohinton: we don't. The package building is a seperate process to the ISO building
<LaserJock> Rohinton: they all come from the same repo, it's not really that different than what you are saying
<sparr> i think Rohinton's issue is more one of perception
<sparr> kubuntu, ubuntu, xubuntu sound very different
<sparr> they would come together in peoples minds more as ubuntu-g, ubuntu-k, ubuntu-x
<sparr> or any other scheme where they all start with the same letter (to be blunt)
<Rohinton> yes - 
<Rohinton> I would like to download a base and then after the live-cd is running or installed be prompted for the gui system...
<sparr> im curious how much space each GUI takes up...  if someone tried to make a k+g+x ubuntu livecd, how much would they have to sacrifice to squeeze it all onto one disc?
<sparr> i am doubtful that there is 700MB worth of kde-specific stuff on the kubuntu disc
<HrdwrBoB> what you really want
<Rohinton> Hmm, but the contents would have to be reviewed as they are all 690+....
<HrdwrBoB> is a button that says 'install KDE'
<HrdwrBoB> 'install gnome'
<Rohinton> right...
<HrdwrBoB> 'install XFCE'
<Burgundavia> sparr: you couldn't do it
<sparr> install edu (less likely, the edubuntu disc probably has the most unique packages compared to the others)
<Burgundavia> you can look at the seeds yourself
<sparr> im a fan of the debian net-install...  boot off a single floppy, or at worst a very very small iso image, and get everything off the network  :)
<sparr> obviously i see the advantages to the ubuntu method
<sparr> having to pick a gui at iso download time is odd, but not killer
<sparr> imho the biggest problem is just the names
<zul> sparr: what you really want is gentoo, I believe that channel is #gentoo
<sparr> the layman is used to mac os 7, os 8, os 9, os 10
<sparr> windows 95, windows 98, windows xp, windows vista
<sparr> ubuntu foo, ubuntu bar, ubuntu baz would make a lot more sense to common people than foobuntu, barubuntu, bazubuntu
* sparr trademarkes foobuntu
<Burgundavia> likely trademarked
<Burgundavia> and there is nothing too different from Kubuntu and Ubuntu from os 9 and os 10
<sparr> right...  so why are the names "so different"?
<sparr> bluntly, having different first letters means they show up different places on a list.  and they go in different little pockets in your mind.
<sparr> think of it from a marketing perspective
<sparr> i see a kubuntu flyer, and then later hear something about ubuntu
<sparr> or about xubuntu
<sparr> i am unlikely to make the connection.  at worst, i might think one is a ripoff of the other
<Burgundavia> they are different products
<sparr> but if they were ubuntu-k and ubuntu-x, the relationship would be a lot more intuitive
<sparr> but they are both ubuntu
<Burgundavia> and twice as ugly
<Burgundavia> no, they are Xubuntu, Kubuntu and Ubuntu
<sparr> its about mindshare
<Burgundavia> they are different products and are marketed as such
<sparr> i disagree.
<Burgundavia> and anyway, this is off topic and the names are not going to change
<Burgundavia> no matter how much we bikeshed
<sparr> kubuntu and ubuntu are far more similar than redhat desktop and redhat enterprise server
<sparr> and yet the redhat name is at least twice as memorable with their scheme than with ours
<_ion> And the scientific method used to conclude the memorability to be  2.0 times better was which?
<sparr> the current names foster an environment that seems to say "come try kubuntu!" "no, come try ubuntu!" which is counterproductive.  the message we need to be sending is "come try some variant of ubuntu!  take your pick"
<sparr> _ion: a dartboard.  happy?  do you actually disagree with the conclusion or just the method?
<_ion> Ubuntu and Kubuntu are totally fine names for the products IMO.
<sparr> show someone an ad for redhat desktop, then ask if they have ever heard of redhat server.  then show someone an ubuntu ad, and ask if they have ever heard of kubuntu.  the precise answer is "no" in both cases, but the connotation is VERY different
<Rohinton> Hmm, the different names do they signify more that just a different UI?
<sparr> Rohinton: nope
<sparr> Rohinton: all they are is a different default set of packages.  converting one to the other is just a matter of installing a single metapackage
<sparr> _ion: im not saying the names are bad, per se...  for established products they would be great.  but ubuntu is in desperate need of mindshare, and this naming scheme doesnt help with that.
<Chipzz> sparr: why are you second-guessing the whole community + canonical?
<Chipzz> oh for crying out loud
<_ion> "Ubuntu is in desperate need of mindshare", HUH?
<sparr> Chipzz: i doubt i am.  first, Rohinton brought it up, not me.  second, im almost certain i could use google to find this same point made a dozen times.
<sparr> _ion: youre familiar with bug #1?
<Chipzz> reality-check: ubuntu is VERY MUCH NOT in need of mindshare
<Ubugtu> Malone bug 1 in ichthux "Microsoft has a majority market share" [Critical,Confirmed]  https://launchpad.net/bugs/1
<Chipzz> sparr: have you checked distrowatch lately?
<sparr> Chipzz: on occassion.  why?
<Chipzz> where the hell is the distro top ten on distrowatch...
<sparr> 'major distributions'
<sparr> at the top
<sparr> i know ubuntu is #1
<sparr> thats irrelevant
<Chipzz> no it is NOT?
<sparr> im talking about the real world, not the "people savvy enough to visit distrowatch" subset
<Chipzz> you're an idiot if you claim ubuntu is in need of mindshare and it's no1 at distrowatch
<sparr> walk down the street
<sparr> ask people if they have heard of windows
<sparr> then ask if they have heard of ubuntu
<_ion> Yes, changing the name of Kubuntu to Ubuntu-K would instantly convert all the Windows users to Ubuntu and Ubuntu-K.
<Chipzz> _ion: yeah :)
<sparr> i gave out kubuntu cds for christmas.  a few people converted.  a few tried it and went back to windows.  plenty used them as coasters, im sure.
<Chipzz> sparr: linux in general is in need of mindshare vs windows
<sparr> that middle group are the ones im talking about
<sparr> a year from now when they hear something awesome about ubuntu, do you think they are going to connect it with kubuntu?
<Chipzz> sparr: but ubuntu is very much not in need of mindshare vs other distro's
<Chipzz> s/vs/compared to/
<sparr> when i see ubuntu vs kubuntu, i think iMac vs Emac (as in emachines, not the educational mac).  a theme ripoff with a similar name.
<Chipzz> STOP TROLLING
<sparr> STOP SHOUTING
<_ion> I think sparr has received too much mindshare tonight. :-)
<Chipzz> yeah
<sparr> then ignore me
<sparr> im the reason they added /ignore to your irc client
<Chipzz> no
<Chipzz> you're the reason they added /kickban to our irc clients :P
<sparr> just because you disagree doesnt make the problem go away
<sparr> im doing my part to introduce the public to linux in general, ubuntu more precisely, kubuntu specifically.  i WANT more people using them (in that order).  since we have a marketing team, i know im not alone.
<sparr> and this naming scheme is counter to that objective
<Chipzz> if you think you're going to solve the problem of linux in general gaining marketshare on windows by changing kubuntu to ubuntu-k you're deleude
<Chipzz> deluded
<sparr> why?
<Chipzz> because IT DOES NOT MATTER
<sparr> are you saying im wrong, or that its insignificant?
<sparr> every single individual who tries ubuntu helps
<sparr> every one who sees an ad for it
<Chipzz> *everyone* is saying you are wronge /since you entered this channel/
<sparr> lol
<sparr> thats a great point
<sparr> well, it would be, if i was the one who said this first...
<Chipzz> do you honestly think people are *that* retarded they cannot associate two product because one has a *prefix* wrt the other instead of a *suffix*?
<sparr> yes
<sparr> not retarded
<Chipzz> boy do you have a very sad view of the world
<sparr> accustomed
<sparr> in the real world, this sort of naming scheme implies ripoffs
<Chipzz> no it does not?
<Chipzz> why do I even bother
<sparr> changing the first letter is the easiest way to escape trademark problems, its how thousands of knockoff brands sell their products
<bddebian> So if I say "Windows", do I mean 3.1, NT, 95/98/ME, XP, or Vista?
<sparr> bddebian: yes.
<sparr> bddebian: probably xp, today.
<jdong> bddebian: I'd assume an NT family though
<bddebian> No, Vista released
<sparr> yes, but its not 'there' yet  :)
<jdong> sparr: lots of people are running it already
<jdong> sparr: especially computer nerds
<bddebian> My point is, the name doesn't mean shit :-)
<sparr> when you say windows, people think of xp.  when someone else says windows, they are almost certainly talking about xp
<jdong> sparr: I see like 50% vista of windows users here :)
<jdong> (here = MIT)
<sparr> jdong: i know of a few similar local demographics...  even there, vista is named
<Chipzz> jdong: ieks
<sparr> vista is "windows vista", or "the new windows"
<HrdwrBoB> sparr: XP is XP
<sparr> i dont think ive heard "windows" specifically referring to vista yet
<Chipzz> sparr: but... "the new" is in front of windows!
<bddebian> hehe
<HrdwrBoB> sparr: my mother in law knows what vista is.
<Chipzz> OMG LOL!!!1!!111!11ELEVEN
<sparr> i dont think ive heard "windows" referring to anything other than xp outside of IRC in at least 5 years
<jdong> sparr: right -- when people want to talk about Windows Vista they say Vista
<sparr> jdong: that seems to be the norm
<jdong> but Windows I'd say refers to XP or 2K
<jdong> at least that'd be my first assumption
<sparr> 2k is my windows of choice, when im forced to use windows  :)
<jdong> around here I've heard a lot of 5.1.2600's.....
<jdong> it's land of the numbers :)
<jdong> or 5.1K
<jdong> for Kerberos patches
<jdong> sparr: I like XP with the 2K theme
<jdong> sparr: I've found XP to be faster than 2K when the theme is stripped down
<jdong> but multitasking is pathetic period
<_ion> I like... Wait, i don't like any Windows. ;-)
<jdong> CPU or IO multitasking...
<sparr> its a matter of perception...  put in simple words...  ubuntu-k says to the average joe "the k version of ubuntu".  kubuntu says "a ripoff of ubuntu, probably by a company whose name starts with k"
<Chipzz> sparr: even then the damage is already done
<Chipzz> sparr: even if we were to change the names, which we are NOT, that would cause confusion/technological programs with existing users of the product
<sparr> if someone liked ubuntu, and has a passing chance to try kubuntu, they might say no just because they expect a ripoff of ubuntu.
<sparr> or vice versa (less likely)
<Chipzz> yes we've heard that argument like 10 times before, and it is still wrong
<_ion> If they already know (and even use!) Ubuntu, Ubuntu already *has* the Mindshare.
<sparr> the divergent advertising doesnt help either, with different color schemes and such
<HrdwrBoB> and even if it's not it's not going to change
<Chipzz> sparr: now you're talking COMPLETE crap
<Chipzz> sparr: the different versions of windows vista also come in boxes with different colors
<sparr> look at ads or packaging for vista home, vista server, vista ultimate, vista premium, vista chipotle...  they have things in common that tell people they are heavily related
<Chipzz> so you're saying people won't buy vista because they're confused by the different colors of the boxes?
<sparr> the 'background' of the box is a different color.  the vista logo is always the same.
<Chipzz> no it's not???
<Chipzz> it's very much the same thing
<Chipzz> you're talking out of your arse
<Chipzz> oh and btw
<Chipzz> there's a name for it
<sparr> there are so many things at work.  in no particular order...  the pearl, the name "windows", the name "vista", and the name "microsoft"
<Chipzz> it's called "product differentiation"
<sparr> kubuntu vs ubuntu doesnt have ANY of that in common
<Chipzz> repeat after me: "product differentiation"
<sparr> product differentiation isnt what we have
<Chipzz> yes it is??
<sparr> product differentiation indicates that theres some common point that you diverged FROM
<sparr> we have vista home, and vista ultimate.  we have vista marketing material.  now, lets add something different for each version.
<sparr> thats ass backwards to what kubuntu and ubuntu have
<Chipzz> the same for ubuntu???
<Chipzz> we have the same base for ubuntu, kubuntu, xubuntu
<Chipzz> even the same apps
<Chipzz> it's just a matter of default installation
<sparr> kubuntu and ubuntu start in completely different places, and maybe by chance happen to come slightly together
<Chipzz> these things use the bloody same repository for crying out loud!
<bddebian> Start in different places???
<sparr> we are talking about advertising
<sparr> "us" communicating to "them"
<jdong> does anyone else use the term ubuntu to encompass the entire Ubuntu family of distros?
* jdong does that sometimes
<sparr> jdong: distrowatch seems to
<jdong> sparr: well every ubuntu release spams DW with like 5 identical annoucements before :D
<sparr> jdong: which is another minor issue
<sparr> bob made a flyer for kubuntu
<sparr> joe made a flyer for ubuntu
<sparr> then maybe, if we are lucky, they talked to each other and shared some ideas so they have something in common
<Chipzz> I'm sure canonical coordinates marketing
<sparr> getting into the look and feel of the ads is way outside the scope of what i was originally trying to say
<jdong> yeah, like Ubuntu doesn't lose data when unmounting USB........ oh never mind
<sparr> the names themselves are counterproductive to the task of telling people about *ubuntu
<ivoks> imho, it would be better to have something like Ubuntu G, Ubuntu K and Ubuntu X :)
<sparr> ivoks: blasphemy!  no one else agrees!  shut up!
<ivoks> :)
<sparr> </sarcasm heavy>
<ivoks> but now it is as it is and changing that would be even worse then leaving it as is
<sparr> i disagree
<sparr> name changes dont have to kill a product
<sparr> consider iceweasel, i mean firefox, i mean firebird, i mean phoenix...
<ivoks> it always had 'Mozilla' in front of the name of product
<ivoks> and most of the IT clueless refer to Firefox as Mozilla
<ivoks> you download it from mozilla.org, hence, it's mozilla :)
<Chipzz> phoenix wasn't known to the larger public, and ice* is not used by ubuntu
<Chipzz> so that only leaves firebird vs firefox
<mpt> sparr, you're making a lot of sense, but in the wrong place and the wrong tone. I suggest either getting a marketing job with Canonical or writing a spec, the latter of which is probably easier.
<Chipzz> mpt: let's for a moment suppose he is right. it is still *not going to happen*
<sparr> mpt: its already been written and dismissed on the marketing list  :)
<mpt> Chipzz, you don't know that. Lindows changed its name for similar reasons.
<sparr> ivoks: mozilla as part of the brand name has definitely not been "always".  it wasnt for phoenix.  it was for a little while for firebird.
<Chipzz> mpt: lindows changed its name because microsoft was threatening to sue
<mpt> gah, I fell for it ... like I said, this is the wrong place.
* mpt shuts up
<ivoks> (is it only me or we hear lindows/freespire to ofter around here :)
<sparr> aha, thanks for the example
<sparr> lindows/windows is a great example of the kind of thing average people think of when they see ubuntu's naming scheme
<Chipzz> and it's a contrived example
<Chipzz> because windows and lindows are *totally* *different* *products*
<sparr> but lindows was trying to capitalize on the windows name
<sparr> thats exactly what people will think about aubuntu when they see bubuntu
<ivoks> guys, let's stop... as mpt said, this is wrong place
<sparr> normal people dont know kubuntu and ubuntu are the same product.  my ENTIRE point is that they are going to think they are *totally* *different* *products*
<_ion> But, but... How could it capitalize on the Windows name? They have *different prefixes*!
<Chipzz> I have a counterargument against that but I'm just going to shut up
<sparr> _ion: precisely
<sparr> i posit two cases.  one, where users wont make the connection.  two, where users will make the connection, and life experience will tell them its a NEGATIVE connection.
<sparr> virtually no other respectable product uses ubuntu's naming scheme.  normal people see it and think "scam" or "ripoff" or "knockoff"
<sparr> ten years from now when ubuntu has taken over the world, we will be in a position to change that notion.  but today, while ubuntu needs to attract new users, its counterproductive to be under such a stigma
<ivoks> ok, stop, please
<ivoks> we code, we don't do marketing, this is -devel place
<ivoks> plase talk to someone else
<Rohinton> Hmm, well I asked not for the name - It did sink in that these where the same - but I was just thinking about an easier way to use ubuntu with different UIs... The download times for 3-4 iso distributions is long, also if/when they only have dvd's it may get worse?
<Rohinton> if as suggested a button was there saying install ( X, Y, Z ) for the UI that would be nice or I could rool my own...
<Rohinton> BTW - for all thing ubuntu the name I know and understand is Ubuntu - the others don't figure for me until I get to the download site.... :-) 
<Rohinton> That's it on that topic, from me at least.
<ivoks> Rohinton: http://www.ubuntu-hr.org/ningi
<Rohinton> thanks.
<mpt> Rohinton, afaik the Ubuntu CD is crammed full and would not have room for any Kubuntu/Xubuntu stuff, and vice versa
<mpt> Besides which, asking people what GUI they want to use is a meaningless question to ~99.9% of the population
<Rohinton> right - they are - I say give us smaller bits to bite...
<Rohinton> yes - you have a point too.
<Rohinton> but the default of gnome seems to be good for 90% - I wonder what the download stats are for the different ISOs? - which ever seems the most popular should be the default...
* Hobbsee WAVES
<Hobbsee> oops, capslock
<Rohinton> also just looked at the dvd - 4.2 GB is an even longer download than the three CDs... :-)
<ivoks> Rohinton: well, software has size :)
<Hobbsee> please dont tell me you're trying to get ubuntu onto multiple cds, suse/mandriva style...
<ivoks> Hobbsee: i think no one wants that
<Hobbsee> ivoks: oh good.  
<Hobbsee> ivoks: are you a core dev?
<Hobbsee> by any chance?
<ivoks> nope :)
<Hobbsee> ivoks: aww, damn
<Rohinton> right but there are limits...
<Hobbsee> tfheen: ping @ amarok?
<fabbione> morning
<Hobbsee> hey fabbione!
<tfheen> Hobbsee: hiya
<fabbione> hey tfheen 
<Hobbsee> hey tfheen :)
<Hobbsee> tfheen: when's herd4 out?
<LaserJock> "when it's ready"? :-)
<tfheen> Hobbsee: today, hopefully.
<Hobbsee> tfheen: got an upload of amarok, with some fixes from upstream.  cool
<dholbach> good morning
<tfheen> hello Daniel
<dholbach> hey Tollef!
<dholbach> how's it going?
<tfheen> slept too little and a bit hungry, but otherwise ok-ish.
<tfheen> wanting to get herd out now.
<dholbach> same here :)
<dholbach> how's herd looking?
<LaserJock> feisty?
<tfheen> I think we have been bitten by all the bugs which are supposed to bite us so far, so I am just hoping we are not going to run into oversizedness or other fun.
<Fujitsu> tfheen: That's a little bit hopefully, isn't it?
<Fujitsu> *hopeful
<tfheen> I'm building candidate ISOs now; that is, the i386 ones failed to build due to a fun soyuz bug.
<tfheen> the others should be ready already.
<Fujitsu> What was with the buildds being rather stuffed last night?
<tfheen> a launchpad upgrade where somebody forgot to restart the services afterwards.
<Fujitsu> Haha.
<tfheen> candidate ISOs up, please test.
<tfheen> I'll file the tracker bugs now.
<Kagou> hi
<pitti> Good morning!
<dholbach> heya pitti
<pitti> hey dholbach 
<Mez> pitti / keescook can you please have a look over bug 84657 and let me know where to go from where it is
<Ubugtu> Malone bug 84657 in edgy-backports "Security update for rar/unrar (CVE-2007-0855)" [Undecided,In progress]  https://launchpad.net/bugs/84657
<Mez> oh, nvm - I jsut didnt get the email
<dholbach> heya seb128
<seb128> hi dholbach
<tfheen> heno: tracking bugs are filed. :-)
<heno> tfheen: cool, I'll start herding people to them :)
<tfheen> heno: excellent.
<cjwatson> mjg59: not certain. Looking at the code, ioperm() should have been called almost immediately before for a range that includes that port
<heno> tfheen: I guess you script doesn't close bugs that I've opened by hand (Herd 3), so I'll close those again manually too
<tfheen> heno: correct.  I didn't know what to do about those, so I just left them.  Thanks for closing them.
<dholbach> hey mvo
<mvo> heyja dholbach
<seb128> tfheen: can we do universe syncs during a freeze or better to wait after the freeze?
<tfheen> seb128: just do them; they probably won't hit the archive since the publisher is disabled, though.
<seb128> tfheen: ok, thank you
<ogra> tfheen, no new live iso for edubuntu ?
<tfheen> ogra: hmm, I thought I built new ones last night, but apparently not, will fix now
<ogra> thanks :)
<tfheen> ogra: done
<tfheen> grr
<ogra> grr ?
<tfheen> yes, grr.
<ogra> why ?
<tfheen> the alternate amd64 CD is busticated due to d-i/kernel mismatch.
<tfheen> ogra: I suspect your alternates are going to be broken; the installer seed hadn't the new kernel ABI in.
<ivoks> pitti: what's with cups? says 'changed by me' but i didn't touch it, i swear :)
<ogra> tfheen, there are no seed differences apart from mdz's last commit in my bzr
<pitti> ivoks: I used your debdiff (slightly modified) to give credit where credit is due ;)
<tfheen> ogra: yes, there are.
<pitti> ivoks: Soyuz just seems to have a hiccup right now, it doesn't see the upload
<cjwatson> damn, I'm sorry, I forgot about the seed change
<cjwatson> tfheen: are you doing that now?
<ivoks> pitti: that was a long long time ago; i don't have time for cups for months now :(
<tfheen> cjwatson: already done.
<cjwatson> ok
<ogra> tfheen, hmm, why doesnt bzr missing show them ?
<tfheen> ogra: because I merged them five minutes ago.
<ogra> oh
<ogra> ok
<tfheen> cjwatson: I need to wait for the supermirror to update, right?
<cjwatson> yeah
<tfheen> new ubuntu alternate images up.
<tfheen> heno: ^^ ; new tracker bugs filed.
<heno> tfheen: thanks
<tfheen> ogra: new -server images for you
<ogra> thanks a lot :)
<tfheen> .. and tracker bugs filed.
<tfheen> cjwatson: would it make sense for ubiquity to fade the X screen to black when you click "reboot the system"?
<tfheen> also, current ubiquity doesn't seem to reboot for me.
<fabbione> tfheen: there is a bug for it it seems
<fabbione> https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/85177
<Ubugtu> Malone bug 85177 in ubiquity "Beeping sound starts on D3C5105 after the end of installation process with Feisty herd 3 desktop CD" [Undecided,Needs info]  
<fabbione> tfheen: no reboot too
<fabbione> the sound might be a broken BIOS
<tfheen> fabbione: except I don't hear any beeping.
<tfheen> and this used to work just fine.
* Hobbsee waves
* tfheen waves back to Hobbsee
* Fujitsu drops a big rock on Hobbsee, and runs away.
* mode/#ubuntu-devel [+o Hobbsee]  by ChanServ
* mode/#ubuntu-devel [+b *!*@ubuntu/member/fujitsu]  by Hobbsee
* Fujitsu was kicked off #ubuntu-devel by Hobbsee (oops)
* Hobbsee hugs tfheen 
* tfheen hugs back.
* Hobbsee looks around innocently
<tfheen> what's up?
<Hobbsee> just got home from work :)
<Hobbsee> got elected as part of the op council :)
* mode/#ubuntu-devel [-b *!*@ubuntu/member/fujitsu]  by Hobbsee
<tfheen> nice :-)
<poningru> open patents?
<poningru> open parents?
<poningru> open pa... maybe I should leave the rest of my guesses locked up in my mind
<Hobbsee> poningru: ops.  the ones who can kick
<tepsipakki> Hobbsee: that's evil ;)
<Hobbsee> tepsipakki: me?  evil?  surely not!
* mode/#ubuntu-devel [-o Hobbsee]  by ChanServ
<tepsipakki> haha
<tfheen> ah
<tfheen> powermanagement-interface needs to be updated for the new gdm socket location
<tfheen> oh well, I'll just releasenote that bit
<Treenaks> ah! new gdm socket location
<Treenaks> that explains why my gnome-screensaver refused to let me back in
<Treenaks> (while complaining about gdm)
* Treenaks stops filing bug
<Fujitsu> That was fixed last night, Treenaks.,
<Treenaks> Fujitsu: well. yes. but not if you hadn't restarted gdm :)
<cjwatson> tfheen: ubiquity just pokes gdm/gnome-session to reboot; if there's fading to be done then they should do it
<tfheen> cjwatson: no, it calls gdm-signal which needs updating; I filed bug #85320
<Ubugtu> Malone bug 85320 in powermanagement-interface "powermanagement-interface: needs updating for new GDM control socket location" [High,Confirmed]  https://launchpad.net/bugs/85320
<cjwatson> oh, yeah, I'd forgotten that gdm-signal wasn't part of gdm
<tfheen> it's harmless enough so I'll just releasenote it.
<cjwatson> tfheen: but what I mean is, fade to black should be done by those tools if they don't already
<tfheen> cjwatson: ah, ok.
<tfheen> maybe gdm should be taught, then.
<tfheen> Riddell: you have new alternates as well, too
<tfheen> ogra: how's your testing going?
<tfheen> Riddell: ^^ likewise
<Riddell> tfheen: i386 desktop is lovely
<Kano> hi, one user gets always kernel panic with asrock k7s41 and 2.6.20 kernel - standard generic config or one without ide, does not matter
<Kano> any ideas
<tfheen> Kano: file a bug in launchpad.
<Kano> well it is not my system
<Hobbsee> file a bug for them, or get them to file a bug.
<tfheen> Riddell: good to hear; would you mind putting that info into the relevant bug at https://bugs.launchpad.net/ubuntu-iso-tests/+bugs ?
<Kano> SiS 741 chipset
<Kano> do you have something similar to test with?
<Kano> http://www.asrock.com/mb/overview.asp?Model=K7S41&s=n
<Kano> btw. I let my users test a kernel with that modified config:
<Kano> http://kanotix.com/files/kernel/kernel-update-pack-noide/source/kanotix-flavour.patch
<Kano> that against git and then only the kanotix flavour compiled
<Kano> but the one with problems testet a pure generic kernel too
<Kano> skynix on that server
<geser> pitti: can you rerun your rdepends script on the mozilla source?
<pitti> geser: sure
<Riddell> tfheen, heno: what are the bug status's that were decided for iso testing?  Test case type: manual partitioning
<pitti> geser: updated on my people page
<Riddell> Date of testing: 20070215
<Riddell> md5sum confirmed: No
<Riddell> doh
<Riddell> Bugs identified: Bug #85320
<Ubugtu> Malone bug 85320 in powermanagement-interface "powermanagement-interface: needs updating for new GDM control socket location" [High,Confirmed]  https://launchpad.net/bugs/85320
<Riddell> tfheen, heno: was going to say that https://wiki.ubuntu.com/Testing/ReportingResults doesn't list them
<heno> Riddell: I'm using In Progress for a sucessful test
<tfheen> Riddell: so far it's been "rejected" => iso is bad, fix released => iso is released at least.
<tfheen> with the addition heno mentioned, I think we have something usable?
<heno> and that too
<Riddell> I'll update that wiki page
<ogra> tfheen, my ppc kernel panics :(
<heno> Riddell: thanks
<tfheen> ogra: ugh.
<tfheen> ogra: good thing ppc is a port architecture now, eh? :-)
<ogra> kernel bug at mm/slab.c:610! is what i see on the screen ...
<ogra> and above is a segfault
<tfheen> pitti: can you test a ppc CD?
<pitti> tfheen: yup, already rsyncing
<tfheen> thanks.
<ogra> thats the server CD 
<ogra> i'll check desktop
<tfheen> it's the same kernel, so you should see it there too, I suspect.
<ogra> bah, and its lying ... it says it would reboot in 180secs
<geser> pitti: gnash, swfdec0.3 and videolink have mozilla-dev as an alternative to libxul-dev; enimail-mailnews is to be removed; gtk2hs ftbfs (because of ghc 6.6) and I've filed an uvf exception to get a fixed version in
<geser> pitti: do you see any packages preventing the removal of mozilla?
<pitti> geser: right, the script doesn't handle alternative dependencies well
<pitti> geser: what about the rdepends on mozilla-browser?
<pitti> geser: libgtk-mozembed-ruby1.8, wysihtml-el, tilp?
<geser> I've filed removals on mozilla-locale-*, mozilla-checky and mozilla-cascades
<pitti> geser: ... and gcjwebplugin-4.1
<geser> libgtk-mozembed-ruby1.8 is bug #85156
<Ubugtu> Malone bug 85156 in ruby-gnome2 "[Remove]  Remove libgtk-mozembed-ruby from feisty" [Undecided,Confirmed]  https://launchpad.net/bugs/85156
<pitti> geser: ah, gcjwebplugin has an alternative dependency
<geser> for wysihtml-el and tilp I've uploaded a fixed version
<pitti> so does wysihtml-el
<pitti> geser: oh, alternative deps are fine
<pitti> better and cleaner to prefer firefox, of course
<pitti> but no reason to deviate from Debian just for this
<pitti> geser: hmm, removal of libgtk-mozembed-ruby1.8? it doesn't build against firefox-dev?
<geser> replaced with ruby-gnome2
<pitti> ah
<pitti> yup, sounds sane
<pitti> geser: feisty is frozen ATM and the publisher disabled, so I think I cannot remove packages right now
<pitti> geser: but I have my archive day tomorrow, that'll be the slaughter fest :)
<cjwatson> pitti: FYI I've updated all the bits of the installer I could find for debian-maintainer-field in bzr
<cjwatson> pitti: so no need to upload for those
<tfheen> pitti: you can remove packages now, but they won't take effect until after the publisher runs.
<pitti> cjwatson: ah, nice; we'll wait for the outcome of the discussion anyway
<cjwatson> in the case of the installer it was easy because ubuntu-installer@lists.ubuntu.com is an appropriate contact address
<pitti> cjwatson: did you use Original-Maintainer or XSBC-?
<doko> pitti, seb128: could you have a look at https://wiki.ubuntu.com/PyDbgBuilds to see if that is understandable?
<pitti> doko: right, I wanted to discuss this with you anyway
<cjwatson> pitti: XSBC-
<pitti> doko: instead of adding dozens of NEW -dbg packages to the archive, can these packages be constructed with pkg-create-dbgsym?
<cjwatson> the installer already uses XB- stuff so I didn't really care
<cjwatson> easy enough to change later if we want
<pitti> doko: ... and do we want that? (i. e. the python -dbgsym stuff in the external archive)
<doko> pitti, cjwatson: do we care about of correct maintainer fields, when a binary package is in another section (main/universe)?
<cjwatson> no
<doko> pitti: 1) no, it needs separate compilation; we maybe could hack around it for distutils based builds, but for other packages not using distutils you have no chance
<cjwatson> MOTUs can't effectively maintain a binary in universe if the source is in main
<doko> 2) I currently add the debug symbols for the normal extensions to the -dbg package as well. How do you handle other -dbg packages? just creating an empty dbgsym package and depending on the -dbg package?
<pitti> doko: -dbgsym packages have a Conflicts: to all -dbg packages that a source generates
<doko> pitti: that would be bad ...
<pitti> doko: but it doesn't sound like p-c-d is the right tool here, so nevermind
<doko> pitti: ok, se we have to make sure, that a python debug package always includes the debug symbols for the normal extension as well.
<pitti> doko: do these steps mean that building with python-dbg will generate both the debug and non-debug extensions? or does this require a multibuild?
<doko> pitti: you need separate calls to python and python-dbg for each extension
<pitti> doko: ah, I looked at python-apt.debdiff
<seb128> doko: do we really benefit from that? like is there a need to change that many packages for that?
<pitti> ogra, tfheen: ppc/desktop boots fine here, no oopses
<ogra> still burning desktop here ... probably my media is broken
<doko> seb128: you don't need to change them at all, if you don't need it. isn't debugging for whimps?
<seb128> doko: well, to be honest standard python trace are often enough and we get probably almost no bugs for most of packages listed on that page
<doko> pitti: another idea would be to put the debug extensions in the same package, and allowing p-c-d to strip out these files
<ogra> hmm, desktop seems to work
<seb128> like python-gmenu
<ogra> i'll finishe the test and redo server
<pitti> doko: indeed, interesting
<doko> pitti: but ... debian incompatible ...
<pitti> doko: if these -dbg builds will go to Debian, too, and we can eventually just sync everything, then the current approach seems fine
<jwendell> seb128, good morning
<seb128> hi jwendell
<jwendell> seb128, tsclient doesn't have an upstream bug tracker, i tried to mail its author, without success... what to do if i want to write patches?
<jwendell> any suggestion?
<seb128> attach them to launchpad
<seb128> and mail them to upstream
<doko> seb128: yes, often enough for crashes; could you already track down the crashes in pygtk? the -dbg package give you an additional aid. unfortunately you cannot just rebuild an extension as a drop in to enable these.
<seb128> we can patch the package
<seb128> doko: well, a -dbg would be useful for pygtk, I'm just wondering if we need to do it for all the small side packages as well
<ogra> argh ... my ltsp is broken ....
<ogra> tfheen, i can fix that through a -meta change ...
<doko> seb128: please see the comment just above the table ... and maybe clarify it
<seb128> doko: same remark than pitti though, if Debian do it as well and we can just sync instead of keeping the diff that would be fine
<doko> seb128: sure, I will propose that to Debian
<tfheen> ogra: please
<ogra> tfheen, i'm missing the ubuntu usplash theme on the edubuntu cd for ltsp, ok with you if i upload a seed change ? (will only need a rebiuld of -server)
<ogra> ok, thanks
<seb128> doko: hum, k, I see
<jwendell> seb128, will patches for tsclient get in feisty? or it's too late?
<seb128> jwendell: depending of the patch, there is still several weeks to fix bugs, no reason to not accept it
<jwendell> seb128, including wishes? :)
<jwendell> or just bugs?
<doko> seb128: clarified on the wiki
<ogra> tfheen, ppc server still paicing, even with a new media
<ogra> *panicing
<thep> asac, hi, i'm here to talk about the firefox thai patch.
<ogra> pitti, did you test alternate on ppc ? 
<seb128> jwendell: depending, I can't say without any detail, depend of the change, the complexity of the patch, etc
<jwendell> seb128, ok. i'll try
<pitti> ogra: no, I didn't
<ogra> could you ? 
<pitti> ogra: I can give it a try, yes, I just need to backup my laptop before
<ogra> just if the kernel boots
<pitti> ogra: or do you get the oops already in the installer?
<pitti> ah
<ogra> its segfailting directly for me
<ogra> *segfaulting
<pitti> ogra: burning
<tfheen> ogra: haven't you had a chance to test any images yet?
<ogra> tfheen, ppc and i386 desktop are fine here ... i have just tested the first server iso, recognizing the ltsp breakage
<tfheen> ogra: please mark the ok images as such in the bug tracker (in progress)
<ogra> will do
<tfheen> thanks
<ogra> tfheen, https://launchpad.net/~ubuntu-core-dev/+branch/ubuntu-seeds/edubuntu.feisty says it has picked up the change
<tfheen> ogra: new server ISOs building; please reject the old server bugs.
<ogra> ok
<Riddell> mvo_: does the dist-upgrade upload you did last night still need approval by a distro manager?
<pitti> tfheen, ogra: hmm, current ppc/alternate doesn't boot for me
<ogra> right
* pitti md5sum checks
<pitti> argh, give me my CD back, you bloody ibook...
<ogra> pitti, "Kernel Bug at mm/slab.c:610!"
<ogra> thats what i see after a segfault ...
<pitti> ogra: I don't see anything, it just immediately returns to yaboot
<tfheen> ogra: but -desktop works?
<ogra> oh, intresting
<ogra> yep, -desktop is fine
<tfheen> weird.
* pitti too
<tfheen> I'll just not release -alternate for ppc then.
<pitti> tfheen: agreed
<pitti> tfheen: handy timing, this announcement :-P
<tfheen> pitti: yep, excellent, I'd say.
<ogra> heh
<tfheen> though, we have dropped releasing images in the past if they were broken and we didn't have time to fix them, so it's not the first time..
* tfheen wants a small SATA switchbox so he can jump between the test and real system on his machine..
<Lathiat> you used to be able to hack that up with IDE
<Lathiat> double pole switch with the jumpers
<Lathiat> on cable select
<doko> pitti: did we already agree on the maintainer address for main?
<tfheen> I'm fairly sure I can get it done with SATA too, I just need to solder a bit.
<jdong> Lathiat: lol yeah I've actrually seen one of those :)
<pitti> doko: no, it's on the agenda today
<Lathiat> tfheen: wouldnt be so easy 
<tfheen> Lathiat: why not?
<Lathiat> you cant just flick the order
<Lathiat> and if your moving the data lines on the sata cable
<Lathiat> mind interference on a crap switch
<pitti> tfheen, ogra: argh, silly me; burned the wrong CD *brown paperbag* burning again...
<tfheen> I'd have one cable per drive and just one to the controller and a physical switch to switch between them.  No need to munge about with ordering.
<Lathiat> my point being if your switching the data lines you have to mind how much interference your whacking in the line with a dodgy switch :)
<Lathiat> might be easier to simply power/unpower the drives
<tfheen> I'd power it off before switching.
<Lathiat> tfheen: im talking running interference
<Lathiat> because the link is shit, etc
<jdong> tfheen: SATA cables are so easy to hook up so why not just turn off and physically switch cables?
<tfheen> true, but I guess I can get that decent-ish.
<tfheen> jdong: because that requires me to crawl under my desk and I'm lazy.
<Lathiat> be interested to see if it works
<jdong> tfheen: haha :) works for me
<Lathiat> IDE version: http://www.youtube.com/watch?v=dSvRlJXoT_g
<tfheen> something like http://www.austech.info/showthread.php?t=145767
<Lathiat> eww that looks so ugly
<Lathiat> haha
<Lathiat> but yeh
<mvo_> Riddell: I think so, yes. but let me check
<cjwatson> pitti,doko: I did my best to merge your sets of debian-maintainer-field agenda items; shout at the start of the meeting if I missed anything
<pitti> cjwatson: thanks, will have a look
<cjwatson> Keybuk will send it out shortly, I think
<pitti> tfheen, ogra: ppc alternate installer boots fine here
<tfheen> pitti: coolie.
<asac> thep: you have an upstream bug you are engaged on?
<thep> asac, yes, it's bug #7969
<Ubugtu> Malone bug 7969 in lilo "lilo segfaults" [High,Rejected]  https://launchpad.net/bugs/7969
<pitti> Riddell: I just committed some missing apport-qt features, Michael Hofmann kindly added them (Details and complete/reduced radio button)
<asac> thep: in bugzilla? quite low number :)
<Riddell> pitti: reduced radio button?
<pitti> Riddell: radio button for sending a complete or reduced report
<thep> asac, of course, a very ancient bug
<asac> thep: whats the state on it?
<Riddell> pitti: oh, cool
<pitti> Riddell: where reduced == no core dump, for modem users
<thep> asac, i'm describing in details in a reply mail
<thep> asac, it's quite long. i also have some updates to propose for feisty
<asac> thep: thanks a lot ... we have to finally work it out with upstream... so I need all infos I can get :)
<ogra> tfheen, ppc works with video=ofonly for me, i never needed that before so i didnt try (even though an oops is still evil)
<tfheen> Riddell: how's the rest of kubuntu looking?
<tfheen> ogra: likewise; how's the rest of edubuntu?
<gpocentek> tfheen: did you had feedback from Jani about Xubuntu?
<tfheen> gpocentek: no, none at all.
<gpocentek> ok...
<tfheen> I'm making new xubuntu images now, I'll file bugs when they're ready.
<gpocentek> I really didn't have time to test isos, I'll try to do this today
<gpocentek> tfheen: thanks
<tkamppeter> Someone knows the usual way under Ubuntu to configure X if one has connected a new monitor?
<gnomefreak> tkamppeter: this is not a support channel. see #ubuntu for support
<tkamppeter> sorry, forgot to change to the right chnanel
<Keybuk> random: can we drop bazaar from feisty?
<Treenaks> Keybuk: yeah, who needs it...
<Treenaks> (or is bazaar the old pre-bzr thing?)
<Keybuk> it's confusing to people
<Keybuk> exactly
<Keybuk> demonstrating my point
<Keybuk> bazaar is the Arch thing
<Keybuk> and is not bzr
<Treenaks> # apt-get install bazaar
<Keybuk> so when you say to someone "install bazaar, and get http://bazaar.launchpad.net/..."
<Treenaks> apt: itym bzr. kthxbye
<Treenaks> # 
<Keybuk> the package they absolutely *do not* want to install, is "bazaar"
<Keybuk> :p
<bddebian> Heya
<Tonio_> pitti: you removed digikam from kubuntu desktop-i386 seed ? any problem with it ?
<elmo> Keybuk: dropping it entirely is a bit harsh - renaming it would probably be appropriate though
<pitti> Tonio_: Riddell did, to save spave
<pitti> Tonio_: space, too
<Tonio_> pitti: argh...
<Tonio_> pitti: okay :'(
<Tonio_> space on the cd becomes a real issue for further developpment...
<Tonio_> pitti: well thanks for the response ;)
<tfheen> Riddell: gentle nag; how's the testing going?
<heno> Riddell: I can help you with an amd64 or i386 image. Where is my help most useful?
<heno> ie which image is last on your own list?
<ogra> tfheen, edubuntu apart from amd64 desktop (and the video=ofonly thing with ppc) which i still have to test is all good
<heno> ogra: could you mark the good ones as In Progress here? https://bugs.launchpad.net/ubuntu-iso-tests/+bugs
<ogra> heno, can you open a set for server 20070215.1 ?
<ogra> and desktop 20070215
<mvo> heno: do you think we could add upgrade testing to the new schema as well?
<ogra> or am i free to do it ? (i see all bugs are opened by Ubuntu ISO testing)
<heno> mvo: Yes He we usually tracked those for alphas?
<heno> ogra: I think you can add bugs easily
<ogra> ok
<mvo> heno: good questions :) IIRC we had some basic testing 
<mvo> heno: not sure how much the community can help, its a lot of work without some sort of vm or snapshot functionality
<doko> pitti: libwps diff is now reduced
<keescook> tfheen: (or other archive admins) please shove my security update for imagemagick through for breezy, dapper, edgy.  :)
<pitti> doko: nice, thanks
<troy_s> security update for imagemagick?
<keescook> troy_s: yup.
<troy_s> keescook: What hole does it expose?
<keescook> troy_s: it's a fix for CVE-2007-0770 (PALM files)
<Mez> keescook, wanna work on the rar thing now, get it out the way ?
<keescook> Mez: yup, I was just about to switch gears and start looking at that.  :)
<Mez> sweet, well I'm here :D
* Mez slaps jdong
<keescook> Mez: do you have a tested debdiff for unrar?
* jdong wonders why he was slapped
<Mez> keescook, just making one for debian
<keescook> okay, I'll work on it.  :)
<Mez> keescook, are you ok to accept a debdiff including the debian version (New maintainer + dh_compat upgrade?)
<keescook> Mez: I'd rather not for stable release updates.  Mostly I'm just curious if a given debdiff has been tested on each of the stable releases.  :)
<Mez> ah kk
<Mez> just debian has -1 ubuntu has -0.1
<keescook> Well, once it's in Debian, I'll just request a sync for feisty.  that shouldn't be a problem.
<Mez> keescook, ubuntu already has the updated rar in feisty (I did a manual upload as debians version needs tweaking ubuntu's doesnt!)
<Mez> keescook, we're doing security releases for debian :D
<tfheen> keescook: the publisher is running now, so it should go as normal
<keescook> tfheen: great, thanks.
<heno> hm, I'm not getting rsync or http downlods from cdimage ATM
<iwj> dsc0t-mawktest       PASS
<pitti> iwj: autopkgtest FTW? :)
<iwj> pitti: Well, FTdraw for the moment I think.
<iwj> root@samual8:~/adt-play# lvchange -a n /dev/glalonde/adt_feisty_base
<iwj> Segmentation fault (core dumped)
<iwj> I think this may in fact be my fault.
<LNX1> hi ! A simple question for you ;o)
<Treenaks> this is not a support channel :)
<LNX1> What is the new compilation flag that make feisty so fast? (I think in glibc 2.5)
<LNX1> i known ;)
<LNX1> I dont need support
<crimsun> -fomgfast
<LNX1> thanks !
<_ion> -O9999
<_ion> -fgentoo
<pitti> lol
<LNX1> lol
<pitti> LNX1: we put doko in a room with just water and a computer and didn't let him out before he optimized gcc by factor 2
<LNX1> lol ;O)
<LNX1> ...but for sure, feisty is more responsivness on my laptop then edgy
<LNX1> sorry for my bad english ;)
<LNX1> thanks , I will discuss about that in the ubuntu channel ! thanks again guys
<jwendell> hi, pitti
<pitti> hi jwendell 
<jwendell> pitti, all packages must have a X-Ubuntu-Gettext-Domain in their .desktop file?
<pitti> jwendell: all .desktop files that have translatable strings, yes
<jwendell> pitti, so, we have to create a patch for it, right?
<pitti> jwendell: depends; if a source package uses cdbs, then you only need to include the standard gnome.mk
<jwendell> pitti, ah... ok
<pitti> tfheen: ok to upgrade tzdata from 2007a to 2007b for bug 83446?
<Ubugtu> Malone bug 83446 in tzdata "Daylight Saving changes in the United States, Canada, and Bermuda" [High,In progress]  https://launchpad.net/bugs/83446
<pitti> tfheen: (I'll prepare a SRU as well, but we need the package in feisty first)
<ogra> are we ufrozen already ?
<ogra> *un
<pitti> no, not yet, just getting UFV exception
<tfheen> pitti: yeah, looks sensible enough to me.  You've tested the changes?
<pitti> tfheen: I'll test them and scrutinize the diff
<tfheen> pitti: cheers.
<tfheen> ogra: so you're good, sans amd64 desktop?
<gpocentek> tfheen: is there a problem with the xubuntu desktop isos?
<ogra> tfheen, all good now
<ogra> apart from that video=ofonly uglyness
<tfheen> ogra: that's for an unsupported platform.
<ogra> right
<ogra> but still worth to be fixed :)
<tfheen> not for herd 4, no.
<ogra> (i'm in the community group supporting that platform :) )
<ogra> indeed ... but for release
<tfheen> ogra: sure, but ports have never hold up milestones, betas, previews or release.
<tfheen> gpocentek: no, I think it's fine.
<tfheen> gpocentek: ah, no, there's something wrong with the -desktop ones, yes.
<tfheen> I'll investigate.
<gpocentek> thanks :)
<gpocentek> amd alternate is OK, i'm rsyncing i386
<spike> hi
<spike> I'm currently looking at opening a bug against lvm2 package in edgy and would appreciate some directions on what to add to it
<pitti> tfheen: oh, false alarm, we don't need a new feisty package; these changes are already in
<pitti> tfheen: 2007b just fixes a single leap second (trivial diff); we can still update it, though
<spike> the problem is with the symlinking/automagic. after installation any command will produce something like: No program "lvmdiskscan" found for your current version of LVM
<spike> invoking /lib/lvm-200/$command will work just fine
<spike> not sure where the problem is since /lib/lvm-default/ is correctly a symlink to /lib/lvm-200/
<cjwatson> kylem: you volunteered to help out with X last week - do you think you could follow up to the thread on ubuntu-devel@?
<spike> altho it could be a problem with my Xen kernel..
<kylem> cjwatson, yup.
<cjwatson> mvo_: you muttered something too, if you have time
<kylem> cjwatson, i thought i had, haven't gotten that far into my mail yet.
<cjwatson> we should try to get that moving ASAP after herd-4, at least the initial round of syncs to make testing easier
<cjwatson> kylem: let's coordinate on #ubuntu-x tomorrow
<mvo_> cjwatson: yep
<kylem> cjwatson, ok.
<pitti> cjwatson: could you please sign-off bug 85394? I don't like approving my own SRU
<Ubugtu> Malone bug 85394 in tzdata "New timezone data 2007b" [High,In progress]  https://launchpad.net/bugs/85394
<victory747> I have a question about the daily feisty install cd.  I just downloaded the alt i386 install cd.  It seems there is no way to manually partition with LVM.
<victory747> I had to start it from the console with vgchange
<victory747> Is this a known issue, by design, or an oversight?
<_ion> It works with the Herd 3 server install CD at least.
<victory747> there was a guided whole disk lvm option
<victory747> but in manual option all there is is "guided partitioning" and "help on partitioning"
<cjwatson> victory747: you need to create individual partitions and select LVM physical volume under "Use as:" 
<cjwatson> victory747: then once you've got some of those you'll see an LVM configuration option appear on the main partitioner menu
<victory747> but i already have existing partitions
<cjwatson> you may have to tweak their use-as
<cjwatson> it might not have detected that properly
<victory747> the volume group is not even active when starting out
<victory747> so you mean select the pv choose LVM?
<cjwatson> yeah, Use as: physical volume for LVM
<victory747> that won't hose my existing volume group?
<cjwatson> then at the main partitioner menu, "Configure the Logical Volume Manager"
<victory747> ok, so this is by design
<victory747> but it doesnt' seem very intuitive
<victory747> it seems to me that if a pv already exists, it would be best to activate the vg so it shows up right away
<cjwatson> shouldn't affect the existing volume group, no
<victory747> let me back up and try that, then
<cjwatson> the problem with activating it is that it then becomes difficult to stop using LVM
<cjwatson> you're right that it's not ideal, though
<victory747> dealing with lvm in the installer has always been a pain when the lvm already exists
<cjwatson> it would really be better to show what it would be if activated, rather than actually activating it
<cjwatson> that sort of design would also get rid of some intermediate commit requirements
<cjwatson> but it's a good deal of work
<victory747> hmm
<victory747> the thing is, it shows what my filesystems are for all my partitions except the lvm when i start the partitioner
<cjwatson> right
<victory747> seems to me it should show that as well.
<cjwatson> right, hence "show what it would be if activated"
<victory747> yeah, i guess.  i guess i don't see why it can't be activated from the start
<victory747> since they are essentially "partitions" like any other partition
<cjwatson> my memory is that that made it much more difficult to delete PVs and replace them with something else
<victory747> you use and manage them like any other partition from a practical point of view
<cjwatson> possibly because the plumbing needed to tear down VGs wasn't there
<cjwatson> and that's just as difficult a usability problem
<victory747> so i guess you guys have thought about this
<cjwatson> I agree with you that the current situation is not optimal; I'm not defending it so much as explaining it
<victory747> hmm, maybe the partitioner needs an overhaul
<victory747> but since i'm not really willing to do the work . . .
<victory747> :)
<cjwatson> not really an overhaul, but LVM and RAID need to be improved and made to fit more into the general structure of the partitioner
<cjwatson> rather, the partitioner modules for handling same
<cjwatson> unfortunately I have no time for this
<victory747> yeah, that would be nice.  i have never liked the way it deals with lvm - very cumbersome
<victory747> i almost find it easier to do from the command line
<victory747> well, i think i understand how you are doing it now
<cjwatson> a way to inspect a VG without activating it would help. Do you know if such a thing exists?
<victory747> hmm.  
<victory747> well, you can use lvscan without activating a group, can't you?
<victory747> let me check . . .
<victory747> yes, they show up as inactive
<cjwatson> mm, I think so, although its output is not exactly desirable
<cjwatson> maybe something can be done with the underlying library code
<cjwatson> so the way that partman works for ordinary partitions on hard disks is that, rather than making changes immediately (with the exception of resizing), they're queued up in a model of the disk constructed in /var/lib/partman/device/
<cjwatson> devices/
<cjwatson> and then committed in one shot at the end
<victory747> is it too late to make changes for feisty?  maybe it doesn't really matter, but i've been doing this ubuntu/lvm thing for a while and I was quite confused
<cjwatson> but for LVM and RAID, we don't have code to represent them this way yet, nor a way to inspect the LVM/RAID nonintrusively
<victory747> oh yeah, but it had to "write" changes in the past before activating the volume groups
<cjwatson> (a) it's too late for major feature enhancements, (b) we don't have resources :-(
<victory747> i understand.  plus holding all that virtually would be quite a bit of work
<cjwatson> most of the LVM and RAID work is done in Debian
<victory747> so this change was a debian change?
<cjwatson> Simon Huggins has been refactoring RAID, I think, but more with an eye to autopartitioning
<victory747> i always do manual partitioning since my stuff is already there and my setup usually rather strange
<cjwatson> all the relevant work on LVM in this cycle was done in Debian, yes
<victory747> only do auto stuff when helping others install, but it's usually pretty simple
<cjwatson> I hadn't been aware that this particular thing had changed - I thought you always had to activate VGs manually
<victory747> um, maybe you could add a note to the help part about how to activate lvm if it already exists
<victory747> oh, well, in the past i didn't know how to do it manually
<victory747> so i would go to "manage lvm"
<victory747> and then it would activate it
<cjwatson> ah, the menu structure was changed a bit and it's possible that hiding that option when there are no PVs with the right method set was a recent change
<victory747> ok, that makes sense
<cjwatson> could you file a bug on partman-lvm (https://launchpad.net/ubuntu/+source/partman-lvm/+filebug)? I might be able to do something very constrained about that
<cjwatson> would need to compare how it worked in edgy
<cjwatson> pitti: ok, I'll have a look at that tomorrow
<victory747> i dist-upgraded to edgy so don't know that installer, but it's not that the 6.06 installer was that much more intuitive anyway
<victory747> i would almost prefer a note in the help files so someone could find it there
<victory747> that way it would not clutter the interface but someone looking for it could find it
<gnomefreak> didnt someone mention the installer would fail with no kernel found?
<victory747> Oh, I also had to modprobe dm-mod
<victory747> I forgot about that, too.
<victory747> I'll make a note of my experience in launchpad url you gave me
<cjwatson> I hate to sound negative, but the help files are actually a real pain for us to change :) they're translated and the resulting change tends to be extremely difficult to merge
<victory747> oh! :(
<cjwatson> so I'd much prefer something simpler if possible
<victory747> ok, well, 
<victory747> i'm not sure what to say
<cjwatson> gnomefreak: transient
<gnomefreak> k
<victory747> except if I didn't know about modprobe dm-mod and vgchange -a y 
<gnomefreak> ty
<cjwatson> having to modprobe dm-mod is certainly a bug, although I don't think that would have been necessary if you'd used the method I suggested from the start
<victory747> then I would not have been able to proceed
<cjwatson> was probably only because you were doing it by hand
<victory747> i was in the partitioner already
<victory747> maybe all i had to do was tag the partition as lvm
<victory747> then it would have all worked
<victory747> i can re-boot the installer and try again if you would like
<victory747> i just don't want to take a chance of hosing my pv/vg
<cjwatson> mark them as lvm and then select the configure-lvm menu item will modprobe dm-mod as part of its operation
<victory747> ok
<cjwatson> do_initial_setup() {
<cjwatson>         # load required kernel modules
<cjwatson>         depmod -a >/dev/null 2>&1
<cjwatson>         modprobe dm-mod >/dev/null 2>&1
<cjwatson>         modprobe lvm-mod >/dev/null 2>&1
<cjwatson> etc.
<victory747> I see.
<victory747> ok
<victory747> ok, well, my problem was that it was not at all intuitive to me, which may or may not mean anything
<cjwatson> what was the "use as" for the relevant partitions to start with?
<victory747> but i wonder about others who may be int eh same position I am
<victory747> I can't remember.  I think it was blank - nothing
<cjwatson> the current use should really be autodetected if at all possible
<cjwatson> fixing that would help
<victory747> you going to be around for a while?  next 15 minutes or so?
<cjwatson> and it is supposed to be autodetected
<cjwatson> nah, about to go to the pub for dinner
<cjwatson> I'll be back later on this evening for the distro team meeting
<victory747> i will re-start the installer and tell you what it's saying
<victory747> ok
<cjwatson> feel free to dump it into that bug
<victory747> should i try to file something, or just let it go for now?
<victory747> allright
<cjwatson> definitely file something or I'll forget
<victory747> thanks for your time
<cjwatson> np
<cjwatson> victory747: #ubuntu-installer is a bit quieter if you want to mention stuff there, and I'll pick it up later
<victory747> ok
<jwendell> fabbione, are you a vnc maintainer?
<mvo__> tepsipakki: would it be possible to add a Packages file to your xorg repository? this way, I would do some testing on the package relationships (e.g. if it upgrades cleanly)
<_ion> tepsipakki: Falcon (made by Seveas) is a *very* nice tool for maintaining an apt-getable repository.
<tepsipakki> mvo: sure
<tepsipakki> _ion: yes, I use that frequently
<ogra> kwwii, ping
<kwwii> ogra: pong
<ogra> kwwii, you promised me a cropped logo :)
<kwwii> man, I should complain about a contentless ping, but I am an artist and will let you go on that one :p
<ogra> i'm just working o the ldm greeter ...
<kwwii> ogra: yeah, let me do that real quick
<tepsipakki> mvo__: I'll do that later this evening
<kwwii> ogra: I'll send you one, just a minute
<ogra> thanks a lot :)
<kwwii> ogra: that pic probably won't work on the standard ubuntu bg though
<kwwii> never tried
<ogra> cairo is a beast ... and i hoped it would be easier than gnomecanvas
<kwwii> and now that I look at it, I wonder if sabdfl would like it ;-)
<ogra> it wont be on a standard ubuntu brown ...
<kwwii> cool
<ogra> rather something in red or orange direction ... even yellow might work .. 
<ogra> but surely not brown :)
<kwwii> cool
<_ion> kwwii: I take it you're the guy behind the new usplash artwork? It's really nice, thanks for your work.
<kwwii> _ion: glad to hear you like it, thanks :-)
<kwwii> _ion: I am getting paid to make it ;-)
* ogra got lots of good feedback for edubuntu as well ...
<mvo__> tepsipakki: thanks
<ogra> (for usplash)
<kwwii> ogra: good to know, I was kinda worried that it would not be playfull enough 
<ogra> i'm happy its a bit more friendly to my eyes :)
<ogra> its a bit out of place though, i need to fix the values in the code
<Burgwork> kwwii: got a linky to the image?
<kwwii> Burgwork: which one?
<Burgwork> kwwii: edubuntu upslash
<ogra> http://people.ubuntu.com/~ogra/usplash_1024_768.png
<ogra> meh, crap ... evo is broken ... 
* ogra dist upgrades to see if that fixes it
<kwwii> ogra: http://sinecera.de/edubuntu.png
<kwwii> sorry that I forgot
<ogra> thanks ... 
<kwwii> I'll help in any way I can with the ldm, btw
<ogra> no problem, i didnt need it yet
<ogra> i'll try o make it look as much like gdm as i can ...
<kwwii> I've made an svg for gdm, btw, so if you want to take that and simply change the colors, let me know
<kwwii> in fact, I have the edubuntu logo as svg too
<kwwii> but you do not want to use that as it has a gaussian blur and that would take forever to render live
<ogra> hmm
<ogra> actually it doesnt look to bad on the brown gdm background
<kwwii> I'll test it, one second
<ogra> the smooth blur makes it fit in very soft ... so the brown isnt to much in your face
<ogra> (still no option, but intresting to know that it doesnt look to evil)
<kwwii> ogra: not horrible but it could look better
<ogra> indeed
<ogra> i just had expected it to be worse 
<kwwii> I'll whip out my magic ubuntu palette tool and see what I can come up with
<ogra> you knw the colorpalette we use in metacity and gtk ? 
<ogra> *know
<kwwii> ogra: nope
<kwwii> but I can guess that it is a subset of the ubuntu colors, or?
<kwwii> red ir iirc
<ogra> http://shots.osdir.com/slideshows/slideshow.php?release=754&slide=4
<ogra> here is one with metacity border and highlighted selection http://shots.osdir.com/slideshows/slideshow.php?release=754&slide=13
<ogra> it uses ubuntulooks 
<ogra> and only has a different colorset
<kwwii> cool, it is pretty much the same palette that we have in ubuntu, only we use them differently
<ogra> right
<cprov> hi guys, does someone know how can I make a deb file using data.tar.bz2 instead of data.tar.gz ?
<elmo> cprov: look at diveintopython package
<thom> cprov: look at debian/rules for diveintopython
<thom> (dh_builddeb -- -Zbzip2)
<thom> elmo: heh :-)
<elmo> (and pre-depends on right version of dpkg)
<cprov> elmo: thom: good thanks
<Riddell> tfheen: sorry for being offline, my router decided to disconnect while testing
<Riddell> tfheen: but amd64 and i386 kubuntu cds are good
<kwwii> ogra: here is a quick idea...just changed the outer gradient color of the gdm bg: http://sinecera.de/ldm_bg_idea.png
<ogra> kwwii, yeah, thats similar to what i had in mind ... perfect !
<ogra> (fruity, you wanna bite it :) )
<kwwii> cool, I am making gdm this week, so I'll keep you in mind
<kwwii> yeah, very tangerine
<tfheen> Riddell: great, thanks.
<ogra> seb128, didnt you say we'd get the menu back for gnomecc ? i didnt have it on herd4
<seb128> ogra: I said to unmask them with alacarte menu editor for herd4 and we will get them back before feisty
<ogra> ah
<ogra> ok
<seb128> don't be lazy
<seb128> that's a few clicks only ;)
<ogra> heh, indeed ... i didnt understand i ha to use alacarte ... i have no prob with that 
<tepsipakki> mvo: deb http://users.tkk.fi/~tjaalton/xorg72 feisty xorg-test
<ogra> tepsipakki, complete ? 
<tepsipakki> yes
<tepsipakki> well
<tepsipakki> no drivers
<mvo> tepsipakki: oh, very nice, thanks!
<tepsipakki> I just upgraded my box and noticed that some were updated.. should've made it a repo right from the start ;)
<tepsipakki> and I have a newer xorg-server with a few more dropped patches, same for mesa
<tepsipakki> but they are on my laptop
<tepsipakki> maybe I'll dig them up
<st3> well, i'll cross-paste here too as i recevied no reply on -kernel
<st3> st3 we reported a critical bug about bcm43xx here: https://bugs.launchpad.net/ubuntu/+source/linux-meta/+bug/85404
<st3> st3 we are receiving a lot of bug reports from ubuntu users, please fix it asap
<st3> st3 thank you
<Ubugtu> Malone bug 85404 in linux-source-2.6.20 "bcm43xx completely broken in feisty" [Undecided,Unconfirmed]  
<st3> exactly
<geser> tepsipakki: is there at that url also the complete source availble? I'm trying to build it on my amd64
<tfheen> ogra: your serveraddon CD is fine too?  Not just your server CD?
<ogra> yep
<ogra> :)
<ogra> not much that can break atm
<tepsipakki> geser: yes
<tepsipakki> geser: you might want to hold a bit, there's a new version of x11proto-input which isn't there yet
<geser> tepsipakki: is xtrans-dev built from the package from Debian experimental? because I can't see the source there
<tepsipakki> oh, that too
<tepsipakki> I removed my version when it was uploaded to experimental
<tepsipakki> err, when the debian version was uploaded..
<Amaranth> tepsipakki: so does it look like they'll be ready in time to have a chance of getting into feisty?
<tepsipakki> Amaranth: what I've been told, yes
<tepsipakki> but that needs help when they hit the archive, to make sure any possible regressions are dealt with
<_ion> Great work, tepsipakki.
<tepsipakki> but debian guys are doing testing as well, and so far there are no showstoppers
<tepsipakki> _ion: thanks
<Amaranth> awesome
<ogra> BenC, i have a kernel oops on ppc with the recent herd release, i have to use video=ofonly to get it to boot ... which i didnt have to before
<pitti> seb128, mvo: post-install u-n for hwdb-client makes me happy
<mvo> pitti: you tried it already?
<BenC> ogra: can you send a photo of the oops?
<pitti> mvo: no, I mean the concept
<mvo> pitti: we need to talk a bit about getting good i18n for it
<mvo> pitti: great!
<pitti> mvo: we don't even need to touch u-n for that any more, right?
<BenC> ogra: BTW, I assume madwifi is working for you...is bcm43xx working any better?
<mvo> pitti: this is a weakness currently
<pitti> mvo: ah, right, no langpack support
<seb128> pitti: good, I think that's a good way as well
<ogra> BenC, yes, but not tonight anymore ... (i'm up and running since 13h)
<mvo> pitti: yep. also we could do something similar as for the desktop files maybe? you know more about that then I :)
<mvo> pitti: but yes, no need to touch u-n, just use what we have there
<mvo> + maybe langpack integration if possible without too much work (should be doable)
<pitti> mvo: let's talk tomorrow
<mvo> pitti: yes, I'm a bit tired
<mvo> pitti: but great that you came up with the idea!
<pochu> BenC: I'm not sure if you are the right person to tell it, or if it's a kernel bug, but ipw2200 (wireless) is not working anymore in feisty (bug 83637)
<Ubugtu> Malone bug 83637 in network-manager "Network-manager doesn't show any wireless network on ipw2200" [Undecided,Needs info]  https://launchpad.net/bugs/83637
<Fujitsu_> pochu: When did that happen? I was using it this morning.
<BenC> pochu: Doesn't work, or doesn't work with NetworkManager?
<BenC> those are two different things :)
<pochu> Fujitsu_: doesn't work
<pochu> with a clean install of herd 2, and yesterday daily-live
<BenC> pochu: Can you configure it from the command line?
<pochu> and some others daily
<pochu> BenC: I'm not very skilled with networking... :(
<pochu> BenC: interfaces?
<BenC> pochu: "ifconfig -a" do you see it in that list?
<BenC> if so, then the kernel's most likely not at fault
<pochu> BenC: is it eth1? If so, I see it
<BenC> pochu: iwconfig eth1
<BenC> if that looks sane (e.g doesn't say it isn't a wireless dev) then the kernels fine
<BenC> which means it's a network-manager bug
<pochu> BenC: when I boot, I sometimes see this message: intel_rng: blabla something can't remember
<BenC> pochu: Sure, intel_rng, doesn't exist...no big deal
<heno> who is looking after network-manager bugs?
<pochu> emilio@kiko:~$ iwconfig eth1 | grep Management
<pochu>           Power Management:off
<pochu> BenC: ^^ does that means my ipw is off?
<pochu> :S
<BenC> heno: I suspect it will end up in kernel-team's lap
<heno> ok
<BenC> pochu: No, it means power-management is off
<BenC> heno: At least the backend driver portions (UI is up to someone else)
<pochu> BenC: radio off  ESSID:""
<ogra> pochu, that means your kernelis fine .... you got a n-m bug
<BenC> pochu: radio is always off until it is configured I think
<BenC> pochu: if you have a radio kill switch, then that's easy to debug...flip the switch
<pochu> BenC: I don't know what radio means in a wireless card :S
<pochu> just I saw it's off...
<pochu> hehe
<pochu> ogra: but I don't have wireless, wether with NM or not
<BenC> pochu: You can work around this using the standard networking control panel to configure the device
<ogra> pochu, right but its not th ekernels fault 
<ogra> its a configuration issue
<tepsipakki> geser: now the repo should be fine
<tepsipakki> geser: added new source versions of xorg-server and mesa as well
<pochu> BenC: I tried it, without success. However I'm gonna try again
<BenC> pochu: Try again, and check iwconfig to see what's going on
<pochu> but then if everything is fine, wifi-radar should work, right?
<pochu> BenC: and another thing (there are no more hehe): when booting, I see a lot of messages similar to this: [some numbers]  PCI: Cannot allocate resource region...
<BenC> pochu: Just an annoying message...no real problems with that message
<pochu> BenC: ok, thank you. Going to test the wireless :)
<pochu> wifi-radar does not show any wireless. Don't know if it should or if it's also "broken"
<BenC> pochu: My only concern is if things like iwconfig/ifconfig can configure it...if that works, then it's some else's problem :)
<pochu> BenC: I'm trying to configure it with network-admin. should it work? and should dhcp work?
<BenC> hard to say...it should work
<pochu> ty
<st3> BenC> ogra: BTW, I assume madwifi is working for you...is bcm43xx working any better?
<st3> please check https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/85404/+viewstatus
<Ubugtu> Malone bug 85404 in linux-source-2.6.20 "bcm43xx completely broken in feisty" [Undecided,Unconfirmed]  
<ogra> st3, what makes you think madwifi is working for me ? i dont have any madwifi using HW
<st3> no, i was citing BenC
<st3> *quoting
<ogra> oh, ah
<ogra> well, since i dont have the firmware on fresh installs i couldnt test yet, my work system is behind and running 2.6.20-5-generic still
<ogra> but i'm currently upgrading ...
<BenC> st3: It was my understanding that bcm43xx dscape was supposed to work better than bcm43xx+softmac
<st3> not yet
<BenC> mjg59: ping
<imbrandon> BenC, ping ( please approve my request to join the PPC Community Dev Team )
<st3> it's still highly experimental, but it could even be ok, if you used the latest version
<BenC> st3: Are you the upstream maintainer of bcm43xx+softmac?
<st3> yes, i'm stefano brivio
<st3> (one of the maintainers)
* pitti hugs st3 and thanks him for making his Airport Extreme work :)
<st3> =)
<BenC> st3: Then maybe you can help the folks who have been getting oopses from stock bcm43xx in 2.6.20 :)
<imbrandon> BenC, that is if you have a moment , heh , btw i dident get a change to whoop you in bowling at the sprint , wait till ubuntu live / uds feisty ;)
<st3> BenC, i didn't see any report on the relevant mailing list, however, tell me
<BenC> imbrandon: hehe, bring it
<st3> *lists
<BenC> st3: let's continue this in #ubuntu-kernel
<st3> i'm there
<imbrandon> BenC, anyhow when you get a moment poke me through on LP please, i'm going afk ( i already hit the join button ) 
<imbrandon> l8tr all
<BenC> imbrandon: sure thing
#ubuntu-devel 2007-02-16
<mjg59> cjwatson: Yeah. I've no idea what's up.
<mjg59> BenC: Hi - here for a second
<BenC> mjg59: see st3's comments...seems the dscape bcm43xx is just plain broken and old
<BenC> ogra says current kernels don't work for him either
<mjg59> BenC: It's current as of last week.
<mjg59> I think it's due to some miscommunicaiton on the bcm43xx mailing list
<st3> BenC, mjg59, mb_ is the maintainer for bcm43xx-d80211, if you want any clarification about that
<BenC> st3, mb_: So which driver is the best to use?
<BenC> I don't want to get into a dscape vs. softmac debate, I just want to know which one will best support our users
<mb_> kernel.org -stable tree is always best. So currently 2.6.20, as there is no -stable released, yet
<mjg59> I've replied to the bug
<BenC> so we should stick with bcm43xx+softmac in stock 2.6.20?
<mb_> bcm43xx-d80211 is currently broken and doesn't work on all devices where bcm43xx-softmac des
<mb_> does
<mb_> Yes, please BenC
<mjg59> Well, no
<BenC> mb_: Thanks...that's the route we'll take then
<mb_> Thanks
<BenC> mjg59: Why not?
<mb_> Saves us a lot of headache ;)
<mjg59> stock 2.6.20 doesn't work usefully on 4611 and 4612
<mjg59> Whereas there's code that does do that
<st3> 4311 and 4312?
<mjg59> Sorry,y es
<st3> you might use patches from larry finger
<mb_> ftp://lwfinger.dynalias.org/patches
<mjg59> So at the very least, it's likely to be something closer to wireless-2.6 or whatever Larry's providing
<st3> ftp://lwfinger.dynalias.org/patches
<mb_> You might want to apply these
<st3> oops
<mjg59> But right now, we want to get a better understanding of what the state of d80211 is so that the transition can be made at the appropriate time
<BenC> I'm willing to transition when stock kernel does
<mjg59> Well, we'll be including d80211 anyway for the sake of iwlwifi
<mb_> mjg59: ok, but please don't let your users run it with bcm43xx. It's a regression :)
<BenC> when userspace catches up, and when more drivers are using it
<st3> what we don't understand is, what version of -d80211 did you put in the kernel?
<mjg59> st3: A fresh pull from wireless-dev last week, along with Michael's current tree
<mb_> But that's d80211 only?!
<mb_> The bcm43xx-d80211 driver is damn old
<mb_> in your tree
<BenC> st3: Do you have a suggested list of patches from that ftp?
<mjg59> mb_: Right, I get confused here. I pulled from your tree on Saturday.
<mjg59> mb_: git-log has the 4311 and 4312 fixes in it
<st3> BenC, ftp://lwfinger.dynalias.org/patches/patch_2.6.20_for_DMA_over_1GB
<st3> this one
<st3> plus
<mb_> I think 2.6.20-combined only, BenC. But best contach Larry before pulling it in.
<mjg59> mb_: And the patches I sent you were based off that tree
<st3> mb_, do you know if larry released that patch for 4311 and 4312?
<mjg59> mb_: Can I just check which code you're looking at?
<st3> yes BenC, please contact larry.
<mb_> mjg59: patches you sent me?
<mjg59> mb_: Oh, I may only have sent you an SSB one in the end
<mjg59> mb_: To fix the parent field in the devices
<BenC> it seems that radio and 1G are the only two, from the README
<mb_> Ah, yes. That one mjg59
<mjg59> BenC: Wait. Did you apply the patch I sent you months ago?
<st3> "iwlist fixes, and resume fix" too
<st3> resume fix isn't actually working, iirc
<mjg59> BenC: If so, yes, that's very ancient and would explain a great deal
<mjg59> BenC: You should certainly drop that - I pushed Kyle some more code last week, so I assumed that it was that stuff
<mjg59> mb_: Sorry, I think I've figured out what's going on now - some internal miscommunication :)
<mb_> :)
<mjg59> mb_: You're right, that code's ancient. I'll get that fixed ASAP
<mjg59> BenC: Did you get those last few bits?
<BenC> sorry, I missed the last comments
<mb_> I was damn surprised to see it being included in a distro now, as I dropped it months back :)
<mjg59> BenC: Did you apply the dscape patch I sent you months ago?
<BenC> that's the only one I had
<mjg59> BenC: Ah. Yeah, drop that. It's ancient.
<mjg59> BenC: I pushed some stuff to Kyle, so I'd assumed that that was what got in
<kylem> still reviwing it.
<BenC> if you have a newer dscape, I can put that in
<mjg59> BenC: So we're definitely not getting the driver-selection stuff?
<BenC> I think for bcm43xx, I want to revert to the stock one, and apply any needed patches to get stuff we want out of it
<BenC> driver-selection?
<mjg59> Supply multiple drivers, let the user choose which is used
<BenC> you mean the driver-device-manager stuff?
<BenC> Keybuk never got a chance to do the udev bits for it
<BenC> so it got defered
<BenC> so we're stuck with one-driver-per-device for feisty still :)
<mjg59> Ok
<mjg59> Hm. We could provide bcm43xx-d80211 without any modalias :)
<BenC> could comment out MODULE_DEV_TABLE()
<mjg59> Yeah
<BenC> kylem: If you can't get the time to do dscape, can you just punt me those patches and I'll merge?
<kylem> sure.
<BenC> maybe they'll fix rt2x00 build with it aswell
<kylem> eating dinner now tho. :)
<BenC> kylem: Bear meat?
<kylem> haha. no.
<kylem> moose.
<BenC> my mom gets a lot of bear meat...pretty damn good stuff
<BenC> much better than black anus
<kylem> i... wouldn't know...
<BenC> mb_, st3: Thanks for your input...hopefully we'll get this sorted out soon so our users stop bugging you :)
<mb_> :)
<st3> =)
<BenC> st3: And don't hesitate to send me any patches you think I might be interested in
<st3> well, ok, i'll tell larry too
<BenC> thanks
<st3> np
<st3> anyway, we work in order to get the stable software in mainline, so please watch -stable, too
<mjg59> We generally pull from stable
<mjg59> So yeah, that shouldn't be a problem :)
<mjg59> Anyway, bed now.
<Tonio_> imbrandon: ping ?
<imbrandon> pong
<imbrandon> Tonio_, 
<xstasi> hi
<xiq> is it possible to get the actual scripts (etc) which are used to build the release livecd?
<poningru_> so quick question re: the zalewski vuln, the upstream branch & trunk just got the patch in
<poningru_> err in firefox
<poningru_> I was wondering if anyone was working on getting the patch into our firefox
<poningru_> https://bugzilla.mozilla.org/attachment.cgi?id=255252
<poningru_> so...
<xiq> is it possible to get the actual scripts (etc) which are used to build the release livecd? (not a customisation script, but whatever is used to make the real livecd in the first place)?
<Hobbsee> xiq: the fact that you didnt get an answer the first time, and the fact that hardly anyone is talking *probably*  means that they're all asleep
<xiq> then they won't mind me asking a second time... unless they all have tts systems running to keep the memory of wargames alive and well...
<sistpoty> xiq: iirc this question was raised on the ubuntu-devel mailing list a few times... maybe you can find an answer there (e.g. google site:lists.ubuntu.com livecd)
<fabbione> morning
<xiq> sistpoty: thanks, i'll look through it..
<alex-weej> is the "importance" field only for bug triagers on LP?
<alex-weej> or can it be set by reporters too, somehow (i know i know)
<Hobbsee> alex-weej: for those in ubuntu-qa.
<Hobbsee> alex-weej: effectively the triagers
<alex-weej> ok
<Amaranth> alex-weej: reporters would mark all of their bugs as critical :P
<alex-weej> irresponsible :P
<jdong> Amaranth: people like that need a good serving of the devil's bug 666
<Ubugtu> Malone bug 666 in malone "can't file a bug on Ubuntu" [Medium,Rejected]  https://launchpad.net/bugs/666
<pitti> Good morning
<LaserJock> hi pitti 
<ajmitch> morning pitti 
<pitti> hey ajmitch 
<Burgundavia> pitti: thanks for doing that cupsys dapper bug
<Burgundavia> pitti: I need to fully test it, but I think that might be the fix
<pitti> Burgundavia: you're welcome, sorry for the delay
<Burgundavia> no worries
<Burgundavia> it means the final FC4 machine in my office can now bite it
<pitti> siretart: ping
<siretart> pitti: You sent me a contentless ping.  This is a contentless pong.  Please provide a bit of information about what you want and I'll respond when I am around.
<pitti> heh
<pitti> siretart: I'm just reviewing the ffmpeg MIR -- doesn't xine-lib contain a static code copy anyway?
<Amaranth> I thought we didn't want a million copies of it
<pitti> Amaranth: right, that's the idea
<fabbione> siretart: ICMP_ECHO_REQUEST
<pitti> Rationale:
<pitti>     *
<pitti>       Build dependency of xine-lib
<fabbione> siretart: your script is owned
<qiyong> is ubuntu alwasy depends on debian?
<qiyong> and how to upgrade to the newest ubuntu?
<pitti> qiyong: please see topic; please ask in #ubuntu
<qiyong> pitti, no one knows there seems
<qiyong> pitti, and i'm trying to get into the latest ubuntu for development purpose
<Amaranth> qiyong: you waited 3 minutes
<qiyong> Amaranth, waited hours already
<qiyong> i think i should run a newest ubuntu in order to develop it, like debian sid
<pitti> qiyong: sudo update-manager -d should do
<qiyong> pitti, and that can bring me into the newest? (i'm in 6.06 LTS)
<Chipzz> qiyong: the fact that no-one in #ubuntu knows/answers still doesn't make this the right place to ask
<siretart> pitti: yes, xine does contain a snapshot of ffmpeg
<pitti> siretart: I just checked; that makes it a snap :)
<siretart> pitti: :)
<pitti> siretart: new x-l will b-dep on ffmpeg then
<siretart> pitti: no, I can't directly, the ffmpeg package is outdated, I need to package a new upstream version first, and get UVF approval for that
<Chipzz> pitti: http://blogs.gnome.org/view/uraeus/2007/02/15/0
<qiyong> Chipzz, i want to begin my ubuntu devel life
<siretart> pitti: first I needed to have ffmpeg in main, after that, I can think about upgrading the package :)
<pitti> siretart: that sounds fine; if it brings the code in sync with the version xine-lib has
<pitti> siretart: oh, why not the other way round?
<siretart> pitti: because this breaks other packages build depending on ffmpeg, which I didn't want to needlesly break. I had concerns that the ffmpeg package makes it into main at all
<LaserJock> qiyong: in a short time Feisty Herd 4 will be released, installing and testing that would be a great way to get started
<pitti> siretart: I see
<qiyong> LaserJock, i don't like a fresh reinstall, i'd like some upgrade
<Burgundavia_> pitti: basically the ffmpeg developers have no idea bout api/abi stability
<qiyong> LaserJock, i don't like install from new CD 
<Burgundavia_> nor do they understand the word "release"
<pitti> Burgundavia_: I know :/
<Chipzz> qiyong: if you really want to start developing for ubuntu, a first good step would be to learn how to figure out stuff on your own; ie learn how to use google, how to read docs etc...
<siretart> pitti: the other thing is, that even in debian there isn't a new ffmpeg version, so I have to package it myself. 
<LaserJock> qiyong: that's a pity, testing fresh installs is important
<LaserJock> qiyong: what you do is upgrade to 6.10 and then upgrade to 7.04
<Chipzz> qiyong: like LaserJock said; direct upgrades from LTS to feisty (7.04) are not supported
<qiyong> LaserJock, by update-manager? or by a new CD?
<pitti> siretart: oh, this also requires a libdts MIR
<qiyong> Chipzz, how about 6.04 to 6.10?
<Chipzz> you mean 6.06
<LaserJock> qiyong: either way will work
<qiyong> Chipzz, yeah
<Chipzz> and yes, both 6.06 -> 6.10 and 6.10 -> 7.04 are supported; 6.06 -> 7.04 is not
<siretart> pitti: well, ffmpeg includes an own copy of libdts and a52. I'd suggest that we promote them as well, but that's not strictly necessary
<pitti> siretart: oh, I see; well, let's not bother now
<ajmitch> siretart: ffmpeg sounds like a scary mess
<Chipzz> siretart: did you read http://blogs.gnome.org/view/uraeus/2007/02/15/0 ?
<siretart> ajmitch: it is. nevertheless, xine is pretty useless without it
<Chipzz> siretart: that's the gstreamer developer; but I'm sure similar views are held by the xine camp
<Chipzz> s/the/a/
<siretart> Chipzz: I didn't read the blog entry before, but I know the problems with that
<Chipzz> while I think having a seperate ffmpeg package is a laudable goal, I'm not really sure how practical it is while the ffmpeg api is still unstable?
<tfheen> http://err.no/tmp/herd-4 ; critisisms welcome.
<tfheen> cjwatson: ^^ ; I left in a reference that the new partitioner UI is not there yet, is that ok?
<fabbione> Edubuntu:
<fabbione>   http://cdimage.ubuntu.com/edubuntu/releases/feisty/herd-3/
<fabbione> tfheen: ^^
<tfheen> fabbione: the URLs need to be fixed; known; thanks.
<fabbione> ok
<tfheen> edubuntu fixed, I still need to add some more URLs there.
<fabbione> tfheen: looks ok otherwise
<pitti> siretart: I added my approval stamp
<pitti> siretart: ok, the package will actually be promoted when something in main b-deps on it; thus, whenever you upload an updated xine-lib with the b-dep, ping me or another archive dude, and we'll promote immediately
<pitti> siretart: does that work for you?
* pitti gives siretart a big hug for going through this trouble
<fabbione> who does approve UVF exceptions now?
<pitti> fabbione: tfheen?
<fabbione> pitti: ok thanks
* fabbione is a bit lost with all changes around the team 
* pitti hugs fabbione 
<Burgundavia_> is mdz stepping back to handle bigger issues now?
<pitti> Burgundavia_: mdz doesn't scale as well as the number and size of tasks :)
<pitti> Burgundavia_: we tried hard to clone him, but the clone just played the guitar all day long
<pitti> (although that was really beautiful :) )
<tfheen> fabbione: the release team, as it has always been.
<Burgundavia_> pitti: indeed. Clearly we need human cloning :)
<fabbione> tfheen: ok.. i just got confused with archive admin changes
<fabbione> tfheen: there was too much overlap before :)
<tfheen> true, those often end up overlapping quite a bit
<fabbione> tfheen: anyway... while waiting for kernel and userland to build.. i would like a UVF exception for redhat-cluster-suite. I need to sync CVS code for gfs-kernel to build and work with 2.6.20 and a bunch of bug fixes in fence agents (like yay.. autoconf for manual fencing)
<fabbione> tfheen: note the package has always been on CVS snapshots
<giftnudel> good morning all (or whatever the equivalent in your timezone is)
<tfheen> fabbione: debdiff?
<fabbione> tfheen: sure.. it's quite big tho... removed local patches that are now upstream and stuff like that too...
<tfheen> fabbione: as long as that's documented in the changelog, that's fine.
<tfheen> fabbione: and it being big is a point against it, not in favour. :-P
<fabbione> tfheen: hehe
<fabbione> tfheen: http://people.ubuntu.com/~fabbione/rh.debdiff
<fabbione> tfheen: i didn't document the test suite changes because we don't ship it.
<tfheen> fabbione: ugh, it is quite big, yes.
<fabbione> tfheen: yes i know and I know it's safe tho.. the hard part is to convice you about it :)
<tfheen> fabbione: approved; In the future, I'd like some bug references too, but we're early in the UVF period so that's fine.
<fabbione> tfheen: i usually reference to their bugzilla during development.. if you want i can go grab a few
<tfheen> fabbione: no, that's fine.
<fabbione> ok thanks
<fabbione> like my cluster hanging in less than 4 seconds :)))
<fabbione> it took them about.. hmmm 4 months to fix it
<pitti> asac: do you see any reason to keep mozilla (1.7.x) and all its plugins/locale packages in universe? geser and I would like to remove it since it's obsolete, vulnerable, and unmaintained; if we don't remove it, someone needs to update those packages to SeaMonkey, do you think that's worth pursuing?
<tepsipakki> tfheen: would you mind syncing nfs-utils from debian experimental? It's a newer upstream snapshot, also it has a patch which makes root-access work when kerberos is in use
<tepsipakki> bug #83435
<Ubugtu> Malone bug 83435 in nfs-utils "please sync nfs-utils (main) from Debian experimental" [Undecided,Unconfirmed]  https://launchpad.net/bugs/83435
<Burgundavia_> tepsipakki: how is the xorg work coming?
<tepsipakki> Burgundavia_: all is well ;)
<tfheen> tepsipakki: I'll take a look at it.  Sesse told me about it a couple of days ago.
<tepsipakki> and 7.2 was officially released yesterday
<tepsipakki> tfheen: cool
<cjwatson> tfheen: yeah, that's ok
<pitti> hey seb128
<seb128> morning pitti
<ajmitch> hi seb128 
<seb128> Hi ajmitch
<seb128> pitti: I can do a syncs round if you want, I didn't really do admin work on wednesday due to the freeze
<ogra> according to the topic its still in effect 
<pitti> seb128: I'll do my archive day today, but go ahead if you want to do syncs; there's enough work left :)
<pitti> oh, no freeze any more
<seb128> pitti: ok, doing syncs now
* ..[topic/#ubuntu-devel:pitti] : Development of Ubuntu (not support, even with feisty; not application development on Ubuntu) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<ogra> thanks :)
<seb128> ogra: from the -changes list there is no freeze :p
<ogra> hehe
* ..[topic/#ubuntu-devel:tfheen] : Development of Ubuntu (not support, even with feisty; not application development on Ubuntu) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Herd 4 released
<giftnudel> hehe
<cjwatson> seb128_: if you're doing syncs, could you pop into #ubuntu-x?
<pitti> mvo, ogra, seb128: I updated https://wiki.ubuntu.com/IncreaseHardwareDatabaseParticipation according to yesterday's discussion and discussion with mvo about the u-n details; I'd appreciate a short peer review
<pitti> seb128: NB that I dropped the 'will restore its menu item' sentence ;)
<seb128> ;)
<seb128> looking
* ogra looks
<pitti> seb128: the notification will just point out where it can be found, and offer a button to start it right away
<pitti> so we get the 'easy to find and do' for the first time, and avoid cluttering
<ogra> We will a post-installation update-notifier notification...
<ogra> We will add ?
<pitti> erm, yes, thanks
<pitti> this sentence no verb...
<ogra> :)
<mvo> pitti: I would like to renamed the field to "GettextDomain"
<pitti> ogra: that wasn't even my sencente :)
<mvo> (details..)
<pitti> mvo: done
<mvo> thanks
<pitti> fixed both and saved
<ogra> looks fine
<pitti> thanks for the review
<ogra> seb128, ah, there is a proper gnome-screensaver -> gdm_socket fix :)
<seb128> ogra: ah?
<seb128> ogra: where?
<ogra> http://svn.gnome.org/viewcvs/gnome-screensaver/trunk/src/cut-n-paste/gdm-queue.c?rev=1078&r1=1095&r2=1078
<seb128> ogra: what happens if it doesn't find the socket then?
<ogra> seb128, what does VE_IGNORE_EINTR do ?
<seb128> dunno
<seb128> I need to look at that
<ogra> http://bugzilla.gnome.org/show_bug.cgi?id=407524
<Ubugtu> Gnome bug 407524 in daemon "Freeze on unlock screen" [Normal,Resolved: fixed]  
<pitti> ogra: can you please commit/push your recent hwdb-client changes into bzr?
<ogra> pitti, who holds the upstream branch  ?
<ogra> mine is totally outdated 
<pitti> ogra: I used sftp://bazaar.launchpad.net/%7Eubuntu-core-dev/hwdb-client/trunk/
<ogra> ok
<pitti> ogra: but that has ubuntu21, but feisty has ubuntu23
<pitti> with these two uploads from you
<pitti> s/from/being from/
<ogra> yep, i'll push my stuff
<pitti> ogra: thanks
<pitti> ogra: btw, shouldn't this get a native version number?
<pitti> ogra: 0.6.1 perhaps?
<ogra> pitti, yes
<pitti> or is there an upstream branch somewhere?
<ogra> nope
<ogra> pitti, i forwarded you a hal patch i just got ...
<pitti> seb128: hm, I wonder where the hal-device-manager entry is nowadays? I can't find it in c-c
<pitti> seb128: but I need it to refer to it in the hwdb first-time notification
<seb128> pitti: I need to fix that, it's to app, system tools atm
<pitti> seb128: hm, not for me
<ogra> seb128, hal device manager itself is gone
<seb128> pitti: ups, right, I mixer with hdwb-client, it's not listed by the shell because the desktop is installed to /usr/share/control-center-2.0/capplets and not /usr/share/applications
<pitti> seb128: just to avoid confusion: we *do* want an icon for h-d-m in control-center, and we *don't* want any icon/menu entry for hwdb-client, right?
<seb128> pitti: correct
<gpocentek> tfheen: hello! could you publish yesterday xubuntu isos as Herd 4? They are OK for me (I couldn't test powerpc though)
<pitti> seb128: ah, nice, I'll fix the path
<seb128> ok, thank you
<pitti> seb128: I have some pending hal fixes in bzr head that I'd like to release now anyway
<pitti> seb128: and that will drop a patch :)
<seb128> thank you
<pitti> seb128: ugh, could you please commit your recent hal upload to bzr or just send me a debdiff?
<seb128> what hal upload?
<seb128> I did one during the distro sprint
<pitti> seb128: oh, sorry, that was ogra's
<seb128> and pushed the changes to bzr
<seb128> ok, np ;)
<pitti> ogra: ^ you then :)
<shawarma> /win/win 2
<pitti> ogra: please merge with the 4ubuntu6 UNRELEASED changes in bzr head, shouldn't give any conflicts
<shawarma> Doh..
<tfheen> gpocentek: ok, thanks.  Will do.
<pitti> ogra: nevermind, I still have hal_0.5.8.1-4ubuntu5.diff.gz on my disk, I'll do the hal merge
<pitti> seb128: ah, moving .desktop helps, I uploaded the new hal
<tepsipakki> so I guess it won't be a problem, if the queue isn't that long
<ogra> pitti, why wasnt that moved ? i didnt touch anything ... wrt .desktop
<mitsuhiko> moin
<pitti> ogra: I meant, you forgot to commit the hal -4ubuntu6 upload to bzr; I did that now
<mitsuhiko> is there a sane explanation why such a package exists: http://packages.ubuntu.com/edgy/libdevel/libopenexr-dev ?
<pitti> ogra: I just need your two hwdb-client uploads in bzr, since I work on it right now
<tfheen> mitsuhiko: what are you asking about?
<mitsuhiko> both the edgy and feisty version is in main but not installable because the dependencies are not in the repository
<mitsuhiko> xlibmeso-glu-dev is not part of any ubuntu repository.... but a dependency of that package
<ogra> pitti, i'm on it ...
<tfheen> mitsuhiko: libglu1-mesa-dev provides libglu-dev
<cjwatson> seems to be installable just fine if you use apt rather than grovelling around in packages.ubuntu.com by hand
<mitsuhiko> tfheen: why is apt-get/synaptic unable to install libglu1-mesa-dev in it's own then when i try to install libopenexr-dev?
<cjwatson> ah, of course I had libglu1-mesa-dev installed in advance
<cjwatson> somebody should update those dependencies so that the preferred ones are correct for Ubuntu
<mitsuhiko> tfheen: anyway. thanks for the help
<cjwatson> in fact I'll just do that now
<tfheen> mitsuhiko: seems to be installable just fine here, and I don't have libglu1-mesa-dev installed.
<cjwatson> mitsuhiko: if your apt cache is already inconsistent, then apt will be significantly less clever; try apt-get -f install first
<mitsuhiko> cjwatson: i must admit that something is screwed up here. after compiling a recent p2yk (python3000) pycentral does not work any more :-/
<ogra> pitti, done
<mitsuhiko> that new python-support stuff in debian is a bit strange :(
<pitti> ogra: danke
<Chapay> hello from russia !!!
<pitti> Chapay:  !
<Chapay> pitti:   :)    !?
<pitti> Chapay: I'm afraid my Russian ends there :/
<jwendell> wow... russian class? :)
<cjwatson> mitsuhiko: openexr fixed in feisty, once it builds
<pitti> Chapay:   -    :-*
<jwendell> pitti, yesterday i made my first ubuntu patch with cdbs, thanks to your class!
<Chapay> pitti: , where are you from !?
<pitti> Chapay: Germany
<pitti> jwendell: great! any questions left?
<jwendell> pitti, just one:
<pitti> Chapay: anyway, off-topic here :)
<Chapay> pitti: ^)
<Chapay> :)
<jwendell> pitti, i do an apt-get source package; cd package; cdbs-edit-patch 01_trivial.patch
<jwendell> pitti, is there a pratical way to test my patch?
<pitti> jwendell: sure, build the package and install the .debs :)
<Chapay> where i can dowload ubuntu installer source !?
<jwendell> pitti, actually i've made a copy of that directory and compiled it separately
<pitti> jwendell: sudo apt-get build-dep <sourcepackagename>; debuild -us -uc
<Chapay> :(
<pitti> Chapay: apt-get source ubiquity
<jwendell> pitti, i'm asking this because that hole process (generate and install .deb) can take many time, so, if i did something wrong in my patch, i have to do all that proccess again
<Chapay> pitti: i`am not have inux on my work :( i need url
<pitti> jwendell: if you can run the program from the build tree, just do 'debian/rules build' once, and then just do 'make'
<pitti> jwendell: that *usually* works
<jwendell> pitti, hmmm, cool
<tfheen> or use ccache
<jwendell> tfheen, excuse me? what is ccache?
<seb128> jwendell: apt-cache show ccache
<thom> jwendell: apt-cache show ccache
<seb128> hi thom ;)
<thom> hey ;-)
<tfheen> the best development tool since coffee.
<tfheen> or editors.
<tfheen> or compilers.  Or anything.
<thom> seb128: i'm gonna be in your crazy country from this evening :-)
<seb128> ah, cool. moving there or just holidays or something? ;)
<pitti> thom: Vive la France!
* seb128 hugs pitti
* pitti hugs thom
<thom> seb128: skiing in morzine
<seb128> ah, k
<seb128> have fun then ;)
<thom> hey pitti :-)
<thom> ta :-)
<jwendell> seb128, just installing this package, i'll get its benefits automatically?
<seb128> jwendell: you have to change your PATH, look at the package documentation
<Chapay> who can help me !!! Where i can get ub untu installer source !?
<pitti> Chapay: http://archive.ubuntu.com/ubuntu/pool/main/u/ubiquity/ubiquity_1.3.21.tar.gz
<cjwatson> Chapay: http://wiki.ubuntu.com/InstallerDevelopment (and stop using panicked!!! punctuation!!! please)
<Chapay> cjwatson: sorry ^)
<Chapay> cjwatson: sorry :)
<Chapay> pitti:  :)
<asac> pitti: right .... actually no ... we have to remove mozilla if we don't upgrade it to seamonkey/iceape.
<pitti> asac: yup; I meant, do you agree to just getting rid of it?
<Keybuk> iceowanttokillwhoeverthoughtofthesesillynames
<asac> pitti: if it just needs a word to drop it ... i would say so.
<pitti> asac: ok, I'll do so this afternoon when I'll do archive stuff
<asac> Keybuk: actually, i was involved :)
<Keybuk> asac: did you do the humping weasel as well? :P
<asac> hey ... we needed something ;)
* Keybuk is still waiting for Debian to start shipping the Cherokee web server
<pitti> Keybuk: :)
<pitti> Keybuk: and YourSQL?
<asac> i talked quite extensively with upstream about our options about not renaming them ... we had ZERO options ... so don't blame debian
<pitti> Mithrandir is back!
<Mithrandir> pitti: indeed.
<Keybuk> asac: but no other distribution has had to rename them ...
<ogra_> oh, incognito is over :)
<Keybuk> what makes Debian so special?
<Keybuk> (stop sniggering at the back, there)
<asac> Keybuk: don't know why others ship it ... I guess they have a less tight policy on what can be shipped. For debian, firefox logos are non-free (in terms of copyright) atm.
<Keybuk> asac: almost every graphic and font in Debian is also non-free
<Keybuk> yet they turn a blind eye to those
<cjwatson> is it really necessary to have this discussion YET AGAIN?
<asac> hehe
<asac> i don't want it :)
<pochu> BenC: ping?
<pochu> BenC: do you remember my wireless problem? Stupid me! I had pressed the wireless button (I have an acer) so the wireless didn't work (even in edgy). But now everything is fine. Thanks anyway!!
<Mez> keescook, ping (rar etc etc)
<jdong> pochu: ben's probably thinking to himself 'man if all problems were this easy....'
<Mez> jdong: BenC is probably thinking "mmmm sleep"
<Mez> :P
<jdong> BenC: 's probably thinking why we're pinging him so much
<Mez> jdong: lol
<jdong> but I love you BenC, and thanks in advance for merging reiser4 later today!
<jdong> LOL
* jdong hopes he hasn't induced any nightmares
* mvo_ wonders if something is wrong with bazaar.lp.net
<Hobbsee> mvo_: see #launchpad
<Fujitsu> Hobbsee: DB vacuuming, another 5 or 10 minutes.
<Fujitsu> Oops, mvo_.
<mvo_> Hobbsee, Fujitsu: thanks
* mvo_ waits patiently
<Hobbsee> :)
<jdong> mvo_: not gonna set up a nice for loop hammering launchpad till it comes back up? :D
* popey tags Mez, "You're it!"
<jdong> Mez: aah! hurry, switch to bzr! he can't tag you there!
<Treenaks> jdong: friday afternoon geek jokes!
<jdong> Treenaks: friday _morning_ geek jokes :D
<Treenaks> jdong: 14:10 - afternoon :)
<jdong> Treenaks: I just joined. Hence morning.
<Mez> jdong, it's popey and I's game of IRC tag
<jdong> lol
* jdong initiates his e-mail checking routine
<imbrandon> jono, ping
<jono> imbrandon: pong!
<imbrandon> heya bro missed yall at SCALE heh, but i'll catch up soon enough somewhere along the way
<imbrandon> but hey i got an idea i want to run by you before i blog about it, got a half sec
<imbrandon> ?
<jono> imbrandon: cool, but I don;t have long, about to catch a flight
<Hobbsee> jono!!!
<jono> hey Hobbsee :)
<Hobbsee> :D
<pochu> is the london office open to the public? :)
<Keybuk> pochu: no; why?
<Keybuk> (it's neither very large, nor interesting, since the development staff all work from home)
<pochu> Keybuk: oh, ok. because I'm travelling to london this afternoon, till monday :)
<seb128> Mithrandir, pitti, cjwatson: could any of you have a second look on xcb-proto (source NEW coming from Debian for xorg 7.2) before I accept it? Just to make sure I make no mistake with source new (it should be safe since the package comes from Debian)
<pitti> re
<pitti> seb128: will do, I'm just about to start archive stuff anyway
<seb128> pitti: thank you
<Keybuk> pochu: it's where the admin and business development teams work from; unless those particular departments interest you? :p
<seb128> pitti: I'm taking a syncs lock again, I'm helping on the xorg syncs atm
<jwendell> pitti, i'm trying to improve 'tsclient'. When i run debuild for the second time, i get an error like that:
<pitti> seb128: that's fine; I'll do removals and NEW
<jwendell> Trying reverse patch debian/patches/99_autogen.patch at level 1 ... 0 ... 2 ... /bin/sh: line 28: 14829 Done                    $cat $patch
<jwendell>      14830 Aborted                 (core dumped) | patch -d . $reverse -E --dry-run -p$level > $logfile 2>&1
<jwendell> failure.
<jwendell> make: *** [reverse-patches]  Error 1
<jwendell> debuild: fatal error at line 1228:
<jwendell> fakeroot debian/rules clean failed
<jwendell> pitti, any idea?
<pitti> jwendell: welcome to the horrible world of autoconf
<pitti> jwendell: patching generated files and calling autoconf/updating config.{guess,sub} don't mix well
<pitti> jwendell: you either want to debuild with -nc, or remove/unpack the source again
<jwendell> pitti, i'm using later option, but i have to backup the patches i've already done...
<seb128> pitti: what email should be used for "Maintainer:" for an universe package?
<jwendell> pitti, thanks 
<pitti> seb128: see spec, ubuntu-motu@l.u.c. by default
<seb128> pitti: ok, thank you
<seb128> pitti: could be a good idea to send an announce mail about that maybe no?
<pitti> seb128: xcb-proto has an invalid copyright file
<seb128> I'm not sure MOTU will read the spec or understand what they are supposed to do
<pitti> seb128: right
<BenC> How does one add an event to the fridge?
<seb128> pitti: it's built from debian/rules
<pitti> seb128: ugh
<pitti> +debian/copyright: debian/copyright.debian COPYING
<pitti> +       cat $+ > $@
<pitti> 
<seb128> yeah, it's sort of ugly
<pitti> *tsk*
<seb128> it has been accepted to Debian though so I was not sure
<pitti> seb128: otherwise it looks okay
<pitti> seb128: in the source you have COPYING, and in the .debs you have a reduntant GPL copy, but *shrug*
<pitti> seb128: the reduntant GPL copy isn't a strong enough reason for me to deviate
<seb128> pitti: well, it has been accepted to Debian and we need it for xorg 7.2
<seb128> let's accept it and fix later if that need to be cleaned
<pitti> seb128: as I said, WFM
<seb128> thank you for the review
<pitti> seb128: oh, btw, package looks fine for main
<seb128> pitti: can I accept it to main directly or do we need a MIR?
<Riddell> Mithrandir: you released powerpc images as well?  I thought they were broken
<pitti> Riddell: worked for me, segfaulted for ogra, so they are 50% broken...
<Riddell> oh, I thought it broke for others too
<pitti> entirely possible, I didn't follow the progress
<ogra> Riddell, it was fine for me with video=ofonly
<Riddell> ok, groovy
<ogra> (which i never needed before, so i didnbt check)
<Kano> hi, could someone test this with mc: 
<Kano> mkdir this-is_a_test-dir-which-has-1_or-0_errors_with-mc
<Kano> then try to change to that dir with it
<Kano> this does not work with ubuntu, with debian no problem
<Kano> Warning: Cannot change to /home/kano/this-is_a_test-dir-which-has-1_or-0_errors_with-mc.4Edit   5Copy   6RenMov 7Mkdir  8Delete 9PullDn 10Quit
<Kano> because of that error i really dislike ubuntu...
<Hobbsee> Kano: i cant reproduce that.
<Hobbsee> oh, with mc...
<Kano> mc is my favorite toy, i use it since i use linux
<Kano> and it always worked nice
<pochu> Keybuk: if you have coffee and food there, I'm interested :)
<thom> Kano: this is abjectly off topic for this channel. i recommend #ubuntu-motu or #ubuntu
<Hobbsee> heya thom 
<thom> hey :-)
<Kano> thom: as the mc code is the same, it must be ubuntu specifc
<Kano> a system issue
<thom> Kano: so report a bug. it's not on-topic here
* lamont can't reproduce it even with mc
<zul> maybe its something with his fs
<pochu> good bye guys!
<seb128> libice needs a fake sync with Debian because we have an higher epoch number
<seb128> and I change the Maintainer field with it
<seb128> what revision should be used? ubuntu1 or build1?
<pitti> seb128: ah, tepsipakki already did a similar change for another package
<pitti> seb128: I'd use build1
<pitti> seb128: since we can autosync it if Debian bumped the epoch
<seb128> tepsipakki managed to not change the Maintainer apparently
<pitti> just to indicate that there are no changes that we want
<seb128> right, makes sense to me
<pitti> seb128: right, but adding an epoch is on the edge of what can be considered modification...
* pitti wonders whether we could convince Debian to bump epoch for these packages
<seb128> tepsipakki is speaking to the debian x team about it
<iwj> I think avahi and upstart have conspired to break my xen guest.
<iwj> The script that sets the firewall properly runs before the one that sets it wrong, now.
<doko> pitti: Are the maintainer addresses somewhere recorded, so that it's easier to get the maintainer again (-0 -> 0ubuntu1 -> -1 -> want to have the old original address)
<pitti> doko: sure, XSBC-Original-Maintainer:
<doko> pitti: so how does -1ubuntu1 gets the "Maintainer" fields from -0ubuntu1 ?
<pitti> doko: I don't understand, shouldn't MoM automatically apply this change?
<Keybuk> iwj: nothing to do with upstart
<doko> pitti: MoM may detect that, but then you have to use MoM ...
<pitti> doko: if you don't use MoM's patch, why not simply copy the old M/X-O-M: fields from the 0ubuntu1 package?
<ogra_> seb128, hey, we have a cd that ships ephy now :)
* pitti might be too stupid on a Friday afternoon to see the problem, sorry
<seb128> ogra_: rock on ;)
<iwj> Keybuk: Don't upstart and the new init scripts make it possible for the scripts to run in a different order ?
<ogra_> only add-on, but hey :)
<iwj> mvo: Do you have a copy of that fix to gdebi somewhere ?  Have you uploaded it to feisty ?  I suppose it was probably held by the freeze.
<Keybuk> iwj: what new init scripts?
<pitti> ogra_: FYI,rasmol/pulse/alsa-plugins approved for main
<ogra_> YAY !!!!!!
<ogra_> gst pulse and alsa was what i was waiting for :)
<pitti> ogra_: sorry for the delay; please feel free to urge me next time if stuff is needed for herds
<pitti> I don't process the queue that often, there's a lot of noise
<ogra_> well, i'm fine with telling people to install it manually :)
<seb128> pitti: should we modify Maintainers when we only change the version number or that's only when we do packaging changes?
<seb128> like the epoch change for xorg packages
<pitti> seb128: that's a pathetic case; my gut feeling is 'no'
<ogra_> its not that ltsp wouldnt work at all or something ... :)
<seb128> pitti: ok, I didn't for that libice upload ;)
<pitti> ogra_: python-ltsp is an in-house development?
<doko> hmm, tollef not online?
<pitti> seb128: if someone complains, we can still change that, but it would be quite ridiculous
<seb128> doko: Mithrandir
<seb128> right
<ogra_> pitti, yep
<doko> Mithrandir: please requeue gcj-4.1 on sparc (after gcc-4.1 is in the archive)
<ogra_> pitti, it's the backend of ltsp-manager ... and will eventually merge with python-tcm
<ogra_> so we have *all* ltsp related functions in one module
<ogra_> keeps dokos python lists small :)
<pitti> ogra_: package looks good, do you still want to have that one in main?
<pitti> anyway, approved
<ogra_> yay
<pitti> ogra_: do you need anything else from the current queue?
<ogra_> pitti, indeed i want it in main :)
<ogra_> nope, i'm happy
<ogra_> ltsp-manager might or might not be ready for main, i'll decide that if i'm ready with the code 
<ogra_> python-ltsp was the important part :)
<pitti> cjwatson: I just reviewed mouseemu and gave it a quick audit; souce looks good, just the init script needs LSBification
<ogra> pitti, the ldap/pam stuff would be nice to get to main during feisty to have it in the ship seed, but i will redo the MIRs first and you can leave it to iwj it's not majorly important ...
<pitti> cjwatson: I'll file a milestone bug for the init script and approve it, if that's ok with you?
<pitti> ogra: I don't feel competent about pam/ldap TBH, I never used it 
<ogra> pitti, well, its the missing bit users need to make use of ldap auth at all ...
<ogra> it's silly that we support slapd but nothing of the rest thats needed
<seb128> cjwatson, Mithrandir, pitti: do we have some rune to sync from Debian incoming?
<elmo> ogra: err that's not actually true
<ogra> elmo, ?
<pitti> seb128, cjwatson, Mithrandir: I'll show Sebastien
<elmo> ogra: in fact it's demonstrably untrue, witness how you're authenticated to chinstrap
<thom> no-one expects userdir-ldap
<thom> :-)
<cjwatson> pitti: sure, sounds good, thanks
<elmo> ogra: now, arguably, that's not the majority or even common use case, but claiming we're missing "the bit users needs to make use of ldap auth at all" is just crazy exageration
<doko> Mithrandir: gcc-4.1 is now in the archive for sparc, please requeue gcj-4.1 on sparc
<ogra> elmo, we support slapd ... but i dont know any network auth for desktop that doesnt use libpam-ldap for example
<kwwii> ogra: I've been tweaking GDM so it uses svgs for the boxes...
<ogra> elmo, well, it would make sense to support pam-mount and libnss-pam as well 
<kwwii> ogra: http://sinecera.de/ubuntuscreen.png
<kwwii> ignore the logo, of course :-)
<doko> Mithrandir: please requeue gnat-4.1 for sparc as well
<ogra> kwwii, but the entry widget is still a gtk.Entry box yes ? *g*
<elmo> ogra: I'm not disputing that, I just hate that kind of unnecessary drama
<kwwii> ogra: sure, but that is your job to change it ;-)
<ogra> elmo, well, i's no drama ... id just like to see these three packages in main to help our users :)
<ogra> kwwii, indeed :)
<elmo> ogra: sigh, never mind
<seb128> pitti: if I maintain a package for Debian and Ubuntu, is there a way to tell to dpkg to  not complain about the Maintainer not being changed?
<pitti> seb128: maintaining this list in dpkg would be quite cumbersome :(
<seb128> pitti: ok, I'll change it then, no problem
<pitti> seb128: you could just put your @ubuntu address in Maintainer and skip O-M
<seb128> I'll put desktop team as maintainer that's fine
<seb128> hum, using my Ubuntu email looks fine as well ;)
<bddebian> Heya
<cjwatson> pitti: perhaps there could be an override switch in dpkg-buildpackage/dpkg-source to suppress that error, for seb128's case
<pitti> cjwatson: we already have such an override system in pkgbinarymangler
<pitti> since the debs are much more prominent, we shuold just add seb128 there IMHO
<pitti> mvo_: is bug 85207 fixed in Feisty? Please update the feisty status task
<Ubugtu> Malone bug 85207 in apt "SRU request for new DPKG::StopOnError config " [Undecided,Unconfirmed]  https://launchpad.net/bugs/85207
<cjwatson> right, but given the dpkg-source change it's not possible to build a package like that any more
<doko> pitti: is there a fixed value for the clear name of the maintainer address?
<cjwatson> regardless of what pkgbinarymangler does
<pitti> doko: I just updated the spec an hour ago to add some default names for consistency
<pitti> doko: I took the pkgbinarymangler values: Ubuntu {Core,Motu} Developers
<pitti> erm, MOTU
<doko> so Core and MOTU.
<pitti> cjwatson: true; I don't see a good heuristic, it'd really require a list in dpkg-dev itself
* seb128 is away for ~1h, bbl
<mvo_> pitti: it is
<mvo_> pitti: I update the status now
<pitti> mvo_: this gives me the creeps - 'do we want to break edgy this or that way?' :/
<mvo_> pitti: the stoponerror? yeah, its a matter of picking the poison it seems. best is if we do not have errors during the upgrade
<cjwatson> pitti: like I say, an override option would do, perhaps?
<geser> doko: should gcc-4.0 be given-back to the buildds?  it looks like it never reached them
<doko> geser: no, look at the control file
<geser> doko: thanks for the pointer
<jdong> Keybuk: I've lost all my vt's since upstart 0.3.5......
<jdong> like all the consoles are just simply blank, or show the last bootup script executed
<geser> I looked at gcc-4.0 because there are still some old debs on the archive creating some unmet deps
<torkel> jdong: have you tried to hit enter?
<jdong> torkel: consoles do not accept any input
<_ion> jdong: Does /etc/event.d/tty1 contain the line "start on runlevel 2"?
<_ion> jdong: Note the space between "runlevel" and "2".
<jdong> _ion: nope
<jdong> start on rcS
<jdong> all of them are that way
<jdong> but rcS should carry over to rc2... right?
<iwj> Is there an easier way to say something like
<iwj>   if [d if d not in deps_new for d in tb.deps_processed] :
<_ion> jdong: Uh. Strange. I don't think those are the default tty* jobs from the system-services package.
<Keybuk> jdong: you changed them yourself?
<jdong> _ion: any way to reset that
<jdong> Keybuk: I haven't touched a thing! :)
<Keybuk> jdong: you must have
<jdong> well, I will adamantly deny that :)
<Keybuk> jdong: the ones shipped with upstart said "runlevel" not "rcS"
<jdong> but how would I restore the defaults?
<jdong> I have not touched upstart configs... I swear :)
<Keybuk> jdong: is there a .dpkg-new file alongside each tty file?
<jdong> Keybuk: no....
<Keybuk> jdong: do you have the system-services package installed?
<jdong> Keybuk: hehe apparently not
<jdong> sorry about that :D
<_ion> Where did those tty* files come from then? :-)
<jdong> _ion: previous upstart? :)
<keescook> Mez: pong
<_ion> Has upstart ever shipped tty* jobs with "start on rcS"?
<jdong> okie dokie, attempt reboot.....
<jdong> _ion: isn't that the way it worked last release?
<Mez> keescook, i have a poc rar but the dev wants it kept private for obv reasons
<Keybuk> jdong: no
<jdong> heh well anyway
<Keybuk> make sure you have startup-tasks and upstart-compat-sysv as well
<_ion> Better have the ubuntu-minimal metapackage installed.
<freshmouse> Hello. I downloaded Herd 4, but I have a problem with boot. I can't boot it, it gives me a "loading error" (in text mode it's called error 10)...
<jdong> ok all is happy
<_ion> jdong: Better have the ubuntu-minimal metapackage installed.
<jdong> _ion: yeah good idea; dunno how that became uninstalled
<jdong> heh
<_ion> Would it be evil to make ubuntu-minimal Essential: yes? :-)
<jdong> shoudl I be using this terminus thingie?
<freshmouse> No ideas?
<freshmouse> I think, it needs edit the booting parametres, but I can't rememeber (and find) how.
<pitti> BenC: is there still something to be done for bug 74004? dapper task is still open
<Ubugtu> Malone bug 74004 in udev "Doesn't include qla2xxx firmware" [High,Confirmed]  https://launchpad.net/bugs/74004
<BenC> pitti: I can't remember if mdz's work was on dapper or edgy
<pitti> BenC: (both udev and initramfs-tools task); but there are no debdiffs
<pitti> BenC: mdz worked on edgy, I finished the edgy SRU and uploaded stuff
<BenC> pitti: Then we probably need firmware in kernel, and both udev/initramfs fixups in dapper
<BenC> pitti: I don't even know if we have the driver in dapper's kernel
<pitti> BenC: it's still assigned to you, is that fine?
<BenC> kylem: ping ^^
<BenC> Re-assign to kyle
<BenC> If you could, please
<pitti> sure
<kylem> moo?
<keescook> pitti, seb128: are you doing "NEW"s?  I think libfilter-template-perl is in this state (#85012)
<kylem> i don't think we have that driver.
<pitti> keescook: will do in a bit
<pitti> keescook: still doing SRUs
<keescook> pitti: okay, thanks!  no rush; I just wanted to make sure I understand where it was.  :)
<pitti> kylem: if it's invalid for dapper, can you please reject the dapper tasks?
<kylem> i'll look into it first.
<kylem> iirc dapper already includes the firmware in the .ko.
<pitti> cjwatson: do you have some minutes to look over bug 85934? I don't like to approve my own SRUs
<pitti> yes Ubugtu, I suck; I mean bug 85394
<Ubugtu> Malone bug 85394 in tzdata "New timezone data 2007b" [High,In progress]  https://launchpad.net/bugs/85394
<kylem> pitti, the firmware is definitely built-in for dapper...
<cjwatson> pitti: oh, yeah, I promised to, ok
<pitti> cjwatson: thanks; we should bring it into edgy before March, so that the new rules arrive in time (that's why I'm urging)
<kylem> pitti/mdz/BenC, this needs kernel changes since dapper doesn't include qla24xx.fw.bin
<kylem> we can't SRU a kernel...
<kylem> should i just add it to -security?
<pitti> kylem: ok, that's fine; let's just reject the task then
<pitti> kylem: IMHO not; it's not a regression from breezy, just a missing feature
<mdz> kylem: I thought it was already in -proposed
<mdz> oh, you're talking about dapper
<mdz> this driver worked in dapper
<mdz> works, even
<kylem> no.
<kylem> /most/ of the driver worked.
<pitti> mdz: there's not even a debdiff for dapper
<kylem> qla24xx is still missing firmware.
<cjwatson> pitti: yes, those are ok, same criteria as previous tzdata updates
<kylem> (22xx/23xx have it built in.)
<mdz> it works well enough for the customer
<jdong> grr how can you get a GNOME app to print to a custom command?
<jdong> not veryone uses cups.....
<mdz> oh, I see
<pitti> cjwatson: thanks
* poningru wonders who to bug re: the firefox bug
<BenC> Oh right, the driver in dapper had the firmware built-in
<poningru> the firefox vuln in 2.0.0.1
<mdz> kylem: I don't think we should backport the initramfs/firmware changes to dapper
* pitti points poningru to asac, our new Mozilla bitc^Wguru
<poningru> asac: ping
<pitti> poningru: ah, that's on our radar
<poningru> pitti: the patch is approved upstream
<pitti> poningru: we'll update to 2.0.0.2 as soon as upstream releases them
<BenC> mdz, kylem, pitti: I don't think any of this is needed for dapper, unless there's something horrible with the driver already there
<poningru> pitti: why not just patch it ourselves and do it?
<kylem> BenC, if you have an ISP24xx card (which is supported by the driver) it is missing firmware.
<pitti> poningru: there are more changes in 2.0.0.2, I assume; we can add the patch on top of the 2.0.0.2 security update, of course
<poningru> right 
<kylem> i'm happy enough fixing that, but only if it's worth the effort...
<poningru> pitti: they are respinning 2.0.0.2 for this
<pitti> lol, ok :)
<mdz> kylem: only if it can be built in like the other firmware
<BenC> mdz: It shouldn't hurt to include the firmware in an update, since it wont affect any existing installs, and the lack of firmware on the CD means we wont get any new installs that need the udev/initramfs fix
<kylem> mdz, it wouldn't be, the 24xx seems to be a special case throughout the driver. can we flag this one as a "maybe if we do a point release"?
<mdz> BenC: sure, I'm just saying we ought not mess around with initramfs and udev in dapper
<cjwatson> asac isn't generally around here on Fridays
<cjwatson> pitti,poningru: ^--
<pitti> kylem, mdz: ok, sounds like rejections of the dapper/edgy tasks are in order?
<pitti> kylem, mdz: sorry, s_/edgy//
<BenC> mdz: Agreed. I do think it would be safe to include the firmware though, even if it isn't in the driver
<poningru> cjwatson: ah ok thanks
<BenC> actually, I think it's safe if it doesn't need to be compiled in...less code changes
<BenC> *safer
<kylem> i'm happy with whatever we choose, one way or another.
<geser> is it possible to have Depends: wine [i386]  in an arch all meta-package?
<BenC> kylem: Do you know if the firmware for that device is external, and the driver already has code to load?
<elmo> geser: no
<kylem> BenC, for almost all of the card types supported, it's internal in 2.6.15, except the two models of qla24xx, which require the external firmware.
<BenC> kylem: But does the driver already have code to demand load that firmware?
<kylem> yeah.
<BenC> kylem: I'd say drop the new firmware in the kernel for proposed, see if you can find someone with that device willing to test it, and work to move it into -stable
<kylem> fabio may have one.
<BenC> is that a dell type device?
<iwj> mvo: AYT?
<iwj> mvo: I'm having some difficulty with this local apt-ftparchive.
<mvo> iwj: I'm here, what is the issue?
<iwj> apt-get update says just   Ign file: . Release.gpg
<iwj> (and similar messages)
<iwj> I have    deb file:///root/adt-downtmp/binaries . main
<iwj> /root/adt-downtmp/binaries contains Release{,gpg}, Packages.gz and a few other files.
<iwj> (I knew it passing the test yesterday was too good to be true.  It turns out it wasn't installing the package I intended at all ...)
<mvo> iwj: is there a reason not to use a flat structure? like "deb file:///root/apt-downtmp/binaries /" and lump it all into a single dir? or is that dir becoming big?
<iwj> Err, I'm allowed `/' ?
<mvo> think of the / as "./"
<iwj> deb file:///root/adt-downtmp/binaries /   is an improvement.  Now it says    Failed to fetch file:///root/adt-downtmp/binaries/Release  Unable to find expected entry  Packages in Meta-index file (malformed Release file?)
<mvo> iwj: what is in Release? can you put it into a pastebin? how was it generated (with "apt-ftparchive release ." ? after the Packages files were created?
<iwj> http://paste.ubuntu-nl.org/6113/ is the fragment that generated it.
<iwj> Just a mo and I'll upload the whole directory `binaries'.
<mvo> iwj: keep a copy of the uncompressed Package file around , that should fix it
<iwj> http://www.chiark.greenend.org.uk/~ian/d/x.tar
<iwj> Err, that's not idea really.
<iwj> s/idea/&l
<iwj> Err, actually what am I talking about.
<iwj> These Packages files are very small.
<kuser> update-grub has changed location to /usr/sbin/. Why did ubuntu not follow yet?
<mvo> iwj: if you haveboth Packages and Pacakges.gz in the  dir all should be good
<iwj> mvo: How does apt decide whether the package it has installed is the right one ?  Does it record the original installation source ?
<iwj> Do I need to worry about   Ign file:  Packages   ?
<mvo> iwj: no, it will figure it from the available sources and usually pick the one with the biggest version number (but I'm not 100% sure if I understand the question)
<mvo> iwj: Packages should be ok as long as it finds Packages.gz
<iwj> OK.
<iwj> My trickery with apt-key seems to have worked, at least.
<iwj> That seems to work.
<iwj> I have this new source which contains a mawk.deb with the same version number as that in the archive.
<iwj> When I say `apt-get install mawk' I want it to install the one from my private archive.
<iwj> It seems to do this already but I worry about how it knows.
<mvo> iwj: and different md5sums? that is likely to confuse the system
<iwj> Yes, different md5sums.
<pitti> geser: gtk2hs still build-deps on mozilla-dev without alternatives
<mvo> iwj: usually it will pick the package from the first source in sources.list, so if file:// is listed first, it will pick that
<iwj> But how does it know that the package already installed isn't the one that it's seeing there ?
<pitti> geser: anyway, I did a first round of removals, will check rdepends again on Monday
<geser> pitti: I know, I'm working on it. see bug #85135
<Ubugtu> Malone bug 85135 in gtk2hs "[UVF exception]  Sync gtk2hs (0.9.10.5-1) from Debian unstable (main)" [Undecided,Needs info]  https://launchpad.net/bugs/85135
<pitti> geser: ah, fine; thanks
<mvo> iwj: you mean you have 1.0-1 installed and 1.0-1 available. and it will (e.g. on upgrade) install the one from the server and think its a update?
<mvo> iwj: IIRC it does so because the local version is different than the remote one and that makes it think its a good idea to reinstall it
<iwj> How can it tell it's different ?
<iwj> I have 1.3.3-11ubuntu2 from the archive installed.  My script creates this new archive (pulling a mawk 1.3.3-11ubuntu2 out of its back pocket that it built earlier), edits sources.list, runs update, and says apt-get install mawk.
<mvo> iwj: it reads /var/lib/dpkg/status and sees e.g. a different install size than the one it has in the repository
<iwj> Now apt somehow knows to install my mawk.
<iwj> Urg.
<iwj> How can I force this to happen ?
<geser> pitti: gtk2hs is already broken (FTBFS with ghc 6.6)
<pitti> geser: ah, I see
<doko> Mithrandir: please requeue openoffice.org on amd64 (trying with new compiler)
<mvo> iwj: with --reinstall. or use a new version number
<iwj> New version number is slightly tricky because that might well break dependencies etc.
<iwj> Eg, people write   Depends: thing (= myself)
<iwj> And --reinstall is wrong because I only want some of the packages reinstalled.
<mvo> iwj: heh, right. well, if it works with apt-get install --reinstall $pkg, then all should be good?
<mvo> iwj: or is it a problem to figure in advance what package need a reinstall?
<iwj> mvo: I know which packages I want to make sure get reinstalled _if they need to be installed at all_
<iwj> But I don't know the latter question because only the dependency resolver knows that.
<iwj> I suppose I could edit /var/lib/dpkg/status and set the Installed-Size of every package that I put in my local archive to some crazy value.
<mvo> iwj: let me then re-check my memory just to be sure that you are hacking around the right assumptions :) 
<iwj> Oh!  I know!  What about if I edit Maintainer ?
<iwj> I could write   Maintainer: Ian's crazy build thingum
<kylem> argh. network manager. die.
<mvo> iwj: I'm not sure if that is enough
<iwj> Maintainer isn't enough apparently.
<iwj> But editing Installed-Size in the dpkg status db works.
<iwj> Yuk.
<mvo> iwj: hrm, its evil enough to consider something custom with python-apt, no? there you have very precise control what to reinstall and what not
<iwj> Is there a way to say `this package named X, if you want to install it, use this version, but do not install it just on my account' ?
<cjwatson> kuser: we have
<cjwatson> $ dpkg -c /mirror/ubuntu/pool/main/g/grub/grub_0.97-20ubuntu3_i386.deb | grep usr/sbin/update-grub
<cjwatson> -rwxr-xr-x root/root     35831 2007-01-19 11:37:42 ./usr/sbin/update-grub
<iwj> What fields does it compare ?  If there's one that I don't mind munging then that completely solves the problem.
<kuser> cjwatson: Hm yes, but the lines in /etc/kernel-img.conf aren't adjusted
<cjwatson> kuser: https://launchpad.net/ubuntu/+source/grub/+bugs and file it if it's not there already
<Mithrandir> Riddell: ppc images worked for some people at least, so yes, I released them.
<Mithrandir> doko: gnat-4.1, gcj-4.1 and openoffice.org all given-back.
<iwj> mvo: Oh, no, actually that doesn't work because if I ask to satisfy dependencies it doesn't think I want to upgrade.
<iwj> Can I upgrade only from one source ?
<asac> poningru: any question?
<kuser> cjwatson: Thanks, haven't found it there but will search until I'm sure I don't dupe.
<mvo> iwj: you can use apt-get install foo=$version . for upgrade-ony-from-one source, why not comment out the others? or use a custrom sources.list?
<mvo> iwj: apt-get upgrade -o Dir::Etc::sourcelist=/foo/bar lets you do this
<poningru> asac: yeah was wondering if 2.0.0.2 with the new patch would be available for testing?
<iwj> apt-get upgrade --reinstall doesn't seem to work.
<iwj> I suppose I could look at the list of installed packages and explicitly apt-get upgrade <name-of-package>
<iwj> Err,  apt-get -y --reinstall install mawk
<asac> poningru: i have not planned to release preview packages build from rc release.
<mvo> iwj: could you please point me to the spec or some more information? I think I miss some information what is needed :)
<iwj> Would you mind if I phoned you ?
<asac> but if you join #ubuntu-mozillateam channel, I will change topic if there are preview builds available
<iwj> I think that'd be quicker.
<geser> kuser: the change is documented in /usr/share/doc/grub/NEWS.Debian.gz
<mvo> iwj: fine with me too
<kuser> geser: That's how I found it. But the changes aren't performed in the ubuntu system.
<geser> kuser: the file says you should edit it. I understand it that this doesn't happen automagically.
<kuser> geser: Question is, who is "you". I, the user or you the developer. To me the former doesn't make sense.
<geser> kuser: as this file it written by the Debian maintainer "you" is the user/admin
<geser> kuser: if you have apt-listchanges installed you get this NEWS shown and/or mailed.
<kuser> geser: And if /sbin/update-grub eventually vanishes, /etc/kernel-img.conf in the new packages get adjusted by the maintainer whereever that file comes from?
<geser> kuser: /etc/kernel-img.conf is created by linux-image if it doesn't exist. it looks like the call to update-grub isn't created by default.
<iwj> mvo: Thanks for that.  I'll get on and try it ...
<mvo> iwj: :) keep me updated! 
<Adri2000> seb128, doko: why this one https://launchpad.net/ubuntu/+source/griffith/+bug/85441 doesn't need the ack from motu-sru?
<Ubugtu> Malone bug 85441 in griffith "Please sync griffith 0.9.1-1 (universe) from unstable (main)" [Undecided,Fix released]  
<kuser> geser: Ok, so I now know which packet creates that file. But still don't know who's responsible to adjust the pathes in that package. Debian maintainers or Ubuntus.
<lionel> Adri2000: motu-uvf you mean ?
<geser> kuser: have you added the calls of update-grub there or were they already present?
<kuser> geser: No, I didn't add anything.
<Adri2000> lionel: err yes, seb128, doko: s/motu-sru/motu-uvf/
<geser> kuser: find out who did it and you know has to updated them
<seb128> Adri2000: pong
<seb128> Adri2000: I thought it had been approved since it had an "ok" from doko, sorry if that was not correct
<seb128> Adri2000: don't subscribe ubuntu-archive if that's something to decide by motu-uvf
<Adri2000> seb128: I didn't subscribe anyone
<doko> seb128: the subscription was done by the original submitter
<seb128> Adri2000: the "you" was not for you especially but for whoever did that ;)
<seb128> doko: no, you did it
<Adri2000> according to https://launchpad.net/ubuntu/+source/griffith/+bug/85441/+activity
<Ubugtu> Malone bug 85441 in griffith "Please sync griffith 0.9.1-1 (universe) from unstable (main)" [Undecided,Fix released]  
<doko> hmm, ok
<seb128> Adri2000: no big deal anyway, that only a .1 new version
<seb128> Adri2000: mistakes happen ;)
<Adri2000> ok
<shawarma> Is root on lvm still supported? (in Feisty)
<doko> pitti: please approve the mysql-dfsg-5.0 upload
<doko> pitti_: please approve the mysql-dfsg-5.0 upload
<pitti_> ugh, yay network breakage
<pitti_> doko: yup, got that; in feisty?
<doko> pitti: edgy-proposed
<pitti> doko: ah, that bug, right
<BenC> what program detects and creates the initial xorg.conf?
<pitti> doko: done, bug updated
<iwj> mvo: How do I pass an apt-get -o option into gdebi, or don't I ?
<doko> Mithrandir: please requeue libgnucrypto-java (i386/all)
<rtg> mjg59: Hi - BenC tells me you are an ACPI/suspend expert. We are getting a bunch of complaits about suspend on Feisty and I'm attempting to determine when it stopped working. Any ideas?
<pitti> yay, a C# reimplementation of dbus, exactly what we need *grumpf*
<mjg59> rtg: There's a couple of patches that ought to go in
<mjg59> rtg: There's a patch somewhere on acpi-devel about GPE configuration on wakeup
<mjg59> I think the thread was about a T43
<mjg59> rtg: About to head out - if you can't find it, I'll take a look later
<rtg> mjg59: Thanks. I'll see if I can track it down.
<shawarma> rtg: I've got a good guess..
<shawarma> rtg: I don't remember if we ever got round to disabling vbetool for Thinkpads.
<shawarma> rtg: If we didn't, that's a likely cause for broken resuming.
<mjg59> (Nngh grah no it isn't)
<shawarma> mjg59: Well, that's what the i810 driver developer guy said and removing vbetool from the resume chain fixed a *lot* of issues a while back.
<rtg> shawarma: Suspend appears to be failing across a variety of machines. For example, I have a Dell XPS that won't return from suspend.
<doko_> seb128: any unknown incompatibilities in libgail? (see #85609)
<seb128> bug #85609
<Ubugtu> Malone bug 85609 in openoffice.org "[apport]  soffice.bin crashed with SIGSEGV"" [Undecided,Unconfirmed]  https://launchpad.net/bugs/85609
<doko_> s/unknown/known/
<seb128> doko_: looking, that's a11y stack though, heno or dholbach would know better
<seb128> doko_: reassign to gail
<shawarma> rtg: Does it do anything at all or does the screen just never come back up properly?
<rtg> shawarma: It just sits there blank after an initial flash of the disk light. Eventually the fan kicks on.
<shawarma> rtg: Ok, that's not it then. I just seem to remember seeing the vbetool issue again recently.
<shawarma> rtg: ...but if mjg59 says that's not it, then that's not it. :-)
<pitti> Mithrandir: just to confirm, orig.tar.gz's need to have a COPYING file? having gpl stanzas in the source files is not enough?
<pitti> or elmo ^
<Burgwork> pitti: I hate to tell you this, but it appears liek that cupsys dapper update completely broke printing
<pitti> Burgwork: hm, it seemed to have fixed stuff for other people, weird
<pitti> Burgwork: but if it regresses for you, then let's skip it
<pitti> Burgwork: can you please say so in the bug, so that we have a recording?
<seb128> hum
<seb128> binary splited to binary and binary-extra
<seb128> -extra needs to Replaces binary, right?
<seb128> dholbach used a Conflicts
<pitti> seb128: and probably Conflicts: << too
<seb128> Conflicts alone is not enough though, right?
<pitti> seb128: that would break apt-get dist-upgrade IIRC
<seb128> right
<pitti> seb128: replaces/conflicts with << (changed version) are the right thing
<seb128> I'll accept the upload and do an another one to fix it
<seb128> pitti: well, I think some people told me that Conflicts is not required
<seb128> that Replaces is enough
<pitti> seb128: right, in theory Replaces: is enough
<pitti> seb128: but that won't force the upgrade of the other package
<NokiaA> ok so i brought vista and installed it. Whats the big deal? it's just like XP...it's not wiping my bum yet.
<Burgwork> pitti: https://launchpad.net/bugs/55828
<pitti> seb128: just Replaces: will just overwrite the files
<Ubugtu> Malone bug 55828 in cupsys "PJL output from 1.2.2 client over IPP" [Medium,Fix committed]  
<pitti> Burgwork: thanks
<seb128> pitti: right
<seb128> Conflicts is not right to force upgrade though ;)
<NokiaA> wrong channel opps.
<NokiaA> omg I just said 'i brought windows' in a ubuntu channel... I should be shot lol
<NokiaA> my bad
<Burgwork> pitti: I just added a comment showing what is happening
<pitti> NokiaA: no, you should return it and reinstall :)
<jordi> mm, no mithrandir
<doko_> pitti: maybe we need an XS-Original-Uploaders as well ?
<pitti> doko_: why that?
<doko_> pitti: well, because that's invalid for ubuntu packages?
<pitti> doko_: noone complained about that, and we don't use it anyway
<doko_> ok, fine with me
<keescook> anyone know why ubuntu continues to have a separate wine package from Debian?
<seb128> keescook: no idea, ask \sh_away he's maintaining it
<seb128> hi keescook BTW ;)
<keescook> hiya!  :)
<keescook> yeah, looks like the ubuntu wine doesn't have binfmt-support, but Debian's does.
<keescook> (both have the bad desktop file, though)
<seb128> good reason to merge with Debian then
<keescook> agreed!  :)
<keescook> there are some big differences between the two packages, though.
<keescook> \sh_away: when you're back, I'd like to ask you about wine packaging; it seems Debian's package has binfmt-support and amd64 builds.  what would be needed from the Ubuntu packages to merge with Debian's package?
<Burgwork> keescook: scott ritchie does Debian as well as teh official wine debs
<keescook> Burgwork: yeah, the package looks good.  I'm just curious what the ubuntu-only changes are (the diff is giant...)
<keescook> where is the log of "removed" packages?  i.e. libjpeg-mmx is not in feisty, and I want to figure out what replaced it, etc
<keescook> (though this looks more like a failure on sbuild's part...)
<geser> keescook: perhaps http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=158474 helps you
<Ubugtu> Debian bug 158474 in wnpp "RFA: libjpeg-mmx" [Normal,Closed]  
<geser> it's the removal bug for libjpeg-mmx in Debian
<keescook> geser: yeah, I tracked that down just now.  :)  So now I'm curious about gcc-4.0, which is still in debian.  :)
<keescook> (weird, it hasn't built)
<geser> gcc-4.0 is only architecture hppa and hurd-i386 in feisty
<geser> it tricked me also
<keescook> geser: what're you using to see the archs for that?  I tend to use apt-cache madison, but that doesn't give me other archs, and LP navigation takes me forever.  :)
<geser> keescook: doko gave me the hint to look into debian/control
<geser> I had to fetch the diff.gz
<keescook> ah-ha! cheater.  :)
<pochu> greetings from london :)
<jdong> anyone else getting blurry fonts with firefox and gnome-terminal today?
<jdong> all other apps seem fine... :-/
<jdong> never find I magically fixed it
<Riddell> cjwatson: in new partitioner partman_column_format_toggled() what actually tells partman the value of the format boolean?
<Riddell> cjwatson: I can see "format='dummy'" but that's the same if the tickbox is true or false
<Riddell> cjwatson: ooh, I got it to work
<Riddell> although I'm not entirely sure how :)
#ubuntu-devel 2007-02-17
<jdong> ok, obviously kinit is not the command for _renewing_ kerberos tickets
<jdong> OH, -R
* jdong hangs head in shame
<jdong> grr Active Directory was a lot easier to use </joke>
<zul> man pages usually help
<jdong> zul: yeah yeah yeah
<wasabi_> <--- kerberos wizard
<Hobbsee> keescook: oops, thanks for the info!
<kwwii> re
<Mithrandir> doko: given-back
<Fujitsu> Mithrandir, is the publisher not running at the moment?
<Mithrandir> Fujitsu: it should be running, I'll take a look if something's wedged.
<Mithrandir> Fujitsu: what's the problem you're seeing?
<Fujitsu> Nothing seems to have been processed since about 13.5 hours ago.
<Fujitsu> (it's all sitting in Accepted)
<Mithrandir> something's blowing up in the publisher.
<Fujitsu> I thought as much.
<Fujitsu> (I originally thought that it might still be on manual, but then I noticed it had been going beforehand)
<Mithrandir> something in the custom upload processor for update-manager.
<Mithrandir> I'll reject those bits so the queue works.
<Fujitsu> Thanks.
<Fujitsu> Is there something in place to notify people of such failures?
<Mithrandir> it's supposed to land in a mailbox on drescher and we tend to notice when stuff hasn't published for a while, but no, not really.
<Fujitsu> OK.
<Fujitsu> That looks a little better.
<bSON> hi
<bSON> will ubuntu feisty not use x.org 7.2?
<seb128> bSON: no
<bSON> seb128, was it released too late?
<seb128> ?
<seb128> will it not use -> no
<seb128> it'll use
<Hobbsee> seb128: tepsipakki has packages for it, at the moment
<Fujitsu> seb128: That's very ambiguous in a silly language like English :P
<seb128> Fujitsu: well, the question was weird
<racarr> join #ubuntu+1
<racarr> gah
<seb128> "will feisty use xorg 7.2" is easier to understand and reply to ;)
<seb128> bSON: a bunch of xorg 7.2 packages have been uploaded yesterday
<bSON> seb128: oh excuse me
<bSON> oh, so the x updates from today were 7.2 versions
<seb128> np
<seb128> yep
<bSON> ok, thanks 
<seb128> np
* Fujitsu heads off to bed.
<alecjw> hi. sorry if this is the wrong place to ask thios, but does anyone think that ti could be a good idea to replace start.BMP on the livecd with a start.PNG?
<hunger> alecjw: I think that there is no png library available at the time start.BMP is read.... so that is not possible.
<alecjw> hunger, ok
<hunger> alecjw: I might be wrong, but that is generaly the reason for using BMPs;-)
<alecjw> hunger, so whay cant a png library be put in? is it just because it takes up mroe space than it saves or osemthing?
<hunger> alecjw: It will probably take more space than using png would save.
<hunger> alecjw: Is that BMP used in grub? That has a limitation on its executables size IIRC.
<alecjw> hunger, it's the splash screen gor the windows program installery thing. i'll put it on my website to show you if you dont know what i mean
<hunger> alecjw: Hmm... then it is probably that windows can handle BMP out of the box but not PNG.
<hunger> alecjw: Why add a new library if things work the same way without after all? The picture won't change just because you store it differently.
<alecjw> hunger, yeah, i suppose. it would praoblyo nly make about 200kb of differnce anyway....
<alecjw> *proably only
<hunger> alecjw: Yeap. And you'd drag in the png code which you need to maintain.
<alecjw> hunger, in case you're wodnering, here' the iamge (converted to jpeg): http://alecjw.no-ip.org/home/start.jpg
<hunger> alecjw: I am:-) No windows here, so I'll probably never see that thing;-)
<alecjw> lol
<hunger> alecjw: Can't connect to your server.
<alecjw> hunger, that's because my server's crap and my internet's too slow. i'll put it on iamgeshack.
<alecjw> hunger, http://img64.imageshack.us/my.php?image=startkl9.jpg
<hunger> looks nice enough.
<hunger> alecjw: Thanks:-)
* mode/#ubuntu-devel [+o Hobbsee]  by ChanServ
<Lathiat> hrm the window title on the feisty CDs still says Ubuntu 6.06
<Lathiat> when booted in windows
<wereHamster> http://www.neopsis.com/projects/yukon/browser/trunk/build.sh gives http://pastebin.ca/349486
<wereHamster> what's wrong? it works fine under bash, but fails under dash
<hunger> wereHamster: Have you tried adding a "test" between the if and the ! in line 13?
<wereHamster> no, is 'test ...' and '[ ... ] ' the same or is there a difference?
<hunger> wereHamster: thinking about it: that should not work either;-)
<hunger> wereHamster: They are the same.
<wereHamster> .. why won't test work?
<hunger> wereHamster: I'd remove the !, put in a echo "... found" and push the existing code into an else branch.
<wereHamster> the strange thing is that the first which (which echo) passes, but it fails on which rm
<hunger> wereHamster: Because test evaluates an expression and gives an return code depending on that.
<hunger> wereHamster: In line 13 you evaluate the which (which you negate with the ! which is not portable IIRC).
<wereHamster> what about [ -x "$(whioch ${tool})" ]  ?
<hunger> wereHamster: Won't work.
<hunger> wereHamster: which always returns a text:-)
<wereHamster> .. my example would evaluate to [ -x /bin/rm ] , which means '/bin/rm isexecutable, right?
<hunger> wereHamster: But it will fail on echo...
<hunger> wereHamster: Try removing the & before the >... That makes things work here.
<hunger> wereHamster: dash's man-page states that it supports ">&", so try that instead.
<hunger> wereHamster: Bash supports that as well, even though there the &> form is prefered.
<hunger> wereHamster: Using the long form which "echo" > /dev/null 2>&1 works in both bash and dash here.
<wereHamster> so &>/dev/null isn't POSIX-conform?
<hunger> wereHamster: Dunno. dash does not support it, so it is a good guess that it is not:-)
<wereHamster> I dislike the long form.. I dislike everything that is long :(
<hunger> wereHamster: You can always replace /bin/sh with /bin/bash in the first line;-)
<wereHamster> but what on systems that don't have bash?
<wereHamster> I want ot be as portable as possibkle
<jdong> wereHamster: &> is a bash extension
<wereHamster> and >& posix?
<bluefoxicy> bah this sucks.
<bluefoxicy> I have a pretty good idea of what to do to Ubuntu to magically make the install CD also support A) Installing as a Xen Dom0 controller; B) Installing as a Xen DomU guest
<bluefoxicy> As for actually implementing... no
<bluefoxicy> (it needs an extra kernel; needs to install into a disk image; needs the Xen hypervisor on the CD; and needs the installer to know that there's 2 new ways to handle installation)
<bluefoxicy> Have not figured out how to get Xen to boot from a CD image though.. I guess I could tell it it's another disk drive but I'd need a kernel and an initrd that would expect to be booted in Xen.
<bluefoxicy> It WOULD help if network didn't die every 10 minutes under Xen
<hunger> wereHamster: >& is POSIX, but it is only valid as part of something like 2>&1 from what I understand.
<wereHamster> eg. not in >&/dev/null ?
<hunger> wereHamster: Nope, that does not work. Tried it and it complains about wrong/missing fds.
<geser> wereHamster: but you can use > /dev/null 2>&1 which is according to the bash manpage the same as &> /dev/null in bash
<eXistenZ> Hello, can I change my wiki name?
<phaidros_> ??
<eXistenZ> phaidros_, I registered an account on wiki.ubuntu.com. How can I change the wikiname I was given?
<gnomefreak> eXistenZ: yes and this shouldnt be in -devel try #ubuntu-offtopic
<eXistenZ> gnomefreak, okay
<gnomefreak> eXistenZ: or read the dropdown on the wiki
<phaidros_> phew
<phaidros> well, #ubuntu is always just beginners and most popular stuff, never get answers there, always just answering .. *sigh
<phaidros> anybody here familiar with xkb stuff?
<phaidros> only thing i want, is that my right ALT works as ALT and not MOD+5 in gnome, *sigh
<phaidros> (/me feel marvinish ..)
<Kano64> hi, some reported system locks using the integrated ndiswrapper 1.30 in the kernel, could you update it to latest
<Kano64> especially with usb wlan devices
<_ion> File a bug report.
<Kano64> i prefer to patch it myself when noone else does it...
<Kano64> bye#
<zul> gah..
<phaidros> thats community ;)
#ubuntu-devel 2007-02-18
<bluefoxicy> ah that's much faster now that I've removed evms, mdadm, and lvm2
<bluefoxicy> (dm-linear was looping and eating 80% CPU in feisty)
<jdong> bluefoxicy: ouch!
<bluefoxicy> fuck.
<bluefoxicy> I got xenman working, upgraded to feisty, and same problem.
<bluefoxicy> XenMan can't find any local host.
<bluefoxicy> it doesn't know about local virtual machines
<bluefoxicy> jdong:  fix XenMan :(
<jdong> bluefoxicy: you vastly overestimate my skills :D
<jdong> bluefoxicy: fix my calc homework
<bluefoxicy> jdong:  also yes ouch, I upgraded to Feisty TWICE on my laptop and it did exactly that.
<bluefoxicy> jdong:  I am currently failing calc2
<jdong> it's somehow not done.
<kylem> heh. calculus.
<jdong> I went to sleep for 10 hours last night
<jdong> and it's still not done.
<jdong> I don't know what I'm doing wrong
<kylem> jdong, woss the problem?
<jdong> should I file a maxima bug that it isn't finishing my homework?
<jdong> kylem: ideas for using vectors to prove law of sines?
<zul> bluefoxicy: you have to enable unix-port in the xen config to get XenMan to work
<jdong> I'm guessing I should use a crossproduct of two legs to find a perpendicular vector
<jdong> and then proceed that way
<bluefoxicy> zul:  can you give me an exact line
<kylem> jdong, it's been a long time, it probably involves summing or subtracting a pair of cross products
<bluefoxicy> zul:  this worked before upgrading and I didn't change the config file
<zul> not off the top of my head
<bluefoxicy> in fact I told dpkg NOT to touch it.
<jdong> kylem: yeah looks that way.... i.e. a lot of work :D
<bluefoxicy> I have xend-unix-server yes
<kylem> jdong, i don't even remember what the sine law is though, *ducks*
<bluefoxicy> and that's it
<jdong> kylem: 5 problem psets per week... sounded so ridiculously short
<bluefoxicy> zul:  I think XenMan is just busted.
<jdong> but nope, this ain't the place for easy homework
<balarka> hi
<_dam> can i ask something?
<geser> !ask
<_dam> what happened today with the alternate(daily) versions at cdimage.ubuntu.com?
<_dam> for example, this folder is empty:    http://cdimage.ubuntu.com/daily/20070218/
<blizz> hi
<blizz> is something going to change about the bcm43xx drivers soon?
<blizz> currently the new drivers only accept 4.x firmware, which doesnt work with most broadcom based cards (all apple laptops, lots of nics)
<_dam> ?
<blizz> am i supposed to ask questions about the development in post 2.6.20-8 kernels here?
<mdke> blizz: it's not obligatory
<mdke> blizz: if you wish to do so, you can; or in #ubuntu-kernel
<blizz> ahh, thats better i think
<blizz> thanks, ill ask there :)
* Hobbsee test
<Treenaks> Hobbsee: test message received :)
<Hobbsee> Treenaks: :P
* Treenaks is poking slapd & smb configs *uurgh*
<adam0509> hi, is there any plans to get a soft painting program in ubuntu ?
<adam0509> gimp is too hard for beginners, even for me...
<adam0509> under Winsucks I use "PhotoFiltre" but's not free
<bhale> adam0509: what exactly do you want to do?
<bhale> adam0509: f-spot is a photo manager included in ubuntu-desktop that lets you do (non-destructive) basic photo editing, color adjustment, red eye removal, crop
<adam0509> I'm not talking about photo-editors, but photo-creator
<adam0509> If you wanna crop a file, add some text, resize picture, you can't do it with f-spot
<adam0509> bhale, 
<bhale> you absolutely can crop a file
<bhale> but yes, it doesnt do anything outside the scope of "touching up"
<adam0509> yes but you can't create a new file from nothing...
<bhale> ok didnt mean to offend, you mentioned something called photofiltre
<adam0509> I just love PhotoFiltre, it's the best, but it only works with wine...
<adam0509> The Author would like help to do a Linux version but don't want the sources to be released
<adam0509> or maybe a complete work could be done on "gpaint"
<adam0509> bhale, 
<angasule> I'm using Edgy and I got OpenAL to work with surround sound, it's a simple thing but I believe there is no program to do it in *buntu and no article in the wiki
<angasule> OpenAL = 3D positional sound, btw, used in games (and probably some apps)
<angasule> http://pastebin.com/883654  <-- this is what fixed OpenAL output for surround sound for me (of course, alsa must see all the speakers first)
<tsmithe> angasule, create an article in the wiki?
<Treenaks> tsmithe: no, file a bug on openal -- it should figure it out by itself :)
<Treenaks> or some gui somewhere
<Treenaks> (if the user says they have 5.1 speakers, USE THEM ;))
<angasule> Treenaks: from what I've seen about OpenAL, it's somewhat of a zombie
<angasule> Treenaks: I believe currently, the user has to configure surround in every single app
<Treenaks> angasule: still. we have a bit of GUI that configures which alsa card is primary
<angasule> Treenaks: even alsa doesn't quite work (volumes are set up wrong)
<_ion> Cool, Google knows bzr is an abbreviation of bazaar-ng.
<Treenaks> angasule: it might be nice to have it do things like this as well
* Treenaks wants to know when the next dev meeting is.. this sounsd like perfect spec material ;)
<angasule> Treenaks: you mean a settings that sets up 5.1 everywhere? that'd be nice
<angasule> btw, there are many surround settings
<angasule> OpenAL only seems to work with 4 speakers (it's extremely neglected on linux)
<Treenaks> angasule: you select 'I have 5.1 speakers' and it writes an openal config, sets the proper alsa mixer channels to sane volume levels, etc.
<angasule> 4.0, 5.1, 7.1, whatever
<angasule> Treenaks: that sounds great :)
<Treenaks> I think it's even possible to detect which options are supported by your sound card...
<angasule> Treenaks: I don't think it can be *automatically* done, though
<angasule> the problem is, one may have a 5.1 capable card, but only use headphones (2 speakers), or 4 speakers
<angasule> and I don't know if the card tells the computer which plugs are in use
<Treenaks> angasule: sure.. but if your soundcard supports 5.1 but not 7.1, it should show an option for 5.1, and not 7.1
<angasule> yeap, of course
<angasule> Treenaks: I think that can be done by asking alsa how many channels are available?
<Treenaks> angasule: something like that
<Treenaks> sabdfl: Do you have any idea when/where the next dev conference will be? (or when it'll be announced :)
<angasule> so, need help with this little thing? sounds like a small project I could help with :D
<Treenaks> angasule: let's wiki up a spec ;)
<Treenaks> or launchpad.. 
<shawarma> Treenaks: https://wiki.ubuntu.com/UDS-Sevilla
<angasule> any chance you'll be going to debconf?
<angasule> I'm definitely going to debconf for one simple reason: it's about 500km from me :)
<Treenaks> shawarma: ooh! Sevilla
<angasule> el que se fue de Sevilla perdio su silla jej
<shawarma> I hope he found it again.
<shawarma> :-/
<sabdfl> seville, andalucia (spain), early may
<sabdfl> then boston, USA, in november
<sabdfl> i think there was a mail to u-announce recently with details
<sabdfl> Treenaks: 
<sabdfl> ^^^
<angasule> hahaha shawarma, that's a phrase one says when one sits in someone else's chair
<angasule> it usually ends in a fist fight
<Treenaks> sabdfl: thanks :)
<shawarma> angasule: Oh, that makes a bit more sense. :-)
<zul__> why not montreal again? ;)
<Treenaks> zul__: montreal rocked :)
<shawarma> I think it's good to have every other conference on this side of the big pond.
<Treenaks> zul__: but so did Barcelona :)
<zul__> Treenaks: and its a 2 hour drive from me
<Seveas> sabdfl, does 23:00 UTC on nov. 26 suit your schedule for a CC meeting?
<shawarma> sabdfl: I can't help but notice that there's no sponsorship subpage on the UDS-Sevilla page on the Wiki. Will there not be any sponsoring this time or has the page just not been created yet?
<robertj_> will gtk input methods ultimately be succeeded by uim?
<cjwatson> Riddell: the underlying bit of the partman interface flow is literally a toggle switch - you select that option in the choose_partition select question, and it toggles the value of format
<cjwatson> Riddell: so you need to invoke edit_partition(format=whatever) strictly when the value is toggled
<jharr> where do I report apic problems?
<zul> jharr: launchpad.net
<sabdfl> Seveas: seriously, november?
<sabdfl> shawarma: there will be sponsorships, but we're nominating internally rather than inviting applications
<Seveas> sabdfl, I meant february of course, don't know what I was thinking there
<sabdfl> Seveas: can do
<Seveas> sabdfl, ok, then I'll announce the meeting
<ajmitch> morning
<_ion> Evening.
<sladen> angasule: could you write up your experiences with OpenAL on a wiki-page if it's not something that works out of the box
<sladen> sometimes it's possible to get "jack sense" from the card when something is inserted, but not always
<angasule> I'll add it to this: https://help.ubuntu.com/community/SurroundSound
<angasule> and with Treenaks we're working on this: https://wiki.ubuntu.com/SurroundSupportSpec
<angasule> OpenAL on linux is nearly dead, btw
<hardaway> any idea when Xorg 7.2 will be in repos
<geser> hardaway: afaik it's on the way, the first packages are already there. I'd expect the remaining packages to follow soon
<hardaway> thank you
<angasule> sladen: http://help.ubuntu.com/community/SurroundSound  <-- I added some tips, not much, but at least it worked for me...
<Treenaks> sladen: ubucon?
<Treenaks> sladen: (re: wiki edit :)
<sladen> Treenaks: there's several contigious events
<Treenaks> sladen: ah
<crimsun> angasule: thanks for the entries. Note however that many codecs require custom routing (ttables); you may wish to add a note about directing users to #alsa, where a few of us get those sorted out.
<angasule> crimsun: done :)
<angasule> autoreconf is old/deprecated?
#ubuntu-devel 2008-02-11
<crimsun> mateusz: you'll probably find https://wiki.ubuntu.com/KernelMaintenance#head-ef6ca858b4b97c1ad30639e34d92abb11ef37cf8 useful, but I recommend you inspect updating it for a hardy SAUCE one.
<crimsun> inspect->consider working on
<mateusz> crimsun: I am not using hardy
<crimsun> mateusz: that's fine; I merely mentioned consider benefitting others.
<mateusz> crimsun: there must be a reason why this patch is from 2006 now in mainline of kernel
<mateusz> no in mainline
<mateusz> crimsun: is ubuntu 2.6.22 kernel modifed ?
<mateusz> crimsun: I thought the sources are vanilla
<mateusz> so it should be possible to applay patch on 2.6.22.9
<crimsun> mateusz: yes, the Ubuntu kernels are modified.
<mateusz> quilt or dpatch ?
<mjg59> No
<crimsun> mateusz: git.  https://kernel.ubuntu.com
<mateusz> heh.. but the tar.bz shouldnt be modified
<mateusz> then how am I suppose to applay patch which only applays on vanilla while preserving all ubuntu patches ?
<mjg59> If it only applies to vanilla, then the Ubuntu patches would be unlikely to apply after you applied it
<mateusz> mjg59: if I want to make a patch for current ubuntu kernel
<mateusz> mjg59: what I should do?
<mateusz> mjg59: for the 2.6.22-14 I guess this one is in gutsy
<mjg59> Grab the kernel source, and generate a patch against it
<mateusz> from git?
<mateusz> or from source package /
<mjg59> If you don't want it to go to the main distribution, then just apt-get the source
<mateusz> No, I want it to go to main dist
<mjg59> Then the best way is to pull the git tree, make your change, commit it and then publish your git tree
<mjg59> Then you can ask kernel-team@ubuntu.com to pull from your tree - best way is to file a bug report and mention that in the pull request
<mjg59> But only critical bug fixes are likely to be applied against the gutsy tree
<mateusz> this is serious bug
<mateusz> as there are packages in gutsy
<mateusz> which need that patch
<mateusz> they're useless
<mateusz> and its very misleading
<mateusz> mjg59: is it possible to use hardy as desktop?
<pitti> Good morning
<dholbach> good morning
<warp10> Good morning!
<pitti> hi warp10
<warp10> pitti: :)
<pitti> does anyone know a good shell pendant of wait(..., NOWAIT), i. e. checking if a backgrounded process finished? "jobs | grep Done" smells too much like a hack to me
<seb128> hey pitti
 * pitti hugs seb128
 * seb128 hugs pitti
<soren> pitti: test -d /proc/$pid ?
<soren> or
<soren> ps -p $pid > /dev/null
<pitti> soren: hm, that could work; so I just need to convert the jobspec (%1) to a pid
<pitti> jobs -l
 * pitti notices that jobs -s and -r options don't actually work
<persia> jobs -r works for me
<pitti> -r shows "done", and -s shows "Running" ones for me
<pitti> heh, maybe I should just trap SIGCHLD
<soren> pitti: Can't you just grab the pid when you just started it?
<soren> From $!..
<pitti> oh, handy
<soren> Very :)
<pitti> (that's not in man dash)
<soren> Sure it is.
<pitti> nor in man bash
<soren> In the "Special parameters" section.
<soren> !            Expands to the process ID of the most recent background command executed from the current shell.
<soren> For a
<soren>                   pipeline, the process ID is that of the last command in the pipeline.
<lool> I do find these $.* expansions hard to grep for in the *sh man pages too  :)
<soren> lool: I usually just grep for something like ! and then scroll up and down a bit :)
<pitti> soren: ah, too bad; the process needs to be fg'ed/wait'ed on, otherwise it'll stay in ps output forever as Z
<pitti> soren: (likewise, kill -0 keeps succeeding)
<pitti> bah
<pitti> oh, hm, now it works; odd
<pitti> while kill -0 $!; do
<pitti> ok, that seems to do the trick
<soren> dash has a "wait" builtin.
<soren> AFAIR
<pitti> right, but that blocks
<soren> point
<pitti> I want to move fsck into the background, update usplash in teh foreground
<soren> When is the source changes file supposed to contain the Description field?
<soren> I see that it changed with my new dpkg merge and I'm wondering if I bollocksed it up somehow.
<pitti> that's news to me, too
<soren>   * Some code refactoring on dpkg-genchanges and bug fixes in the generation
<soren>     of the Description: field. As a result, source only uploads will no more
<soren>     have Description fields.
<soren> That explains it :)
<soren> Ok, so I didn't break it. \o/
<thegodfather> soren: did you complete the libvirt transition now?
<pitti> well, I guess few, if any, people actually want to read that
<thegodfather> (vs libxen)
<soren> thegodfather: I belive I did so on Friday.
<thegodfather> soren: ok thanks
<soren> :)
 * thegodfather prepares a new cluster upload
<soren> Yay!
 * soren taps his fingers waiting for the clock to hit 11:29 so that he can get shiny, new, working server install iso's. Whee!
<pochu> soren: the gtk-vnc patch is used by your virt-* combo keys stuff, am I right? I'm wondering whether it makes sense to forward the patch to the Debian maintainer, but I thought it would only make sense if the virt-* maintainers were going to use it. But as he maintains virt-viewer I think I'll forward it to him and let him decide if he wants it or not
<soren> pochu: No, they're entirely separate.
<soren> pochu: The patch enables an extension to the VNC protocol that sends key codes rather than keysyms over the wire. This alleviates practially all problems you might encounter if you're not using US keymapping everywhere.
<soren> pochu: The combo keys stuff is just a one-liner. (assuming we're talking about the same combo keys stuff)
<Riddell> pitti: can you move the feisty and gutsy packages of bug 184149 to -updates sometime?  they've been verified by sru-verification
<ubotu> Launchpad bug 184149 in kdelibs "[hardy]xembed and flash support patches doesn't work for konqueror" [Undecided,Fix committed] https://launchpad.net/bugs/184149
<pitti> Riddell: yes
<lool> soren: I saw this in a cl when updating: http://paste.ubuntu.com/4426/ perhaps it's worth cherrypicking the dpkg-gensymbols changes?
<pitti> Riddell: done; doing kitchensync now, too
<Riddell> thanks
<soren> lool: dpkg 1.14.16.6ubuntu1 will be uploaded later today.
<eradicus>  /j #ubuntu-kernel
<eradicus> oops
<lool> soren: Excellent; thanks!
<tkamppeter> hi pitti
<pitti> hi tkamppeter
<tkamppeter> pitti, have you seen my mails about the Brother driver packages?
<pitti> tkamppeter: yes, and answered one which was incomplete; your review was good otherwise
<slytherin> elmo: lamont: Is it possible preseed the debconf question for j2sdk package on buildd. batik has an FTBFS currently and uses j2sdk as build dependency.
<tkamppeter> pitti, your answer did not arrive in my mailbox, did you send it only to Jeremy?
<pitti> tkamppeter: no, To: was you, and CC: was Jeremy and SaÃ¯vann
<tkamppeter> It really did not arrive at me, I even looked into my spam folders.
<pitti> tkamppeter: let me boot my notebook and check if it's stuck in its local MTA
<pitti> oh, argh
<pitti> there are 24 mails stuck in the local MTA, sorry
<pitti> ok, flushed
<pitti> tkamppeter: you should get it any second now
<tkamppeter> pitti, I got them now. Thanks.
<pitti> tkamppeter: thanks for poking me about this; I now added a 'stuck MTA' check into my .bashrc :)
<Hobbsee> pitti: like the mega killall gnome script?
<pitti> much less intimidating :)
<Hobbsee> awww
<pitti> mailq | grep -v 'is empty'
 * Hobbsee wonders what else pitti has
<slytherin> pitti: Sorry I couldn't be available on weekend for testing jockey. Have you created handler for broadcom?
<pitti> slytherin: yes, and tested by TheMuso; I uploaded it to Hardy this morning (2ubuntu3), so maybe you can test that version in the archive?
<slytherin> pitti: Ok. I will do it tomorrow probably
<pitti> slytherin: great, thanks
<geser> pitti: please give back: gutsy-wallpapers feisty-gdm-themes. They failed to upload due to main -> universe demotion. Thanks.
<Hobbsee> geser: (done)
<geser> Hobbsee: thanks
<DarkSun88> Hi all
<Mithrandir> pitti: why is it the ConsoleKit dbus policy allows root to send to "org.freedesktop.ConsoleKit.Manager" with a member of "OpenConsoleWithParameters", but disallows others to use the member "OpenSessionWithParameters"?  (Note different member parameter)
<pitti> re
<seb128> StevenK: could you update bluez-utils to 3
<seb128> 3.26?
<pitti> geser: done
<Hobbsee> seb128: (he'll probably be asleep by now)
<Mithrandir> seb128: any interesting changes or just because it has a higher version number?
<pitti> Mithrandir: hm, good question; might be a typo
<seb128> Mithrandir: the new gnome-bluetooth requires the new version
<Mithrandir> seb128: ok
<seb128> Mithrandir: I'm pinging StevenK because he did the previous update, if you want to do it you are welcome ;-)
<Mithrandir> pitti: yes, that was what I was wondering.  And I'm wondering how I'm going to write something that is to CK like how seahorse, gpg-agent, ssh-agent and friends are to their programs.
<Mithrandir> seb128: yeah, pondering it, to take my brain away from being fried on OverdoseKit.
<pitti> Mithrandir: I'll file a bug upstream and see what they say
<Mithrandir> pitti: coolie
<pitti> Mithrandir: freedesktop bug 14459; I checked that it's still like that in git head
<ubotu> Freedesktop bug 14459 in Daemon "Typo in dbus.conf: OpenConsoleWithParameters()" [Normal,New] http://bugzilla.freedesktop.org/show_bug.cgi?id=14459
<pitti> Mithrandir: thanks for pointing out
<Mithrandir> pitti: happy to help.
<zul> pitti: when you get a chance can you look at the vblade MIR again.
<pitti> zul, soren: dnsmasq? why can't kvm etc. use our standard dhcp3-server?
<pitti> in hardy we try to *reduce* duplication, not introduce more of it :/
<pitti> zul: vlade> ack
<zul> pitti: thanks
<mateusz> Is Ubuntu kernel patched with hdaps_protect ?
<Ko_deZ> Hi all
<Ko_deZ> I am playing with pbuilder, and having some problems
<Ko_deZ> I am trying to compile the latest dvb-apps (linuxtv project), and it fails.
<Ko_deZ> http://pastebin.com/d1a7bb138
<Ko_deZ> actually it fails when compiling on my local system as well.
<soren> pitti: Because dnsmasq is small and lovely unlike that other thing.
<Ko_deZ> Could anyone give me a hint on what makes this error appear?
<Ko_deZ> I am running kubuntu 7.10
<pitti> soren: but we have used and supported dhcp3-server for years, and suddenly pulling in another one sounds bad both maintenance and support-wise
<soren> pitti: The alternative is to maintain weird, ugly patches to stuff like libvirt.
<Riddell> Ko_deZ: talk to upstream
<pitti> soren: to change the called command from dnsmasq to dhcp3d?
<soren> pitti: You realise they're not cli compatible?
<pitti> sure
<soren> pitti: ...and that dnsmasq also provides dns.
<cjwatson> mateusz: #ubuntu-kernel would be more effctive
<cjwatson> effective
<soren> pitti: and is made for this particular scenario..
<pitti> soren: why not have the dhcp server just pass the host nameserver?
<pitti> soren: can you please list some reasons in the MIR?
<Ko_deZ> Riddell: I have been trying to get help on their irc channel for a while. No luck. I was hoping someone could tell me if there is a dev or header file I need to install for this.
<pitti> TBH, we have enough bugs on dhcp3, we don't really need more from dnsmasq
<pitti> and we should check this with the support team, too
<pitti> soren: I perfectly see the rationale for dnsmasq on an embedded system like openwrt
 * soren is on the phone
<pitti> but on a server which is beefy enough to run kvm it hardly matters
<soren> Gimme 5 minutes.
<pitti> soren: ah; no problem, take your time :)
<pitti> (random note: just got a wrt54 on the weekend, with openwrt; nice toy!)
<Mithrandir> there, new bluez-{libs,utils} uploaded.
 * seb128 hugs Mithrandir
<seb128> Mithrandir: thanks
<seb128> crevette: ^
<Riddell> evand: tm_t has been talking to you about windows profile for qt ubiquity?
<evand> Riddell: indeed, in the middle of a conversation with him now about it
<evand> I'm unfamiliar with COSS.fi though.
<Riddell> evand: if he gets it are you happy to answer his questions about the debconf side?
<tjaalton> coss.fi is an organization promoting the use of open-source software in Finland
<evand> Riddell: yeah, I basically said the important bit is the core migration-assistant C code.  Things outside of that, like the ubiquity GUI bits are either bonus, or can be learned along the way (Debian policy, debconf, if needed at all)
<Riddell> evand: surely it's not much use without a GUI?
<soren> pitti: I've added a bit of info to https://wiki.ubuntu.com/MainInclusionDnsMasq
<evand> well no, it's not.  But my point was that the GUI is a small aspect of the code nowadays.  It's just a matter of updating the KDE ubiquity UI to match the GTK side.
<evand> Riddell: ^
<Riddell> evand: ok, thanks
<evand> But it's a just a treeview with the GTK set/get code already there, so it should be a simple port.
<pitti> soren: why do we need bind for kvm in the first place?
<selckin> soren: debian maintance link 404's
<pitti> soren: and our libc already DTRT for resolv.conf changes
<soren> pitti: It's for libvirt. Does it say kvm?
<soren> That's a mistake.
<pitti> well, yeah, libvirt
<soren> pitti: Why? Er.. Becuase I'm running virtual machines in it that would like to lookup stuff in dns?
<soren> pitti: libc does not come into play at all.
<soren> pitti: er.. for dns lookups at least.
<soren> pitti: And we don't need bind. We need dnsmasq :)
<pitti> my question is, why do we need a nameserver at all?
<soren> ..
<pitti> the guests can just use the host's nameserver (that works fine for me at least)
<soren> Tons of reasons.
<soren> a) the host's dns might change.
<soren> b) you might move your vm to another host.
<pitti> ^ good reason
<soren> selckin: Fixed. Thansk.
<soren> alias Thansk=Thanks
<soren> ah..
<dholbach> can somebody moderate my ubuntu-devel-announce mail?
<dholbach> mvo: your stuff in OpenSUSE and Slackware: http://blogs.warwick.ac.uk/bweber/entry/untitled_entry_1/ - http://www.fredemmott.co.uk/blog_133
<mvo> dholbach: meh, cool!
<seb128> mvo: what is cool?
<mvo> seb128: command-not-found seems to become popular in other distros as well
<seb128> ah, nice
<seb128> mvo: what distro is using it now?
<dholbach> seb128: opensuse and slackware
<seb128> slackware has a packaging system now? ;-)
<mvo> heh :)
<asac> soren: avail?
<soren> asac: Wazzup?
<asac> soren: lol :) ... what do you think about nm vpn plugins going to main?
<asac> soren: i assume you know better how well upstream deals with security updates and how much they care about stable branch maintenance
<asac> soren: and maybe you know about any blocker that might lead to a bad user experience
<soren> asac: I'm afraid noone gives much attention to the vpn plugins.
<soren> asac: Last I checked, they never even had a proper release. I've always just grabbed a random svn checkout.
<asac> ok. i think that would be enough of a blocker to disqualify them from entering main :/
<asac> who maintains them upstream? is it the same team that does NM ?
<soren> asac: I'm not sure to be honest. I'd ask on the mailing list if I were you.
<asac> soren: ok ... do you speak for all vpn plugins or just the vpnc one?
<soren> I haven't looked into them for over a year and even then I mostly just did the packaging and wrote a few small patches.
<asac> ok thanks
<soren> asac: vpnc and openvpn, but I have the feeling it's true for all three (or four if the ipsec one was ever finished).
<soren> ...things might have changed over the last year, but I haven't seen much activity about them on the nm mailing list.
<asac> yeah
<soren> I think the functionality is really cool, but I'm afraid this is one of the times where the lack of activity can't be excused by "if it works, don't fix it" :)
<asac> right ... there are definitly a few bugs that might justify some activity
<soren> Quite so.
<DarkSun88> Hi all
<wasabi> So... the 'kvm' module keeps loading... even though I have it black listed... and it's incompatible with vmware (causes system to crash). Why might the blacklist be ignored in this case?
<pitti> Mithrandir: got a response from CK upstream; so it's really s/Console/System/ in the dbus conf
<TeXnicer> Moin!
<TeXnicer> Is this english?
<TeXnicer> Nihongo? Farsi? Francais? Neederlaans?
<_MMA_> TeXnicer: DO you want to know the language of the channel? If so, its English.
<thom> english
<TeXnicer> Rgr. Thx.
<TeXnicer> Well, this IS a support question, while I was redirected from #ubuntu-de -> #debian-de -> #ubuntu-devel... looking for help concerning my Harddiskdrive
<mjg59> TeXnicer: Then I'm afraid this isn't the right place to ask
<TeXnicer> 2.5" Toshiba 6GB rather old, was accessed well under 6.10, since 7.10 I get bad bootmessages
<TeXnicer> like in pata and /grub/menu.lst   ... any clue -- or at least where to look?
<TeXnicer> mjg59: Where might be the right place to ask or lookup?
<TeXnicer> BTW: Where can I push forward the translation-programm (german)?
<_MMA_> TeXnicer: #ubuntu #ubuntu-forums or the Ubuntu Forums themselves.
<_MMA_> Sorry, #ubuntuforums
<TeXnicer> mma just got forwarded? LOL
<TeXnicer> ubuntu-forums
<TeXnicer> Thx! Go ahead! Keep it on, folks... I thank you for such an nice distri!
<_MMA_> TeXnicer: I'm gonna say bad hardware or something to do with the libata transition. Anymore than that, I would say look into the places above.
<TeXnicer> hardware seems to be okay under 6.10
<TeXnicer> i try in -forums now, thx&bye!
<bSON> hi
<bSON> (05:31:11 PM) denisw: where does apport save the apps for which it shouldn't show any bug reporting dialogs for?
<bSON> oops, yeah the question is copy-pasted here ;)
<geser> pitti: it looks like pkg-create-dbgsym got broken, all builds fail with "dpkg-gencontrol: failure: cannot read -: No such file or directory
<geser> Error: parsed ddeb section or priority is empty
<geser> make: *** [binary-arch] Error 1"
<geser> e.g. http://launchpadlibrarian.net/11875738/buildlog_ubuntu-hardy-amd64.netpbm-free_2%3A10.0-11.1_FAILEDTOBUILD.txt.gz
<seb128> are the LANG and LANGUAGE formats described somewhere?
<slangasek> ebman 7 locale?
<slangasek> seb128: man 7 locale?
<seb128> slangasek: no LANG or LANGUAGE there on my hardy
<seb128> ups
<seb128> no, no description or what they contain
<slangasek> hmm, ok
<seb128> slangasek: the issue is
<seb128> $ cat /etc/default/locale
<seb128> LANG="fr_FR.UTF-8"
<seb128> LANGUAGE="fr_FR:fr:en_GB:en"
<seb128> or gdm use LANGUAGE
<seb128> and complains about fr_FR not being a valid locale
<seb128> which is right
<slangasek> hmm
<seb128> and I'm not sure on whether gdm is wrong to expect locales there or if LANGUAGE should be fr_FR.UTF-8:en_GB.UTF-8:etc
<slangasek> LANGUAGE isn't supposed to be a list of locales, but a list of languages
<slangasek> but it's a GNU extension, I don't know where it's documented
<seb128> is that written somewhere?
<seb128> hum, k
<geser> soren: the new dpkg seems to cause many FTBFS on the buildds
<LaserJock> pitti: any ETA on when the gutsy lang packs in PPA will make it to -updates?
<slangasek> geser: how do you know it's the new dpkg?  the new dpkg was uploaded some time ago, was it not installed on the buildds until now?
<seb128> slangasek: the build log he pointed before has the new dpkg installed
<seb128> slangasek: and looks like a pkg-create-dbgsym issue, likely created by the dpkg changes
<slangasek> seb128: but so does an older, successful build log from earlier
<slangasek> er, oh
<slangasek> no, now I see the new dpkg, n/m :)
<geser> slangasek: dpkg 1.14.16ubuntu1 got uploaded 3 hours ago
<geser> slangasek: http://launchpadlibrarian.net/11876179/buildlog_ubuntu-hardy-amd64.scrapbook_1.3.2.5-2ubuntu1_FAILEDTOBUILD.txt.gz might be the same problem but here the package build on i386
<slangasek> geser: yes, I was evidently looking at stale archive state and thought dpkg was last uploaded mid-January
<soren> Argh, fuck.
<soren> slangasek: Got a plan?
<soren> slangasek: Any idea what the problem is?
<slangasek> soren: no clue at this point
<seb128> soren: perfect timing, just when the new GNOME is being uploaded ;-)
<slangasek> I was hoping you had a better idea, since you'd done the merge ;)
<soren> slangasek: No, I'll look into it right away.
<torkel> seb128: re LANGUAGE see http://www.gnu.org/software/libc/manual/html_node/Locale-Categories.html#Locale-Categories
<soren> slangasek: Does everything fail?
<slangasek> soren: pkg-create-dbgsyms seems to be failing rather consistently, but I haven't verified whether there are cases where it succeeds (I'm not sure how to go about looking those up)
<soren> slangasek: Me neither.
<soren> No, some things work.
<soren> I'm looking at a pure arch:all package that built just fine.
<soren> http://launchpadlibrarian.net/11876766/buildlog_ubuntu-hardy-i386.kqemu_1.3.0%7Epre11-8_FULLYBUILT.txt.gz
<slangasek> a pure arch: all package shouldn't have pkg-create-dbgsyms try to do anything significant though :)
<soren> If I don't have pkg-craete-dbgsyms locally everything works, yes.
<soren> That explains why I didn't see it while testing.
<geser> soren: http://launchpadlibrarian.net/11875714/buildlog_ubuntu-hardy-amd64.flex_2.5.34-2.1_FULLYBUILT.txt.gz has some interesting warnings: "Use of uninitialized value in hash element at /usr/bin/dpkg-genchanges line 468."
<seb128> torkel: thanks
<soren> geser: Erk, yes, that doesn't look too well.
<slangasek> soren: I guess it's dpkg-gencontrol that's failing, right? there are a number of changes to that file in the merge; how does pkg-create-dbgsyms invoke it?
<soren> slangasek: I'm trying to figure that out.
<slangasek> ok :)
<soren> The only changes I made to dpkg-genchanges are about Launchad-Bugs-Fixed magic.
<soren> At least that was the intent.
<soren> :)
<geser> soren: but this warning exist also in http://launchpadlibrarian.net/11869736/buildlog_ubuntu-hardy-amd64.apt_0.7.9ubuntu9_FULLYBUILT.txt.gz which still used the old dpkg, so nothing new
<soren> geser: Lovely, thanks for looking that up! That's likely to have saved me quite a bit of head ache :)
<slangasek> soren: right; it's dpkg 1.14.16.6 that has the sweeping changes to dpkg-gencontrol
<soren> pitti: around?
 * soren boggles at the fact that there's logic in pkg-create-dbgsym for debhelper compat level 1
<soren> Ah... I've got a good guess as to what's going on..
<soren> Er...
<soren> I'm no perl guru, but isn't the third argumennt to open supposed to be the flags?
<soren> From the new dpkg: open(CDATA, "<", $file)
<soren> Kaboom!
<soren> The old dpkg:
<soren>     open(CDATA, "< $controlfile") ||
<blueyed> soren: maybe open(CDATA, "<".$file) was intended (but no perl guru either)
<soren> That would probably work, too. I've change it to "< $file".
<slangasek> soren: that appears to be legal use of perl open(), but if you want to use the magic '-' value for stdin or stdout it apparently doesn't work so well
<slangasek> "In the 2-arguments (and 1-argument) form opening â-â opens STDIN and opening '>-' opens STDOUT." perlfunc(1)
<slangasek> and if you use the comma, you obviously aren't using the 2-argument form, so. :)
<soren> slangasek: How do we fix this?
<slangasek> soren: I think the fix you just described would be correct
<soren> slangasek: If I just upload the new one, it'll fail to build.
<slangasek> will it? are there dbgsym packages built from dpkg?
<soren> Sure.
<soren> Only dpkg-dev is arch:all.
<slangasek> well, upload the fix all the same, and then we can beg a manual bootstrapping from a buildd admin
<geser> I've tested the new dpkg-dev with the old /usr/bin/dpkg-genchanges but still the same error
<soren> geser: YEs, it's in $PERL/Dpkg/Control.pm
<soren> slangasek: Yeah.
<soren> lamont: Around?
<lamont> yeah
<lamont> in this channel anyway. :-)
<soren> Are you following this, or should I fill you in?
<lamont> soren: --> infinity
<soren> Alright.
<soren> infinity: Are you following this?
<soren> infinity: New dpkg broke the world. A new upload of dpkg will just ftbfs, so I need manual intervention.
<geser> soren: iirc there is an option to disable the package mangling, or will it failed for other reasons?
<soren> NO_PKG_MANGE will certainly fix it.
<soren> NO_PKG_MANGLE, even.
<soren> slangasek: What do you think? Upload a fixed version with that, have it built and published, and the upload a new one without NO_PKG_MANGLE?
<slangasek> soren: oh, sure, go for it
<soren> Will do.
<seb128> soren: right I would do that
<soren> I'm on it.
<soren> infinity: Never mind :)
 * soren uploads
 * seb128 hugs soren
<soren> debian bug 465340
<ubotu> Debian bug 465340 in dpkg "dpkg: Broken call to open in Dpkg/Control.pm" [Important,Open] http://bugs.debian.org/465340
<soren> I hope "important" is an appropriate severity. I wasn't sure.
<xivulon> TheMuso, re accessibility wanted to show current wubi dialog
<TheMuso> xivulon: right
<xivulon> this is the current version
<xivulon> http://img123.imageshack.us/img123/4568/screenshotwubisetupld0.png
<xivulon> but I am not too pleased with it
<xivulon> as mentioned in the email, wouldn't it be better if the accessibility and mobility options were not mutually exclusive?
<TheMuso> xivulon: I was actually going to reply to your email. Braille at this point should not be a check box, because on the live CD boot menu, it can not be used as such. It shoudl be a radio button like the rest.
<xivulon> that would translate to all checkbox in the dialog (without "None" option)
<TheMuso> xivulon: At the moment this is not possible, due to the way the live CD boot menu works, and I don't think they can be turned on and off in that menu. cjwatson, do you have any idea whether having the accessibility menu act like check boxes, instead of single selectable options only is possible?
<TheMuso> And, for many of them, it doesn't make sense. One would either want one, or the other.
<soren> Er.... I'm not getting an ACCEPT mail..
<seb128> soren: maybe elmo did something again
<xivulon> TheMuso, I am no expert, but I would expect that someone might want both visibility and keyboard-modifiers
<xivulon> or magnifier + screen reader
<seb128> soren: I didn't get accepted mail either for my gnome-desktop upload
<soren> seb128: What did you do? Reupload?
<TheMuso> xivulon: Yes, however the underlying code on the Linux side doesn't really support this properly yet, and its probably a little too late to go changing it for hardy, as its working quite well at the moment. However, this is certainly something we can look at doing for hardy+1.
<seb128> soren: no, the gnome-desktop upload was from 15 minutes ago or so
<soren> seb128: Oh, ok.
<seb128> soren: but the uploads were not processed this morning neither, some people asked on IRC and elmo fixed it
<soren> Hrm..
<evand> TheMuso: cjwatson recently added checkbox support to isolinux, so yes, it is possible.
<xivulon> casper-bottom can probably take multiple arguments not sure about gfx interface
<soren> elmo: Around? It seems that soyuz might be failing to pick up uploads.. Rumour has it that you're the man to fix it.
<TheMuso> evand: Ooo ok, I wonder how much work it is to change the a11y menu. If its not too difficult, I could easily hack on the code for casper to get it support such a configuration by thursday.
<TheMuso> xivulon: Yes it can take multiple arguments, but its the code that processes those arguments and takes the appropriate action that needs to be changed.
<evand> TheMuso: the casper code works with multiple a11y arguments alreayd.
<evand> already*
<TheMuso> evand: Are you sure?
<evand> TheMuso: yes, it processes every /proc/cmdline option.
<xivulon> can we the have boot parameters such as accessibility_v1 accessibility_m2 accessibility_braille
<TheMuso> evand: I know that, but I am referring to the code withint eh individual cases. We'd need to be sure that one profile doesn't overwrite another's settings./
<evand> TheMuso: ah, indeed
<evand> xivulon: what's wrong with the way they're currently implemented?
<TheMuso> evand: Heh I was the original author of that file back in 2006.
<TheMuso> It has since undergone way too many changes to keep track of. :p
<evand> TheMuso: heh, indeed :)
<geser> soren: luckily today is not friday, usually such things are reserved for fridays
<xivulon> evand, IIRC now it sets a single variable
 * xivulon looking at code
<xivulon> no it does not
<evand> indeed, it should work fine as is
<xivulon> current implementation is fine, other than the caveat from TheMuso
 * TheMuso looks at the code again.
<evand> indeed, I was just going to say
<evand> TheMuso: be sure to look at the copy from bzr
<TheMuso> evand: Yeah I saw your upload.
<evand> I have changes in there that haven't made it to the archive yet
<evand> ok
<TheMuso> I just pulled the latest changes.
<evand> fantastic
 * TheMuso goes to scour the code now.
<soren> Aw, shame on me for not passing proper -vstuff to dpkg-genchanges when merging dpkg.
<TheMuso> evand: Any reason why you used orca-customizations.py, and not the standard user-settings.py file?
<evand> TheMuso:
<evand> whoops
<evand> TheMuso: "Generated by orca. DO NOT EDIT THIS FILE!!!"
<TheMuso> Fair enough.
<evand> orca-customizations.py seems to be the proper place for such things
<TheMuso> evand: It also seems that for the magnifier and braille profiles, you've enabled speech when speech is not needed.
<TheMuso> s/needed/wanted/
<elmo> seb128/soren: I broke soyuz temporarily while doing emergency maintenance for the kernel root exploit - I'm definitely not the go to guy everytime soyuz stops working
<evand> TheMuso: I think I just did a simple sed, let me check though.
<seb128> elmo: ok, sorry, I though you might have been working on the same thing that this morning
<xivulon> better http://img405.imageshack.us/my.php?image=screenshotwubisetup1ka0.png
<TheMuso> xivulon, evand. The only profile where things get overwritten/are shared between profiles but different settings, are the two motor disability profiles, i.e m1 and m2. I am also not sure as to whether the KDE/XFCE stuff overwrites itself for different profiles, but gconf wise, and orca wise, all other profiles do not break each other.
<soren> elmo: Was that this morning or just now?
<elmo> soren: this morning
<xivulon> TheMuso in this case if both m1 and m2 are true we go with m2
<xivulon> I guess
<TheMuso> xivulon: Well its up to the code to work that out, but I wouldn't make those two check boxes, however it also depends on the gfxboot possibilities.
<soren> elmo: Ok. So cprov/bigjools?
<evand> TheMuso: so I did, thanks for catching that.
<cjwatson> TheMuso: should be possible to make the access stuff checkbox, though it would change the keyboard navigation a bit (at the moment you'd have to press a number then escape)
<cjwatson> TheMuso: but at the moment a menu can only be all-checkbox or all-radio, not a mix
<TheMuso> evand: While you're at it, I'll get you to uncomment the enable_esd line in the blindness profile. We can finally have sound using pulse for speech.
<TheMuso> cjwatson: Right I thought as much.
<evand> TheMuso: will do
<cjwatson> so from what you were saying from the time being we might be better off staying with what we have
<TheMuso> cjwatson: I totally agree. It also makes things harder for those who can't see what they are doing.
<TheMuso> As there are more keys to press, with little to no feedback.
<xivulon> TheMuso on my side I am ok http://img183.imageshack.us/my.php?image=screenshotwubisetup2mn9.png
<xivulon> cjwatson have a look at the image above would like to stay close to cd interface
<xivulon> so do we go back to all radio buttons?
<elmo> soren: normally yes
<elmo> soren: mthaddon's fixed it
<TheMuso> xivulon: I'd say so, simply because we can't have a mix on the gfxboot menu. However its nice to know that the code is pretty much fine if in the future we wish to change things.
<TheMuso> And, that is actually something worth considering for the future.
<TheMuso> At the start of the next cycle, I'll see what the community has to say about that idea.
<soren> elmo: Excellent. Thanks very much.
<evand> TheMuso: enable_esd is on by default.  In fact, the commentted out line actually disables esd.  Any objection to me just removing the comment entirely?
<xivulon> last http://img155.imageshack.us/my.php?image=screenshotwubisetup3kd3.png
<TheMuso> evand: Sorry, I got confused, yes remove that, and the comment above it, thanks.
<evand> will do
<TheMuso> xivulon: I don't personally care how it looks, as long as it works, and windows screen readers can work with it. Let me know when this is available for testing, and I will test it.
<TheMuso> And get others with other screen readers to test it also.
<xivulon> TheMuso, tonight wubi build will include that, but it won't work until the new ISO is up with grub-installer/lupin patches
<TheMuso> xivulon: Right. Is all of that likely to land for hardy?
<xivulon> Should be it'has been released already mostly
<TheMuso> xivulon: Ok.
<xivulon> But I am not the one in charge...
<TheMuso> xivulon: Ok I understand.
<TheMuso> cjwatson: I was looking over my logs from the weekend, and noticed talk about dmraid, and its possible inclusion into main, once partman-dmraid or whatever it was gets testing. Woudl you, 1) like me to test it, as I have a PCI card that uses such metadata that dmraid reads, and 2), integrate it into the initramfs error handling spec?
<xivulon> TheMuso, last build with accessibility page: http://wubi-installer.org/devel/minefield/Wubi-8.04-alpha-rev411.exe
<TheMuso> xivulon: Ok thanks. I'll have a look when I get a chance.
<cjwatson> TheMuso: 1) sounds good, coordinate with evand 2) if you have time, absolutely
<cjwatson> although I'm not sure how dmraid works with regard to the initramfs
<TheMuso> cjwatson: Well I'll have a look at the code at least.
#ubuntu-devel 2008-02-12
 * ogra_cmpc sighs about fedora
<ogra_cmpc> hrm
<soren> ogra_cmpc: hm?
<ogra_cmpc> soren, ach ... endless discussions with the fedora people about the --arch option in ltsp
<ogra_cmpc> they never heard about amd64 :P
<ogra_cmpc> and somethimes the attitude between the lines "there is no linux apart from fedora" is a bit well ...
<ogra_cmpc> ... tiring ?
<slangasek> maddening?  exasperating?  pity-inspiring? :)
<ogra_cmpc> :)
<soren> Gah... Is that really the time?
<soren> *headdesk* I have work tomorrow you know!
<slangasek> no, you're reading it upside-down
<Hobbsee> geser: ah good, i'm not going mad (w.r.t dpkg-gencontrol: failure: cannot read -)
<ogra_cmpc> soren, lol
<slangasek> it's actually hh:01
<slangasek> sorry, hh:10
<soren> Oh... good?
<slangasek> it's always good when it's the hour of the hardy heron
<soren> \o/
<Hobbsee> soren: oh dear.  i told you that you broke it :)
<soren> Hobbsee: You did.
<soren> You actually did.
<soren> I was bound to happen sooner or later.
 * jdong reads scrollback
<StevenK> Bwahaha
<jdong> sounds like fun, folks
<jdong> :)
<jdong> anyone else notice stuff FTBFSing on Hardy? (kidding :D)
<StevenK> "I was bound to happen sooner or later." <- sounds like the sage words of someone crazy enough to merge dpkg
<soren> Impossible!
<slangasek> StevenK: he is inevitable
<soren> That's me. Inevitable.
<soren> The best part about uploading dpkg? Knowing that your crack will be built *right* *now*.
<jdong> soren: and your crack seeds all other crack too :)
<soren> Yeah, that's the not so best part of it.
 * soren goes to bed
<soren> LS:10 is way too late for me to still be up.
<soren> I completely stopped making sense at hE:10.
<Hobbsee> soren: do try not to break it again, OK? :)
<Hobbsee> soren: Knowing that your crack will be built *right* *now*. <-- sounds like you should apply to be a buildd admin.
<Hobbsee> there are priorities for a reason!
<soren> Hobbsee: It's ironic, really. I was trying to be a good boy and even added a new test case to dpkg with this upload. Did it help? Nooooo..
<Hobbsee> soren: your upload is done and built and didn't break the world now, i tkae it?
<soren> https://edge.launchpad.net/ubuntu/+source/dpkg/1.14.16.6ubuntu2
<soren> I guess it needs to be published before the buildd's pick it up.
<soren> After that, it's give-back galore.
 * Hobbsee looks
<infinity> soren: No, it's built already.
<Hobbsee> yeah, just as i'm going on VAC.  great.
<Chipzz> soren: http://imgs.xkcd.com/comics/insomnia.png ;)
<infinity> soren: I'll do mass-give-backs once it's published.
<Hobbsee> infinity: who really cares about ia64 anyway
 * cjwatson hopes he didn't just break all the seeds
<Hobbsee> cjwatson: it's the day for breakage. why not?
 * cjwatson HIGHLY recommends not merging the seeds any more
<soren> cjwatson: Just fix them before FF, otherwise we'll have to live with broken seeds. :(
<cjwatson> unless you feel like a really fun resolution pass
<Hobbsee> cjwatson: so, uh, how does one merge seeds, or do that equivalent, now?
 * soren decides to stop trying to be funny and *really* goes to bed.
<Hobbsee> or am i missing something obvious?
<Chipzz> cjwatson: btw, are you responsible for consolekit integration?
<cjwatson> Hobbsee: largely, the idea is that we should stop needing to, because common things are in a single common place
<Hobbsee> soren: you'll probably break dpkg between now and then anyway, so the seed point will be moot.  *g*
<cjwatson> Chipzz: no
<cjwatson> Hobbsee: we're not quite at that ideal yet, but a lot closer than we were
<Hobbsee> cjwatson: oh good!  i'd wondered why they weren't previously
<Chipzz> hrrrm then I must be mistaken; nevermind then. who is though?
<cjwatson> Chipzz: pitti
<cjwatson> err, and if you just updated your seed branches, you might have to force it a bit - I just made a mistake and uncommitted
<Chipzz> cjwatson: is it possible that I recall you having a discussion about sudo and ck integration a couple of weeks ago?
<cjwatson> Chipzz: yes
<cjwatson> Chipzz: doesn't mean I'm responsible for it though, I was just playing with it and trying to improve a few things
<Chipzz> cjwatson: ah, because that actually was a reason for concern for me
<Chipzz> haven't played with ck yet, so I may be totally mistaken
<Chipzz> but integrating ck with sudo and/or login rang a couple of very loud alarmbells here
<cjwatson> do you mean ssh rather than sudo?
<Chipzz> no, sudo
<cjwatson> I wasn't integrating it with sudo
<cjwatson> all I was trying to do was make policykit applications not break hopelessly when invoked via sudo
<Chipzz> anyway, I'll be better off voicing my concerns with pitti maybe?
<cjwatson> sure
<Chipzz> but your input would be nicetoo I guess ;)
<cjwatson> well, I don't know what your concerns are
<cjwatson> but it's also 1:15am
<Chipzz> basically my concern is that adding ck as a dependency may complicate recovering a broken system
<Chipzz> (ie booting in rescue mode)
<Hobbsee> death to all evil keyboard bugs111
<cjwatson> Chipzz: well, nobody AFAIK was talking about making sudo register a CK session
<cjwatson> Chipzz: and rescue mode uses sulogin, not login, and therefore does not create a PAM session, so that would not involve CK either
<cjwatson> any sane implementation of CK integration lets the login manager continue if CK isn't available, anyway
<cjwatson> for instance if you use the PAM module you make it optional
<Chipzz> that's what I figured
<cjwatson> I think there's an argument (though it's still debatable) that sudo should forward CK credentials, but having it pretend to be a new console session seems rather a stretch
<Chipzz> but I shall ask pitti about it tomorrow. imho care should be taken not to complicate such scenarios (though one might argue that when your system is broken, well, it's broken...)
<cjwatson> I don't really think it would
<Chipzz> cjwatson: anyway, since this is pitti's stuff anyway, I'll bother you no more and let you get some sleep ;)
<cjwatson> thanks ;)
<Chipzz> good night (in case you're hitting the sack ;))
 * infinity manually shoves dpkg through the publisher...
 * lamont waves
<Hobbsee> hi lamont
<Seq> Does anybody know how to create their own kernel derivitive using the binary-custom folder? Mine seems to continually fail
<warp10> Good morning!
<pwnguin> im assuming the answer's no, but if I trigger a kernel panic, that stack trace wont be present anywhere on disk, right?
<pitti> Good morning
<stgraber> hi pitti
<pitti> geser: ugh; due to the new dpkg, I assume? I'll have a look soon
<pitti> LaserJock: I just accepted the packs in -proposed
<pitti> LaserJock: today I'll care for getting dapper to feisty langpacks synced, and then do an announcement on -translators@; if all goes well, I'll move them in a week
<pitti> soren: compat level 1 in pkg-create-dbgsym> yes, unfortunately we have packages which are *that* old and crappy :/
<pitti> soren: that sounded like fun; thanks for fixing it, is there anything I still need to do?
<LaserJock> pitti: k, awesome
<pitti> Chipzz: so, what exactly are your concerns with sudo and CK?
<Hobbsee> morning pitti!
<Chipzz> pitti: more like login and CK
<Chipzz> hrrrm wait :P sudo too actually
<Chipzz> my concern is that in case something breaks, that having CK in the mix would make it harder to fix things
<Chipzz> basically the way it is now, recovering a broken system (or rather: getting to a state where you can attempt to recover it) is not too complex
<Chipzz> FSVO "not too complex"
<Chipzz> ie
<Chipzz> booting with init=/bin/bash
<Chipzz> lets say the sudo <-> CK integration breaks
<Chipzz> atm sudo setup is not too complex, and little is required to say, reboot, log in as user, and use sudo to gain root
<Chipzz> little is required -> from a technical pov
<Chipzz> my concern (and I don't know if it's a valid concern) is that complicating sudo (and login) config may make it more error-prone, and increase the chances of you being unable to for example gain root access at all when stuff goes haywire
<dholbach> good morning
<simira> dholbach: the "good" part still is missing. But I hope you are having one. :)
<dholbach> thanks simira
 * dholbach hugs simira
<simira> :)
<Hobbsee> simira!
<emgent> moin
<simira> hi Hobbsee
 * simira is at school, with a terribly bad teacher.... (he is french, and not totally comfortable with Norwegian...)
<Hobbsee> erk!
<soren> pitti: I think it's under control. infinity said he'd be giving back all the stuff that broke because of it.
<pitti> good
<pitti> soren: you didn't disable NO_PKG_MANGLE yet, right?
<soren> pitti: Right. I'll do that later today.
<pitti> cool
<pitti> soren: the joys of dpkg :)
 * pitti hugs soren
<pitti> StevenK: oooh, promising changelog on libosso! :)
<slytherin> Why is latest daily alternate CD for i386 so small (491MB)?
<Hobbsee> seeds are probably botched
<slytherin> Hobbsee: looks like that is the case. Many important packages are missing
<seb128> hey Hobbsee pitti soren
<seb128> hello mvo
<seb128> soren: so the fixed dpkg has built?
<mvo> hey seb128
<soren> seb128: Yes, around 2AM last night.
<pitti> good morning mvo, seb128
 * soren is sleepy eyed.
<Hobbsee> hey seb128
<Hobbsee> soren: 2am is a great bedtime!
 * soren hugs pitti back
<soren> Hobbsee: It would have been, yes.
 * mvo hugs Hobbsee
<mvo> hey pitti
<seb128> around the time I stopped working then
 * Hobbsee hugs mvo.  morning!
 * seb128 is tired still and need coffee
 * Hobbsee inserts the caffeine drip
 * mvo needs tea
<seb128> hum, tea?
<seb128> no, need coffee first this morning
<seb128> ah, and builds have been retried during the night
<simira> mvo: hmm... good suggestion
<slytherin> Hobbsee: by the way, it is not i386 problem. All the CDs are very small
<Hobbsee> slytherin: it wouldnt' surprise me.  cjwatson should know why
<gaspa> pitti: i saw usplash... hm. there really was some dumb mistakes...
<StevenK> pitti: Do you think my libosso hack is too gruesome?
<pitti> gaspa: working fine now :) ; however, it's still not quite what I need, so I added another command (INPUTCHAR); will upload today
<pitti> StevenK: haven't looked at it yet (will do in a few), but it sounds like a great hack :)
<pitti> (in the *sniff* "good crack" sense)
<gaspa> pitti: ok... so you're not angry with me, isn't it ? :D :D
<pitti> gaspa: no, why should I? :)
<soren> wtf...
<gaspa> :P
<soren> It's *Tuesday*?!?
<gaspa> pitti: there's something other that should be done in usplash?
<pitti> soren: does that come as a big surprise for you?
<soren> pitti: Yes!
<pitti> gaspa: there are tons of bug reports...
<gaspa> ( someone's going to fosdem, this month? )
<soren> pitti: This is awesome! I just got an extra day until FF!
<pitti> good morning macd
<pitti> good morning MacSlow
<pitti> good morning Pi"I'm a lazy tab key user"tti
<gaspa> pitti: yes, but much of them seems arch-dependent...
<MacSlow> hi pitti
<MacSlow> odd... I thought I shut down xchat yesterday
<gaspa> so i wasn't able to reproduce them.
<soren> MacSlow: Shut down xchat? But that would log you off irc, wouldn't it?
<pitti> znc FTW!
<soren> znc?
<MacSlow> soren, yes... in the evening before going to bed this makes sense :)
<pitti> soren: apt-cache show znc (I have used this for some weeks now, it works great)
<soren> MacSlow: But, but... You'd be logged off irc!!!11!!!one!
<pitti> seb128: I'm about to look at MacSlow's sponsor request, or did you already?
<seb128> pitti: feel free, there is new upstream versions
<seb128> pitti: so if you want to do the update in the same time you are welcome
<Mithrandir> soren: you'd take IRC through a drip feed directly into your brain if you could. :-P
<seb128> pitti: the libwnck one should be easy
<pitti> soren: still better than wasting power over the night :) (but with a proxy you can have both)
<pitti> seb128: erm, I was just going to upload them
<pitti> seb128: *sigh*, ok, will do
<seb128> pitti: ok, do it, I'll pick those when I do the update
<seb128> pitti: no, don't bother, I'm fast at doing those updates ;-)
<soren> pitti: You turn off your computer too?!
<pitti> heh
<soren> Good thing I'm sitting down already..
<pitti> soren: sure, whenever I don't need it for at least an hour
<pitti> MacSlow: just a nitpick for the future: can you please use patch tags (https://wiki.ubuntu.com/UbuntuDevelopment/PatchTaggingGuidelines) for future patches, to record upstream bugs and descriptions, etc.?
<pitti> MacSlow: and please put the source.changes there, too (rebuilding locally now, so don't worry for now)
<MacSlow> pitti, oh... sorry didn't knew about the comments
<MacSlow> pitti, I only knew about stating the LP-bug entry in the changelog
<seb128> hate cupsys and apparmor
<pitti> MacSlow: no need to be sorry, it's a relatively new thing
<pitti> MacSlow: that's why I'm pointing it out, we want to try to establish it a bit
<pitti> seb128: --verbose?
<seb128> pitti: still the broken update for a week, I didn't take time to investigate but it's getting annoying
<seb128> Loading AppArmor module: Failed.
<seb128> invoke-rc.d: initscript apparmor, action "force-reload" failed.
<seb128> so cupsys can't be configured
<MacSlow> pitti, so the suggested comments in the patch itself is newer than the (LP: #12346)-thing?
<pitti> ugh, I thought apparmor was working again on current kernels?
<pitti> MacSlow: yes, much newer
<pitti> MacSlow: in the desktop team we want to add some metadata to patches to record description, whether it's ubuntu specific, and various bug tracker links
<pitti> MacSlow: g-c-c> any particular reason why you hcanged the function names?
<pitti> MacSlow: wouldn't it be enough to just change the called programs?
<MacSlow> pitti, I like consistency and predictability
<pitti> ok
<MacSlow> pitti, and since it's not a public API-call I felt save changing it
<MacSlow> pitti, thanks for the uploads!
<geser> good morning
<lool> persia: I tried to clarify the "situation" with UME-handled packages in #188130; I'm around to chat about them if you need further clarifications
<pitti> MacSlow: you're welcome *hug*
<pitti> hi geser
<pitti> StevenK: hah, nice patch!
<pitti> StevenK: I take it you verified that using the same pointer doesn't lead to double-free() or other crashes when the session terminates?
<pitti> StevenK: I wait with the promotion until it gets built everywhere
<geser> Hi pitti
<seb128> StevenK: could you look at the gimp update sponsor request? getting the new version before the freeze would be nice
<StevenK> pitti: I've found where it disconnects. It doesn't free them, it calls dbus_bus_release_name() -- as long as that copes, I think it should be fine.
<StevenK> seb128: Yeah, in a little while.
<seb128> thanks
 * StevenK runs off to buy part of dinner.
<simira> can someone fix the locobot?
<cjwatson> slytherin: ok, I'm sure it's my fault, I'll look at it shortly
<Hobbsee> soren: no, it's really monday.
<Hobbsee> Mithrandir: do they do those drips now?  that'd be nice!
<simira> Hobbsee: he's in transit I believe
<Hobbsee> oh.
<Hobbsee> yay for backscroll, and irc proxies
<simira> he's on in a few mins
<simira> :)
<Hobbsee> just demand he comes on now :P
<simira> I don't need him, I'm in class :)
<Hobbsee> simira: i thought you were supposed to listen in class?
<Hobbsee> and not be on irc?  :)
<Hobbsee> that being said, i've been on irc during uni too.
<simira> Hobbsee: yes, when my french lecturer learns Norwegian properly, maybe...
<Hobbsee> oh, this is *still* the french lecturer?
<Hobbsee> sheesh, how long is he giving a lecture for?
<simira> yes, we mostly got only him :p
<simira> four hours today
<simira> five yesterday, and three tomorrow, I believe
<Hobbsee> ew.
<simira> mm
<Hobbsee> what's he attempting to teach?
<simira> a norwegian standardization system for archive management for official purposes
<simira> pretty much like ISO 15489, just made and adjusted to Norwegian standards
<simira> lucky for me, it's very easy to understand from an IT/developer perspective
 * mpt orders a copy of ISO 15489 to keep on his bedside table
<simira> mpt: you'd need a bad French lecturer to have any use of it. The standardization itself is somewhat interesting
<simira> (if you are interested in archive managment, that is)
<pitti> yay, seems I sufficiently convinced usplash to do what I want it to do \o/
<pitti> sane fsck integration into usplash!
<TheMuso> pitti: DO those recent usplash changes affect themes at all?
<pitti> with pressing Esc to skip routine checks
<TheMuso> pitti: ooooo shiny!
<mpt> pitti, cool
<pitti> TheMuso: no, they don't; I just fixed the input handling
<mpt> !
<TheMuso> pitti: Right.
<pitti> I currently hijack the progress bar to show the fsck progress
<pitti> which means that it'll jump around a little
<pitti> (i. e. used for init script progress, then fsck progress, then again init script progress
<pitti> I'd like to use a different colour for fsck, but usplash currently doesn't allow that
<TheMuso> Better than nothing.
<pitti> it's probably good enough for a first upload
<mpt> hrm
<pitti> mpt: WDYT? should I use the progress bar or output some text
<cjwatson> pitti: ooh, congratulations
<pitti> (like percentage)
<cjwatson> pitti: which fsck backends does it support?
<pitti> cjwatson: only ext3 actually provides progress reading
<mpt> pitti, how soon in the progress bar do/can you find out that you need to do fsck?
<pitti> I'll check it in a bit how it looks with reiser and xfs
<pitti> rcS.d/S30checkfs.sh
<pitti> should be fairly early
<pitti> I didn't run a complete boot yet
<cjwatson> but only when fsck actually starts
<mpt> pitti, I mean, do you know that you'll have to do a fsck before the progress bar begins?
<pitti> I just start usplash and checkfs. manually
<pitti> right, what cjwatson said
<pitti> mpt: let me test this with a real boot and come back to describe how it looks like in the entire boot sequence
<mpt> ok
<slytherin> cjwatson: thanks for looking into it. :-)
<gaspa> pitti: next step is a kernel ooops... i want to see it in a usplash screen... :D :D
<pitti> heh
<Mithrandir> Hobbsee: I'm sure you could get one if you paid enough..
<pitti> mpt: so, it actually looks a bit ugly
<mpt> pitti, my usual suggestion is to retain one progress bar for overall progress of the task (in this case, starting up), and using text for subtasks
<pitti> init script progress starts from 0 to 30%, then checkfs kicks in and does 0 to 100, then init script continues from 30 to 100
<mpt> So it's ok if the progress bar gets stuck for a few minutes, as long as there's a line of text changing regularly underneath
<pitti> mpt: ok, I I should rather output the percentage?
<mpt> where "regularly" > 1/second
<mpt> pitti, is there anything more fine-grained you can report than the percentage?
<Hobbsee> simira: fun
<mpt> For a large disk, a single percentage could take many seconds
<pitti> mpt: fsck has 5 stages, and reports a percentage for each of the stages
<pitti> but they are fairly meaningless
<mpt> Is there a MB measurement, for example?
<mpt> or disk blocks, or something?
<pitti> no
<pitti> well, blocks maybe
<pitti> it outputs some numbers 'cur' and 'max'
<Hobbsee> Mithrandir: heh
<mpt> pitti, do they represent a fraction?
<mpt> i.e. progress = cur/max?
<pitti> I can output the numbers (stage X/5, cur, max) directly instead of percentages
<pitti> mpt: yes
<pitti> mpt: that's the percentage withing a stage
<mpt> and max > 100?
<pitti> for a small disk, max < 100
<mpt> hrm
<pitti> for a large one I suppose it's much bigger
<pitti> I have a 6 GB test partition, where it's 94
<mpt> How long does it take overall?
<mpt> actually, sorry, wrong question
<mpt> How long does the slowest stage take?
<mpt> for that 6 GB
<pitti> oh, stage 1: 46 (70% of time), stage 2: 473 (20% of time), stages 3 to 5 are very quick
<mpt> 473 seconds?
<pitti> no, that's the 'max' number reported
<mpt> oh
<pitti> an absolute number of files or blocks to check, or so
<mpt> a different number for each stage
<pitti> I have a conversion function which accumulates stage, cur, and max to a single percentage
<pitti> (adapted from fsck.ext3)
<mpt> The reason I'm asking this, is that it's good for the text to update at least every couple of seconds
<mpt> so that it never looks frozen
<mpt> As a (very) last resort we could include the time elapsed, I'm just trying to work out whether that's necessary
<pitti> mpt: what about including all?
<Mithrandir> mpt: you don't have any meaningful output that changes every couple of seconds by default, at least.
<pitti> Checking disc..... 23% (stage 1, 234/437)
<Mithrandir> well, maybe on a 6G disk, but not on a 1TB disk or thereabouts.
<mpt> Mithrandir, "by default" as in the existing text display?
<Mithrandir> mpt: yes.  You have a text throbber and a progress bar.
<mpt> yes, I'm familiar with it
<mpt> but not familiar with how bad it gets on huge disks
<mpt> s/bad/sullen/
<pitti> (I currently mimic that text mode progress bar behaviour in usplash)
<Mithrandir> it just throbs slower.
<pitti> I think the numbers (cur/max) will get higher, so I could output those
<pitti> fsck seems to update progress several times a second
<mpt> What makes it spin the throbber?
<pitti> mpt: the text mode has a certain threshold for the percentage
<mpt> I mean, what has it finished when it rotates one segment
<pitti> e. g. if one "=" represents 2.3%, it updates the progress bar every 2.3%
<pitti> oh, it has that rotating thingy, too
<Mithrandir> pitti: "throbber". :-)
<pitti> Mithrandir: I think I just learned a new word :)
<mpt> So, if we can assume that (a) fsck will usually take more than a couple of minutes, and (b) for most disks max > 100, then I think it's better to show cur & max
<pitti> mpt: maybe the percentage in addition, to give a feeling for an ETA?
<mpt> throbber, I think comes from Netscape 1.1, where it actually throbbed
<pitti> since stage 1 takes 70% and stages 2 to 5 together 30%, it would look less intimidating
<mpt> pitti, you're right
<pitti> mpt: WDYT about "23% (stage 1/5, block 234/437)"
<mpt> Your suggestion above is perfect
<mpt> except three dots, not five :-)
<Mithrandir> pitti: where do you get the cur and max numbers from?
<pitti> sure :)
<pitti> Mithrandir: fsck -C
<pitti> Mithrandir: rather, -C3
<pitti> (output progress to fd 3)
<pitti> -C == -C0 is magic, it uses the text mode progress bar
<pitti> but for an fd you get three numbers (stage cur max) per line
<pitti> one line for each cur
<Mithrandir> ah
<mpt> http://en.wikipedia.org/wiki/Throbber
<Mithrandir> max for a 2.6T volume is ~21k, so a percentage would be good
<persia> lool: Thanks for the clarification on MIC.  Sounds like a bit of a mess.  I'd like to wait to hear back from smagaoun about it, but will push pre-FF if nobody else hits it.
<Hobbsee> persia: see my comment in -motu
<persia> Longer term, I'd think setting maintainer to UME, and granting UME access to the VCS might be a sensible solution, to avoid tracking multiple debian/ directories.  Alternately, one of the two repos can be the master, and the other can merge/sync as Ubuntu does with Debian.
<cjwatson> slytherin: OK, I see the problem - the code that generates the "master task" for cdimage doesn't cope with following more than one level of seed dependencies
<persia> Hobbsee: I refuse to accept anything as "crack" that can be fixed.  Mortar is cheap :p
<cjwatson> slytherin: the upshot being that required, minimal, standard, and desktop-common go missing
<slytherin> cjwatson: That is almost everything one would need to use Ubuntu. ;-)
<slytherin> desktop I mean.
<lool> persia: Thanks
<persia> lool: On an extended note, aside from other things, doesn't it make sense for someone in UME to be sponsoring UME stuff, rather that UUS?  My comfort level for uploads when wearing a UUS hat goes down significantly when the resulting maintainer is not MOTU.
<lool> persia: There are little uploaders for UME at the moment; most people aren't MOTU and we only have a couple of core dev while the packages are being promoted to main
<persia> lool: Makes sense.  I remember when myth was that way.  UUS works until it gets resolved (although it may soon require UMS)
<lool> persia: While folks started the MOTU process and will probably be core dev in the next weeks or months when they will have demoed some experience, I fear it would be too hard to sponsor everything internally ATM
<Hobbsee> persia: sure, but sanity is not.
<TheMuso> Hrm. Is it known that one doesn't get a /dev/cdrom symlink in /dev?
<TheMuso> Running latest updates, from my local mirror.
<sucotronic> hello everybody
<sucotronic> one question
<sucotronic> How often the maintainers checks the original projects for new releases?
<cjwatson> sucotronic: "from time to time"
<sucotronic> mmm
<cjwatson> some maintainers are subscribed to announcement lists and see them immediately; some just check every so often; some only update when prodded
<sucotronic> there isn't any mechanism to notify maintainers?
<sucotronic> or is more easy to become a maintainer?
<cjwatson> sucotronic: subscribing to upstream announcement lists is the preferred mechanism for diligent maintainers, though they can also create a debian/watch file and use uscan --report --verbose regularly
<sucotronic> then, I've to contact with the maintainer to ask him?
<cjwatson> sucotronic: filing a bug would be the usual method
<sucotronic> cjwatson: sorry, I'm new. How I can do it?
<cjwatson> sucotronic: https://bugs.launchpad.net/ubuntu/+filebug; also read https://wiki.ubuntu.com/ContributeToUbuntu
<cjwatson> sucotronic: please ask further support questions in #ubuntu
<sucotronic> cjwatson: thank you a lot
<Mez> hmm, does anyone know anyone here who works for yahoo ?
<sucotronic> cjwatson: I think you are wrong. I don't want to report a bug. I'm a maintanier of a project, and I only want to know how to notificate the ubuntu maintainer the new releases
<persia> sucotronic: A bug of the form "Please upgrade to new upstream release X.Y" is the preferred format if you want to push changes, rather than waiting for a pull.
<sucotronic> persia: ok, that's what I want to know. Thanks
<DarkSun88> Hi all
<cjwatson> slytherin: Ubuntu daily CD builds fixed now
<slytherin> cjwatson: Thanks. Does that mean that new images will be generated again?
<cjwatson> slytherin: I just generated Ubuntu ones
<cjwatson> and am building Kubuntu now
<slytherin> cjwatson: kudos to you. :-)
<slytherin> Any of the buildd admins present here? I have a debconf preseed request.
<cjwatson> I thought that particular preseed had been done
<slytherin> cjwatson: which one? I am referring to batik build, it uses older j2sdk because Sun JDK is too new for it.
<cjwatson> slytherin: the RT ticket was marked resolved on 12 Dec; I'll see if I can dig up exactly what was preseeded
<slytherin> cjwatson: AFAIK, only Sun java packages have been preseeded.
<geser> cjwatson: sun-java-* works on the buildds after the preseeding was done (at least in hardy)
<slytherin> and what we need is preseeding for j2sdk/j2re package (Blackdown JDK/JRE). This is needed for some packages.
<cjwatson> shared/accepted-sun-dlj-v1-1 is preseeded, but nothing else seems to be
<cjwatson> slytherin: mail rt@admin.canonical.com with your request
<pitti> cjwatson: do you know if there will be any problems if I add a "Breaks: usplash (<< 0.5.12)" to initscripts? (which is a required package)
<pitti> cjwatson: I need the new usplash features for the fsck integration
<cjwatson> pitti: don't think so
<pitti> ok, thanks
<slytherin> cjwatson: Difficult task if you ask me. Access to my primary mail account (gmail) is blocked for me. I will see what I can do. :-)
<cjwatson> slytherin: (or ask somebody else to do so) and say exactly which debconf question you need preseeded
<slytherin> cjwatson: How do I identify debconf question?
<cjwatson> slytherin: you'll need to read the maintainer scripts and figure out what they're doing
<slytherin> ok
<slytherin> cjwatson: Looks like there are two different debconf questions, one for sdk and one for runtime. 'j2re1.4/license: true' and 'j2sdk1.4/license: true'
<StevenK> pitti: libosso built everywhere - do you need to wait for the publisher to finish, or can you promote it while it's running?
<pitti> StevenK: if it's uploaded, I can promote it
<Hobbsee> pitti: bad idea.
<pitti> ?
<Hobbsee> pitti: you need to wait for it to finish building, else it gets a "failed to upload" status.  iz YALPB.
<Mithrandir> Hobbsee: but it's shiny!
 * Hobbsee takes the shiny away from Mithrandir
<pitti> Hobbsee: "if it's uploaded..."
<Hobbsee> NO MORE SHINY FOR YOU!  NOT YOURS!
<Hobbsee> pitti: i thought you meant source uploaded
<Mithrandir> :'-(
<pitti> no, I meant the binary builds were uploaded
<Hobbsee> oh right.   go ahead, then :)
 * Hobbsee hugs Mithrandir
<pitti> anyway, I'm finally off for lunch for a bit; I'll review/promote it once I'm back
 * Hobbsee blinks
<Hobbsee> so, uh...
<Hobbsee> either iv'e forgotten how to use powerpoints, or thsi cable has just died on me.
<Hobbsee> or only works sometimes
<Mithrandir> Hobbsee: it's probably to wear down your nerves.
<Hobbsee> Mithrandir: it was working fine prior to this.  but now that i'm going on holidays, where it'll be my only phone, it does this.  grrr.
<saispo> BenC: ping ?
<BenC> saispo: ?
<saispo> BenC: hi :) i have a little question about git kernel ubuntu, i see on list *changes that kernel 2.6.20 and 2.6.22 are fixed but nothing in gitweb, it's normal ?
<BenC> saispo: what do you mean "fixed"?
<saispo> about CVE-2008-0600.
<ubotu> ** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem.  When the candidate has been publicized, the details for this candidate will be provided. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0600)
 * pitti promotes libosso and osso-gwconnect to main and waves to StevenK
<Riddell> DarkSun88: are you going to rebulid all the libglew rdepends?
<DarkSun88> Yes. Are there problems?
<Riddell> DarkSun88: no, just confirming it's in your sights, I've let it through New
<Riddell> DarkSun88: also I've uploaded a new koffice2 so you can ignore krita-kde4
<DarkSun88> Well, thanks. :)
<saispo> BenC: changes haven't been commited in git ?
<BenC> saispo: I'm sure they have, but maybe they weren't pushed...I can check
<saispo> ok, thanks :) because i must rebuild them
<saispo> and i use git for doing this
<saispo> BenC: thanks, good for gutsy :)
<saispo> waiting feisty :)
<dramen> hello
<dramen> how can i install a manpage when i build a (debian)package by using dpkg-buildpackage
<ion_> See dh_installman(1)
<persia> dramen: You likely want to ask that question in #ubuntu-motu, and read the dh_installman manual page
<dramen> in debian/rules there is a call dh_installman
<dramen> normally, it should install the manual page automatically on the right location
<cjwatson> as dh_installman's own manual page says, you have to tell it which manual pages to install, either with debian/manpages (or debian/PACKAGENAME.manpages) or with command-line arguments
<dramen> ok, i just put the deprecated dh_installmanpages into my debian/rules-file and now it works
<dramen> although, the output is as followed: "dh_installmanpages: This program is deprecated, switch to dh_installman."
<pitti> cjwatson: ooh! ubuntu-meta with reorganized seeds?
<cjwatson> dramen: dh_installmanpages has a different interface, which includes automatically searching for manual pages. In practice this turned out to be more trouble than it was worth.
<cjwatson> pitti: yes
<seb128> ogra: will you look at ted's gnome-screensaver updates, the bug is assigned to you, or should I do it?
<seb128> soren: could you look at the gtk-vnc update sponsor request? it should be easy and required by the new GNOME
<soren> seb128: It's on my list.
<soren> :)
<lool> Hmm today's Tech Board meeting doesn't appear on the fridge which is the official place to list tech board meetings (says the wiki); who should I ping to get this fixed?  Tech board folks to ask fridge people or fridge people directly?
<xivulon> hi heno
<persia> lool: Mail to fridge-devel@
<heno> hey xivulon!
<persia> More generally, TB should send such a mail when a meeting date is decided.
<heno> xivulon: that last version looks nice :)
<Keybuk> lool: fridge *still* can't do recurring meetings
<Keybuk> so they have to add them one by one by hand
<saispo> seb128: \o/
<seb128> saispo: what?
 * lool mailed fridge-devel
<Keybuk> and occasionally we hit the horizon of Corey's boredom of typing the same meeting in
<saispo> seb128: nothing, just say "hello" :)
<seb128> hey saispo ;-)
<xivulon> heno: glad to hear that
<xivulon> heno re skinning, I should be made the labels and buttons solid color and/or transparent
<xivulon> at the moment the image is 314x164
<xivulon> assumes white background
<xivulon> 164x314
<heno> xivulon: can the buttons be made transparent?
<xivulon> heno: never tried that
<ogra> seb128, hmm, i'm pretty packed atm if you have a spare cycle for that it would be great
<xivulon> should be possible though
<seb128> ogra: ok, will look at it, thanks
<heno> xivulon: ok, grey will be fine as well
<ogra> thanks a lot
<heno> having a pixmap on the entire background would be great
<xivulon> that should be possible too, but haven't played with that either, requires overriding default nsis behaviour (164x314) expected
<xivulon> that said when the image goes below text readibility is affected
<xivulon> I think that a 3Dish logo with shadow on white background might be good enough
<heno> I agree
<xivulon> if they can keep it within the above size much easier for me
<heno> It's just useful to know what the technical constraints are when talking to the art team
<xivulon> that can be branded (at compile time though)
<heno> let's start with that then
<xivulon> I mean I can always override the nsis behaviour here and there, but I have the schedule quite busy before friday already
<xivulon> translation I think is a more urgent issue
<xivulon> I can reuse wubi scripts (po <-> nsh) or win32loader approach (c dll + gettext)
<xivulon> the transparency by the way depends on mfc api, if it is supported by standard flags or via sendmessage then it can be done
<heno> xivulon: NSIS gets the locale from Windows?
<xivulon> if not it requires a separate dll which is not worth it IMO
<xivulon> yes
<xivulon> uses the default windows language
<heno> cool
<xivulon> but at the moment I only have english in there anyway
<heno> I think the text is ok for translation now (though I'd like to see even less of it :) )
<xivulon> if there are mfc gui experts here, tips are welcome :P
<xivulon> easiest way for me is if you change the text in the wiki
<xivulon> I'll grab it from there
<heno> OK, I'll try condensing it some more if possible
<xivulon> I'll upload the code tonight, building it should be quite straightforward, you need wine+nsis2.34
<xivulon> heno: quick googling shows that transparent buttons are not obvious, transparent labels should be ok
<heno> that would be great
<xivulon> eh did not look at what is required to enlarge the image though
<xivulon> heno: http://img444.imageshack.us/img444/9167/umenu1wy6.jpg
<xivulon> this is to show transparency capabilities
<xivulon> I think it looks better on the side though
<heno> xivulon: right, but we wouldn't use that image in that case. most likely the image would have the logo on the left and a faint texture on the right
<heno> xivulon: what's the image dimension on that one?
<xivulon> I appreciate that, note that the same image would probably also go in the reboot page
<heno> right
<xivulon> heno that is a bit tricky, since the size changes slightly with font sizes (the image can be stretched or we can end off into a background color)
<\sh> soren, ping dpkg-dev...as I don't like to fight with dpkg, would you like to bring the "Description" tag back to _source.changes files, as described here: http://git.debian.org/?p=dpkg/dpkg.git;a=blobdiff;f=scripts/dpkg-genchanges.pl;h=0fcd529b847c5f51f7f4c5e3ea8c51e186d3730d;hp=7dada21a531c568298764c76dbe9a44b56471101;hb=15fa75bd7143d6ec54f0a77c482ff0cfb72bf440;hpb=1f6feb233d4e7088cb920f386292f8d31d694d3a ?
<soren> \sh: File a bug.
<\sh> soren, right now, this field is policy and MIA in last dpkg from debian/ubuntu :)
<\sh> soren, ah well, I'll provide a debdiff
<soren> Cool, thanks.
<\sh> soren, np
<xivulon> heno the nsis recommended size for a vertical image is 164x314, for a full image 496x314
<xivulon> heno: checkboxes are like buttons, so cannot be transparent
<xivulon> that basically rules out a full size image
<heno> xivulon: ok (you mean for the radio buttons on the reboot page?)
<xivulon> yes
<xivulon> they will have a solid background
<heno> btw, is there any limitation on colour depth?
<xivulon> It has to be a bitmap not sure what depth is supported, but I that depends on windows defaults
<xivulon> heno: http://img166.imageshack.us/img166/1228/umenu2zo3.jpg
<xivulon> IMO Simplest option is to have a vertical image (164x314) with 3Dish logo + shadow, all with a white background.
<heno> xivulon: agree. I'll look at making one (and ask for some art help if I fail)
<heno> thanks for investigating
<xivulon> np
<neighborlee> so is hardy close'ish to average user ready , from what I read about current status it would seem so  :)
<jpatrick> neighborlee: feature freeze soon
<neighborlee> ohhhhh btw
<neighborlee> what was the decision on mono
<neighborlee> jpatrick, sounds nice :)
<persia> neighborlee: The (nearly) final set of upstreams should be determined this week, but there are still lots of bugs that need closing.  Testing appreciated, but know that you're testing.
<neighborlee> persia, yes
<neighborlee> persia, current issues seemed doable ;)
<neighborlee> persia, what is the status of mono in hardy or is it already gone ;)
<neighborlee>  I saw wiki and  was wondering
<persia> neighborlee: You'll get a better answer from the daily CDs or the metapackages than from me (I don't know, except that there are at least mono packages in universe)
<neighborlee> yes that wont change from what I read
<neighborlee> just  wont be installed out of box or on install CD
<neighborlee> persia, daily cd ??
<LaserJock> I can't imagine mono being gone, we have f-spot and tomboy using it
<neighborlee> persia, surely someone knows
<neighborlee> :))
<neighborlee> LaserJock, you dont know about the  wiki do you ;)
<persia> neighborlee: Check the hardy ubuntu-desktop package
<LaserJock> neighborlee: I know there is a lot of stuff on the wiki, much of it has no baring on what's actually done
<neighborlee> persia, ok fine I was hoping someone would just know what status was ;))
<neighborlee> LaserJock, ok, odd.
<LaserJock> *bearing, methinks
<LaserJock> neighborlee: why is that odd? The wiki is open to editing by anyone
<neighborlee> well the idea is the remove mono entirely, but leave on repo at least
<neighborlee> LaserJock, I assumed it was a serious issue r aised by a developer, but maybe not.
<mjg59> No
<neighborlee> LaserJock, it looked very serious to me.
<mjg59> Mono's not being removed
<neighborlee> mjg59, ok ..as I say the wiki looked done very professsionally so I had zero reason to think anything less
<LaserJock> neighborlee: well, I'm sure the person who wrote it  was serious, but if it's the wiki page I'm thinking of it was not by a developer
<mjg59> Someone's written a spec about it. The spec hasn't been approved.
<neighborlee> ic alright
<mjg59> You can see that by following the link from the spec to the status page on Launchpad
<neighborlee> ic
<neighborlee> well it did makes alot of sense though if you think about it
<neighborlee> MUCH less MB footprint  ,  memory too ?..and there are valid  replacements to all apps according to the wiki author anyway
<neighborlee> anyway I was curious, as on the outset it sounded very logical.
<neighborlee> and now with winforms being deprecated for avalon it does beg the question possibly ;)
<mjg59> There's no decent replacement for Tomboy
<neighborlee> yes actually there is, at least according to the wiki author
<neighborlee> offhand I dont recall.
<mjg59> He's wrong
<neighborlee> but I think there was some feature the repalcement didn't have.
<neighborlee> but I now he mentioned something
<neighborlee> ..know
<neighborlee> checking
<neighborlee> and what about tracker..it replaced beagle :)..makes you wonder at least it does me.
<neighborlee> hm lets see
<neighborlee> found it
<neighborlee> ok this is on forum however
 * persia notes bug #190862 may be interesting in any discussion of tomboy
<ubotu> Launchpad bug 190862 in tomboy "License headers missing" [High,Confirmed] https://launchpad.net/bugs/190862
<neighborlee> oh gawd clealry this is a HUGE issue for those involved in the discussions..a sorta 'heated' debate it looks like.
<neighborlee> persia, hmm
<neighborlee> license headers oh thats inntersting ;)
<LaserJock> neighborlee: yes, because almost are all arguments are a technical "smoke and mirrors" around "we don't want it"
<neighborlee> hm
<mjg59> persia: Unless there's any reason to think otherwise, the presence of a global copyright file is generally sufficient
 * mjg59 heads out
<xivulon> heno: once you get the artwork for umenu could you please also produce a set of images of size 150x57 to be used in wubi header?
<xivulon> ideally there should be one for each flavor covered by wubi
<xivulon> mjg59, there used to be some code in powermanagement-interface/pmi.acpi to disable suspend (ram/disk) for loopinstallations
<xivulon> that for some reason did not go through to pm-utils
<xivulon> would it be possible to add it back? grep host in pmi.acpi
<xivulon> ah missed the heads out part...
<pranith> is there any update for the vmsplice exploit for ubuntu yet?
<sistpoty|work> pranith: yes
<pranith> i did apt-get upgrade today, and no new kernel...
<sistpoty|work> pranith: at least I've seen a new kernel from security today
<pranith> hmm
<pranith> ok
<sistpoty|work> pranith: arrived not too long ago
<jdong> it was put in git like 23hrs ago
<jdong> http://www.ubuntu.com/usn/usn-577-1
<pranith> ok, thanks
<jdong> update released on all supported versions of Ubuntu :)
<geser> slangasek: the last comment in bug #187890 says that the package got synced but the archive has still the old version. A bug in a script not catching an error?
<ubotu> Launchpad bug 187890 in onscripter "Please sync onscripter 0.0.20080121-1 (universe) from Debian unstable (main)" [Wishlist,Fix released] https://launchpad.net/bugs/187890
<\sh> soren, would you like to take a look at bug #191324 and upload please, so linda and everyone else is satisfied again using dpkg-genchanges.pl ? :)
<ubotu> Launchpad bug 191324 in dpkg "dpkg-genchanges.pl missing the "Description" field in *_source.changes files" [Undecided,New] https://launchpad.net/bugs/191324
<\sh> soren, I just tested it , and everything is fine again and following debian policy
<sistpoty|work> \sh: revu is already fixed *g*, and sparky's linda as well *g*
<slangasek> geser: mmm, could be.  the sync-source script apparently exits with success when you fail to ask it to override the Ubuntu changes, and so pitti's most recent wrapper script sends some false-acks :/
<\sh> sistpoty|work, well, if dpkg is fixed, you can drop the workaround ,-)
<slangasek> Riddell: I guess you have the sync lock right now, could you add 187890 to your queue?
<persia> geser: There's an issue with package versions that small.  I had to manually force a couple packages earlier in the cycle
<\sh> sistpoty|work, but I'm uploading my package again, ok?
<persia> infon 0~r144-1 and infon-devel 0=r198-2.1
<sistpoty|work> \sh: I'd rather not drop the workaround... revu shouldn't throw backtraces because of a missing entry in the changes file (of course I should really fix much more for that *g*)
<Riddell> slangasek: ok
<sistpoty|work> \sh: sure (btw.: I put back your last upload)
<sistpoty|work> \sh: so that's up there already
<\sh> sistpoty|work, so it's already on the list, cool :)
<Riddell> slangasek: that can't be synced, it has a smaller version number than the current version we have
<slangasek> Riddell: oh, that's also a good reason for not syncing then
<geser> slangasek: so we need to add an epoch to onscripter?
<slangasek> geser: to be syncable again, yes
<jaalto> Where can I find step by step instructions how to make a release and upload files to it in launcpad. I have forgotten the details
<slangasek> geser: or else drop the leading zeroes, and worry about epoching later?
<ScottK> Debian would need to add the epoch, right?
<slangasek> epoch, or drop the leading zeroes
<geser> ScottK: if we don't want to carry it forever, yes
<geser> slangasek: wouldn't dropping the zeroes also require to rename the orig.tar.gz?
 * ScottK was thinking if we wanted to be able to sync it.  Once you add an epoch for Ubuntu, you aren't syncing any more.
<slangasek> geser: well, yes - why would that hurt anything?
<geser> slangasek: not really
<slangasek> ScottK: we already can't sync it because the current Ubuntu versioning sorts greater than the Debian versioning
<ScottK> Right, but us adding an epoch doesn't help that.
<geser> ScottK: how does dropping the zeros help us?
 * ScottK didn't say it does.
<slangasek> ScottK: sorry, I read "we need to add an epoch to onscripter" as "we need to get the Debian maintainer to add an epoch to onscripter" :)
<ScottK> Ah.  Maybe that's what he meant and I'm to much of a literalist.  Dunno.
 * geser will upload onscripter without the leading zeroes
<slangasek> geser: upload it to Debian?
<geser> slangasek: to Ubuntu :)
<geser> as a fake-sync
<slangasek> oh, gotcha
<geser> what's the correct version in this case? -1build1 as there is no real change or is it -1ubuntu1 due to the changed versioning?
<xivulon> slangasek, is it possible to agree on metalink urls, even without dealing with generating the metalinks? I need to hardcode those in wubi.
<xivulon> otherwise I will need to make amendments post feature freeze
<persia> geser: Maybe -0ubuntu1 because of the changed versioning?
<geser> that's also an option
<xivulon> only need to know where the metalinks will be, and convention for filename therein (relevant before final release), we can use static metalinks for the time being pointing at daily-builds
<xivulon> slangsek: something like: ubuntu.com/metalinks/ubuntu-8.04-desktop.metalink -> ubuntu-8.04-desktop.iso (filename)
<slangasek> xivulon: let me see about working through that over the next few hours.  Any new URLs under ubuntu.com need to be discussed with the webmaster first
<xivulon> slangasek, keep in mind that 1: the metalink url should not change over time within a release cycle, 2: the filename within it may or may not change
<xivulon> to make clear the second point, assume the metalink is called ubuntu-8.04-desktop.metalink, that will now point to urls that will retrieve the file hardy-desktop.iso
<xivulon> on top it contains a filename property (which most downloaders use to rename the downloaded file). That can be hardy-desktop.iso or ubuntu-8.04-desktop.iso
<ScottK> Riddell: Could I please have a give back on testresources.  I believe it'll build this time.
<xivulon> I'd opt for the second option
<Riddell> ScottK: not from me
<Riddell> ScottK: try slangasek
<ScottK> OK.  Riddell: who from then?
<ScottK> K
<ScottK> slangasek: Would you please give back testresources.  I'm reasonably certain it will build.
<geser> ScottK: ask pitti, Mithrandir or lamont for a give-back
<geser> ScottK: you need an build admin not an archive admin
<ScottK> Ah.
<ScottK> Thanks.
<lamont> geser: s/lamont/infinity/
 * ScottK hopes one of them see that then.
<slangasek> ScottK: not me either, I'm not a buildd admin
<ScottK> Right.
<geser> lamont: aren't you a buildd admin anymore or do you simple don't handel give-back requests?
<lamont> geser: well.....
<geser> ScottK: Hobbsee can also do give-backs, but that doesn't help you right now
<lamont> I'm an lp-admin now, so I can certainly do it.
 * ScottK would need her long stick to reach out and wake her up.
<lamont> I prefer to not abuse the duck that way
<geser> lamont: I looked at https://edge.launchpad.net/~launchpad-buildd-admins/+members and you're still listed so I guessed you could do it
<lamont> yeah.  I should really fire myself from that group, to be proper
<ScottK> lamont: Please give back testresources first.
<lamont> ScottK: dropping myself from the group won't make it so I can't give it back..
<ScottK> True, but if you did it first, it would actually be done.
<lamont> both done
<ScottK> lamont: Thanks.
<slangasek> xivulon: ok, I've given the ubuntu.com webmaster food for thought; there are various concerns about how much of a difference this will make to www.ubuntu.com load at release time and so forth, but we'll work through those and I'll let you know what conclusions we reach.  If this is just a matter of adding the metalink URLs to wubi, though, I wouldn't worry about not having the decision before FF
<bddebian> Oh, who is doing give-backs?  Can someone do lordsawar?
<pitti> bddebian: can do
<pitti> bddebian: people in the ~launchpad-buildd-admin team can
<bddebian> Thx
<pitti> bddebian: nothing to give back, it's built everywhere but hppa (and it's needsbuild there)
<LaserJock> bah
<pitti> hi LaserJock
<LaserJock> pitti: you gotta a sec for a NEW consultation?
<newz2000> xivulon: Hi, I'm the webmaster. I have some questions but I need to do a little investigation in order to speak intelligibly on the matter. Can I e-mail your or /msg you later on this week?
<pitti> actually not, trying to concentrate to get this usplash thing fixed and then go to bed
<LaserJock> pitti: fine
<pitti> LaserJock: but just ask your question,
<bddebian> pitti: Ah, someone must have done it, thanks
<LaserJock> I'm totally switching the packaging for squeak (multiverse smalltalk stuff) so that we're syncing to the official unofficial packages
<pitti> 'official unofficial'? :)
<LaserJock> the source package names are completely different
<pitti> I see
<pitti> so that requires some removals/NEWs
<LaserJock> pitti: Debian won't take it officially, but squeak maintains official packages
<LaserJock> but there is some binary package overlap
<pitti> LaserJock: that's not a problem; just make sure that the versions are higher
<LaserJock> yes, the versions will all be higher
<pitti> and that the packages with the same names have the same purpose :)
<pitti> and keep transitional empty packages until after hardy for upgrades
<LaserJock> ok, so I shouldn't ask for removals?
<pitti> the old source packages should be removed
<pitti> and old libraries, etc.
<LaserJock> k, and have the new packages do the transitionals
<pitti> old application packages should become transitional packages
<LaserJock> ok, how hard would it be to get somebody to remove squeak-image, squeak-sources, and squeak-vm for me? :-)
<pitti> LaserJock: let's first get the new packages in, then remove the old onese
<pitti> LaserJock: it's not hard, just file a bug against them asking for removal and sub ~ubuntu-archive
<LaserJock> sure
 * pitti sighs and goes for another round of reboot/usplash testing; brb
<pitti> 4 usplash uploads in two days...
<LaserJock> fun :/
<ScottK> pitti: If you're going to be around for a bit, you might idle in #ubuntu-meeting and 'fanboy' my core-dev application in person when the time comes (meeting in progress now).
<Mez> Question: with all the idiots trying to get people to sudo rm -rf / - why not create a patch that gives you an "are you sure - are you really sure - are you REALLY REALLY sure" kind of warning?
<persia> Mez: Fails the silent-on-success guideline
<LjL> Mez: as in, putting an alias by default in ~/.bashrc for --preserve-root?
<ScottK> bddebian: Testresources FTBFS again.  It's your fix, so have fun.
<ScottK> ;-)
<Mez> LjL, something like that
<Mez> LjL, actually, thats not a half bad idea
<Mez> Anyone willing to sponsor a patch for that
<LjL> Mez: not sure. guidelines aside, people would probably starting to give "alternative commands" to bypass that check
<Mez> LjL, it's built into rm, so wouldnt fail the guidelines
<infinity> Mez: Preventing users from shooting themselves in the foot with cute aliases and such never works.
<Mez> infinity, wow - havent seen you in ages
<Mez> how're things
<infinity> Decent, I just don't speak up in -devel much anymore
<Mez> I've actually looked for you specifically on a couple of occasions infinity ;)
<Mez> cant remember why now
<Mez> prob something to do with Debian and NM
<slangasek> or turtles
<infinity> Mez: (Note that we could just change it to "rm -rf /*" etc... If people will run random commands like that, they'll always get what's coming to them)
<infinity> slangasek: *glare*
<slangasek> :-)
<Mez> infinity, ;)
<Mez> slangasek, do I want to know
<slangasek> yes, but I won't tell you
<Mez> ?@
<xivulon> slangasek: thanks, yes for the time being it's mostly a matter of URL only I can point to my website for the time being and repoint later.
<xivulon> Note that if the "filename" attribute within the metalink is not constant throughout a release cycle, I will also need to recode a bit.
<slangasek> xivulon: right.  I'm not sure what the best solution is for that side of things; everywhere else, we make a point to distinguish between pre-release codenames, and release versions
<xivulon> slangsek, if you keep the metalink url fixed, either way is wrong
<xivulon> slangasek: ^
<slangasek> precisely
<xivulon> i.e. you either have a ubuntu-8.04-desktop.metalink pointing at hardy-8.04-destop.iso or you have ubuntu-8.04-desktop.metalink which downloads hardy-desktop-iso and calls it ubuntu-8.04-desktop.iso
<slangasek> xivulon: yes, it's also wrong because we don't want to have /metalink/ files labelled "hardy" after release, or labelled "8.04" before release
<xivulon> an alternive is to use server side redirection
<xivulon> so I can point to ubuntu-8.04-desktop.metalink.latest
<xivulon> which will redirect me to either ubuntu-8.04-desktop.metalink or ubuntu-8.04-alpha3-desktop.metalink
<xivulon> the metalink file itself by the way should be lighter than an average webpage if you are concerned about bandwidth
<slangasek> xivulon: what about if the installer were to look for a file under the release number, and fall back to the codename if it's not available?
<xivulon> I can do that but will hardcode some ubuntu specific practices
<slangasek> that would also give us the option of hosting them in two different places (i.e., releases.u.c, cdimage.u.c, which is how the images are split as well)
<xivulon> I was thinking somthing like:
<xivulon> ubuntu.com/metalinks/8.04 with subdirs: final, beta, alph3, current
<xivulon> current contains "fixed" urls which are redirected
<slangasek> the subdirs seem unnecessary, since we don't generally keep previous milestone images around after the next one has been released
<xivulon> agree, on top of that server side redirection do not require files visible to the user
<xivulon> so it would be ubuntu.com/metalinks/8.04 containing ubuntu-8.04-desktop.metalink OR ubuntu-8.04beta-desktop.metalink + ubuntu-8.04-desktop.current.metalink redirection
<xivulon> the last one being "invisible"
<xivulon> the filenames therein should match whatever a user would grab manually from the mirrors
<xivulon> would the above seem reasonable?
<slangasek> it still has the flaw that it implies using the "8.04" designation before 8.04 is released
<slangasek> I expect newz2000 will have some opinions on the layout
<Mithrandir> we could use metalinks/NOT-YET-RELEASED/8.04/ or something like that.
<xivulon> could be called hardy-desktop, the issue is that all distros share the same codename so can't have that...
<infinity> We should definitely not use numbers before release.
<xivulon> ubuntu-beta-desktop.metalink ubuntu-finall-desktop.metalink ...?
<xivulon> all in 8.04
<infinity> I still remember the s/6.04/6.06/ pain.
<xivulon> I mean either one or the other
<slangasek> xivulon: I would probably do ubuntu-hardy-desktop-i386.metalink or such; prefixing the distro name to the image name
<slangasek> or else mirroring the per-flavor heirarchy currently present on releases.u.c/cdimage.u.c
<xivulon> slangasek: I really only care about having redirections (.htaccess) which are fixed across a cycle and gets updated
<xivulon> The rest is for "real users" more than programmatic access
<xivulon> provided the redirections get me to the right metalink, I do not really mind what is called
<infinity> What's the actual goal here?
<infinity> A static URL that's always correct?
<xivulon> yes
<slangasek> infinity: giving wubi a static url that can be embedded, yes
<infinity> It's my opinion that having the current alpha turn into the release is very much incorrect.
<infinity> This is one reason why we do the rename on release.
<infinity> ubuntu-hardy-desktop.iso != ubuntu-8.04-desktop.iso, and never should we promote anything that claims otherwise.
<xivulon> don't think there is much confusion there
<slangasek> there isn't *today*, because we make the distinction
<infinity> There would be with a static URL that tracks through to release.
<Mithrandir> any reason wubi can't try two URLs and fall back to the not-yet-released one if the released one doesn't exist?
<Mithrandir> so it'd be embedding two URLs, not just one
<infinity> Having different locations and filenames is a big, blinking warning that you're using unreleased code.
<infinity> Anything that obscures that without warning the user is a no-no to me. :/
<infinity> s/unreleased/unsupported/, if you prefer.
<infinity> (It's obviously all "released")
<xivulon> That is of course not an issue for the stand-alone version, but it is problematic for the version bundled with the CD
<infinity> Why is it an issue?
<slangasek> for the version bundled with the CD, it could read metadata from the CD image itself telling it which url to check...?
<xivulon> I will have to change the embedded urls just before release
<infinity> if (download release.iso) { continue; } else { download beta.iso; warn user that it's beta; }
<xivulon> slangasek: I do parse .disk/info anyway...
<slangasek> xivulon: in that case, you already have the metadata that tells you whether it's released
<xivulon> sorry infinity misunderstood you above, yes I can do 2 urls
<xivulon> slangasek: true.
<xivulon> but...
<xivulon> if a user gets a copy of wubi.exe and pass it to a friend, that becomes stand-alone, and will not "know" what to download
<slangasek> are there identifying version numbers in wubi itself?
<Mithrandir> xivulon: make it look at http://releases.ubuntu.com/.manifest or something then?
<xivulon> Now I use 8.04+bzr revision
<xivulon> But can of course change that
<xivulon> Mithrandir: you mean the wubi name?
<xivulon> ah no
<Mithrandir> xivulon: if you have a standalone .exe, what information does wubi want to collect before it can install?
<xivulon> it needs to know the metalink url
<Mithrandir> it needs to be able to construct the right metalink URL, right?
<xivulon> if the standalone is produced after the ISO ships, that is trivial, but if the standalone is on the CD that is less so
<xivulon> yes
<Mithrandir> it's not needed for wubi from 8.04 to be able to install 8.10?
<xivulon> nope
<slangasek> huh? why does it make a difference when the .exe is built?
<xivulon> slangasek: if I release an exe on my website after ISO release I can embedded the right urls
<slangasek> we will know, a priori, what the urls are for "pre-release" and "release" metalink files, whether these are the same or different
<slangasek> I think we're all agreed that the urls should be *defined* well in advance
<slangasek> it's just that the "release" url shouldn't be *populated* prior to the release
<Mithrandir> they'll just 404 until we actually have released.
<xivulon> slangasek: correct
<slangasek> xivulon: ok, so where's the problem then?
<xivulon> not really a problem, so far there seem to be 2 solutions: I try 2 different urls or we use redirection
<slangasek> ok
<xivulon> just need to knwo which route you guys prefer, for me redirection is less work :P
<cody-somerville> Would someone be so kind to summarize what the problem is? :)
<slangasek> well, yes, but I think the above 800 lines of scrollback make it clear that there's resistance to using a single, user-visible url for pre- and post-release files :)
<xivulon> ah but that will not be user-visible
<cody-somerville> Why would you want that anyhow?
<slangasek> cody-somerville: the subject at hand is wubi using metalink files; I don't know that there is a problem currently
<slangasek> xivulon: uh, it'll be on a website, users can access websites, therefore it's user-visible :-)
<xivulon> in the sense the redirection is serer side (.htaccess) so if you look in the metalinks directory you do not see redirecting urls
<xivulon> of course you can also opt for visible redirections
<slangasek> mm, ok
<xivulon> http://en.wikipedia.org/wiki/Server-side_redirect
<slangasek> eh, "server-side redirect" is a very vague term without any implications of .htaccess or any other mechanism; that was my confusion, citing wikipedia doesn't really help :)
<xivulon> What I mean is that I can type "http://ubuntu.com/metalinks/hidden_latest.metalink" and get "http://ubuntu.com/metalinks/ubuntu-8.04-desktop.metalink"
<xivulon> but if you look in "http://ubuntu.com/metalinks" you only see "ubuntu-8.04-desktop.metalink"
<slangasek> yes.  "server-side redirect" implies the former, it didn't imply the latter.  But I'm on the same page now.
<xivulon> in any case the downloaded metalink (and hence iso filename) would reflect the actual status
<xivulon> so do we use (hidden) redirection or do I test for 2 URLs?
<slangasek> not our decision to make yet, still needs the webmaster's buy-in :)
<slangasek> (and if the webmaster nack's hosting it on www.ubuntu.com, then it'll have to be two urls since pre-release images are hosted on a completely different server from releases)
<xivulon> I would assume that in any case, the filename within the metalink will match the underlying iso file URL (i.e. now it would be hardy-desktop-i386.iso)
<slangasek> right
<xivulon> slangsek thanks a lot for bearing with me
<xivulon> aaaaa^
<slangasek> no problem at all; sorry for having deferred this so long
<xivulon> not strictly a problem for me, I simply wanted to avoid post feature-freeze changes
<soren> pitti: debian bug 465340
<ubotu> Debian bug 465340 in dpkg "dpkg: Broken call to open in Dpkg/Control.pm" [Important,Open] http://bugs.debian.org/465340
<soren> pitti: Short version: Please use dpkg-gencontrol differently :)
 * soren gives doko "the eye"
 * ion_ has two.
<doko_> siren: ?
<doko_> soren: ?
<soren> doko: Hm.... I'm having odd problems with grub and right now, my prime suspect is your dpkg patch :)
<soren> doko: Yup, it seems to be accurate.
<soren> doko: It checks:
<soren> if test "x$CFLAGS" = x; then default_CFLAGS=yes
<soren> fi
<soren> And if $default_CFLAGS isn't "yes", it doesn't check for e.g. -fno-stack-protector and then it blows up.
<doko> soren: ohh great, it does the CFLAGS settings stuff in debian/rules, but then it doesn't pass it to the upstream make
<soren> doko: What would you suggest? Adding -fno-stack-protector to CFLAGS? unset CFLAGS before calling configure?
<doko> or configure
<soren> doko: No, it *does* get passed to configure. That's the problem. configure behaves differently depending on whether or not CFLAGS is unset(/empty) or not.
<doko> soren: this is insane. the conservative thing would be to unexport CFLAGS, and mention it in debian/rules
<soren> doko: That's your recommendation?
<soren> doko: I just tested it, and it does indeed fix it. Not surprising, I'm just saying.
<doko> soren: unexport CFLAGS, and maybe remove the setting of CLAGS in the rules file, it's just misleading
<soren> doko: Hm... I'm not sure I remember this correctly..
<soren> If a makefile specifies CFLAGS, but there's also a CFLAGS environment variable, what happens?
<soren> The environment variable takes precedence, right?
<doko> soren: in debian/rules, CFLAGS is not passed to configure, so CFLAGS from debian/files is ignored, configure takes it from the env. in the generated Makefile, it's available and taken, unless you call make with the -e option
<soren> doko: Ah.. Ok.
<emgent> debian #462984
<ubotu> Debian bug 462984 in python-moinmoin "python-moinmoin: MOIN_ID cookie bug" [Serious,Open] http://bugs.debian.org/462984
#ubuntu-devel 2008-02-13
<burner> anyone familiar with what ubuntu is going to do about nautilus and gio in hardy?  gio isn't going to support smb:// or ftp:// according to the gnome folks.  can gnome-vfs going to be backported or are we just going to have regressions when going from dapper to hardy?
 * Fujitsu can use SMB in Hardy's Nautilus, and it seems to use GIO...
<burner> oh?
<Fujitsu> It's not exavrtly reliable, but...
<burner> well wtf was all that chatter on planet gnome?
<Fujitsu> There was something about it not supporting network:/// or similar a while ago.
<burner> aww
<burner> that's right
<burner> http://live.gnome.org/GioToDo says there is no Network:  ftp: http/https/webdav: obexftp: burn: or fonts:
<burner> ftp is going to kill me when doing web dev :\
<soren> Aw, no fonts:/// ?
<Fujitsu> I have a burn:/// too.
 * burner shrugs
<ion_> You arenât using FTP with authentication but without encryption, are you?
 * burner is
 * burner does
 * burner has a host that doesn't support sftp
<thotypous> hi :)
 * Fujitsu would have hoped that such hosts ceased to exist a while ago.
<ion_> You arenât paying anything for the service, are you?
<thotypous> hi caetano
<caetano> hi
<thotypous> hey, is there someone here responsible for ubuntu's kernel stuff?
<mjg59> thotypous: #ubuntu-kernel
<thotypous> thanks
<thotypous> hey maskd, #ubuntu-kernel
<Pimentel-ES> thotypous: burro
<Pimentel-ES> nao vai falar do oss?
<xivulon> heno: I have uploaded umenu code to https://code.launchpad.net/umenu
<xivulon> make prerequisites && make && make test
<ogra> aclocal: macro `AM_PROG_MKDIR_P' required but not defined
 * ogra sighs loudly
<lamont> ogra: automake does tend to make one sigh, doesn't it./
<ogra> yeah
<ogra> especially if someone "fixed" your code to use a newer version instead of being compatible with the most common one ....
<jdong> any ubuntu-main-sponsors want a quickie?
<jdong> (upload, that is)
<lamont> ogra: but newer is always better, no?
<TheMuso> jdong: In a few months I might. :p
<TheMuso> but not just yet
<jdong> TheMuso: :) that's no help for a feature freeze ;-)
 * jdong thinks transmission should stay in universe until FF!
<TheMuso> jdong: Its called, just got the keys to the world, and don't want to break anything.
<jdong> TheMuso: haha well you have my word that it won't break anything :)
<jdong> if that means anything :D
<TheMuso> No, I'm not even on the main sponsors team yet
<jdong> oh well I'll keep /pounce-ums active then
<ogra> lamont, yeah, but some people use changelogs to let other devs know it changed ... ;)
<superm1> ogra, i missed the discussion with you and laga on the patches that he had for mythbuntu-diskless against ltsp, what came of that?
<ogra> superm1, the plugin is included in ltsp since today, his initramfs changes have to be merged into the mythbuntu-diskless-client package
<ogra> there are some changes i''d like to see in the code before final but all in all it looks fine
<superm1> ogra, okay so everything should be fine on it then for this cycle?
<ogra> yup
<superm1> ogra, great, thanks :)
<lamont> sigh.  jdong did you get taken care of while I was translocating?
<jdong> lamont: you mean my call for sponsorship? not yet
<lamont> what is it you need sponsored?
<jdong> bug 190614
<ubotu> Launchpad bug 190614 in transmission "New upstream version: 1.05" [Undecided,New] https://launchpad.net/bugs/190614
<lamont> if it's not too complex, I suppose I could be talked into it...
<lamont> hrm...
<jdong> it's a trivial and routine one
<jdong> I've been the one who's done like the past 4 or 5
<lamont> where does $UPSTREAM_VERSION get used?
<lamont> or rather, where should I grab bts from to look at them?
<jdong> lamont: it's used in Debian's get-orig-source rule
<jdong> lamont: which is redundant and there for historical purposes, as right now a watchfile is used
<jdong> (before DFSG needed to do some repacking)
<lamont> ah
 * lamont fetches
 * lamont wants to know how to get gutsy's network managler to automatically notice that and switch ssids without me doing "manual config"
<jdong> lamont: it doesn't detect your teleportation?
<lamont> something like that
<jdong> lamont: are you sleeping to and from your destination?
<lamont> I removed network mangler and reinstalled it (long story_)
<lamont> and right now all i have is 'manual config'
 * lamont dist-upgrades his hardy chroot so he can test build
<ogra> does anyone know why libexecdir defaults to /usr/libexec, even that dir usually doesnt exists in debian/ubuntu and is usually pointed to /usr/lib ?
<ogra> i would expect it to use a default that actually works with my system
<lamont> ogra: historical linux?
<ogra> silly ... i would expect tools that have "auto" in their name to set the best defaults for the current system i'm on :)
<lamont> ogra: bug keybuk, I guess...
<ogra> well, likely asleep :)
<lamont> and your excuse?
<ogra> freeze tomorrow, and insanely early meeting :)
<lamont> oh. meh
<ogra> (well, insanely early for my biorhythm ... others like to be up at 8am :) )
<lamont> feature freeze or so?
<ogra> yep
<ogra> which goes hand in hand with UVF nowadays
<lamont> ok.  /me has an upload pending for bind9 - but it's more of a bug fix, IMO
<lamont> otoh, we're two revs back
<ogra> well, it wouldnt be a freeze if theer werent exceptions
 * lamont files a sync request,  having noticed that it's out of date
<lamont> jdong: you didn't say it build-depends: $WORLD
<jdong> lamont: sorry :)
<jdong> lamont: you could take my word that it builds fine in a hardy pbuilder
<ScottK> !jdong
<ubotu> <Hobbsee> jdong: yes, but you're FULL OF CRACK!
<ScottK> ;-)
<ScottK> If it's transmission though, I'd be inclined to believe him.
<lamont> heh
<lamont> Get:91 http://us.archive.ubuntu.com hardy/main gettext 0.17-2ubuntu1 [1978kB]
<lamont> jdong: transmission_1.05-0ubuntu1 uploaded
<jdong> lamont: thanks!
<jdong> lamont: now it'll hurt less the next time you do it for me :D
<lamont> lol
<jdong> (luckily for you there's FF)
<lamont> yeah - my build chroots hadn't been set up yet on the laptop
<lamont> what's FF? :-)
<lamont> I will _not_ upload firefox for you
 * lamont ducks
<StevenK> Hah
<LaserJock> lol
<emgent> :)
<StevenK> Is jdong wanting to crackport firefox? :-P
<lamont> I  wonder if anyone has ever done stats on who's sig is most common on new upstream versions in the archive post-feature freeze...
<lamont> StevenK: what else could FF possibly mean? :-)
<StevenK> lamont: "Feature Freeze"
<lamont> StevenK: you do spoil trolling, you know...
<LaserJock> lamont: seb128 perhaps?
<StevenK> lamont: :-)
<lamont> LaserJock: almost certainly
<jdong> StevenK: ff-3 crackports already done btw ;-)
<StevenK> jdong: Argh
 * lamont notes that is  "just do the right thing, dammit' build-package script is now 250 lines of shell
<jdong> StevenK: it was done responsibly and safely though ;-)
<lamont> I should really consider rewriting that in something else.
<StevenK> lamont: Blink?
<StevenK> 250 lines to do what?
<superm1> could one of you many core-devs around sponsor a small patch to acpi-support?  bug 123104
<ubotu> Launchpad bug 123104 in acpi-support "Suspend using nvidia driver and NVIDIA 8400M GS doesn't work" [Undecided,In progress] https://launchpad.net/bugs/123104
 * ScottK is pretty certain that's not where I'm going to start doing Main uploads....
<lamont> ScottK: _I_ won't touch an acpi upload
<StevenK> ScottK: Did you get core-dev?
<lamont> StevenK: mostly magic sed commands to smash build-deps around
<ScottK> StevenK: I did
<lamont> StevenK: he's a real person now
<StevenK> ScottK: Nice! Congrats
<jdong> superm1: we still use acpi-support?
<ScottK> lamont: Heh
<superm1> congrats ScottK, i wasnt aware of this either
<StevenK> lamont: ... Why?
<ScottK> StevenK: Thanks.
<ScottK> superm1: Thanks.
<lamont> StevenK: he's a real person because he's cool.
<jdong> ScottK: congrats!
<lamont> acpi?  scary - too easy to break random crap elsewhere with what seems like a simple fix.
<StevenK> lamont: Sorry, that "... Why?" was due to "mostly magic sed commands to smash build-deps around
<superm1> jdong, I was under the impression that part of it was still used
<lamont> because sometimes I backport things from hardy to dapper.
<superm1> to build the modules that need to be taken out
<StevenK> Crazy
<jdong> superm1: that may be. Sounds a bit silly though
<lamont> jdong: acpi-support is on my freshly-installed gutsy box
<StevenK> superm1: I'd talk to mjg59 first.
<jdong> superm1: and pm-utils's taking out modules routine actually does absolutely crap
<ScottK> jdong: THanks
<jdong> lamont: hardy's using pm-utils though :)
<lamont> ah, ok
<superm1> thanks StevenK i'll check with him
<jdong> superm1: I filed a bug and a debdiff on that ;-)
<lamont> one of these days I should do more playing with hardy...
<jdong> lamont: it looks very promising as a solid release :)
<lamont> mostly ScottK just tells me to upload stuff, and I do....
<lamont> no one wants a solid hardy release more than me
<lamont> backporting from hardy to dapper, um, sometimes really really sucks
<jdong> lol
<lamont> only 10 sed commands (admittedly, it could be 2, since all but one just tweak debian/control
<lamont> I think my favorite has to be:
<lamont>                         sed -ri "$(grep-dctrl -P -sPackage -n python- ${CTL} |
<lamont>                                   sed 's/\(python\)\(-.*\)/\/^[^ ]*(Pac|Dep|Sug|Pro|Con|Rep)\/s\/\0\/\12.4\2\/g;/')" ${CTL}
<StevenK> Please. I just ate.
<LaserJock> yikes
<jdong> wow
<lamont> what's wrong with having sed generate a sed program?
<lamont> have I mentioned that I love python, and I _HATE_ python-packaging changes?
<StevenK> lamont: A few things. Mostly readability and maintainability?
<lamont> StevenK: piffle
<lamont>                         sed -i '/^Build-Dep/s/libdb-dev (>=4.6.19-1)/libdb4.4-dev/g' ${CTL}
<lamont> that one is nicer.
<lamont> see, this way I just say 'build-package -bfeisty postfix_4.7.1-1' and it does the right thing, and generates binaries for testing, so that I can sign and upload the source.
<lamont> admittedly, the dapper backports I'm doing have a very targeted uh, target.
<jdong> lamont: why don't you just write a pbuilder-satisfydepends that's more lenient? :)
<jdong> lamont: then I can steal parts of that for backports usage too
<lamont> jdong: because I'm uploading these to a pedantic archive
<StevenK> lamont: Is the meat of build-package calling sbuild or pbuilder?
<jdong> lamont: lovely :)
<lamont> sbuild.
<lamont> what's pbuilder?
<lamont> :-)
<StevenK> Haha
 * lamont has only been using sbuild for most of a decade...
<lamont> I keep saying that I should really take time and learn pbuilder... it never makes it above the cutline though...
<StevenK> Depends how long your machine takes to untar a 80Mb base tarball
<lifeless> lamont: pdebuild FTW
<lifeless> lamont: combined with bzr builddeb, its fun
<lamont> a major improvement in the script came recently when I taught it to notice that I'd forgotten the epoch in the version, and just rip that from changelog
<StevenK> I'm going to stand up for sbuild, and say that keescook is my hero and that mk-sbuild-lv rocks
<lamont> lifeless: I've used bzr far more in the last five weeks than ever before.
<lifeless> lamont: thumbs up or down
<lamont> I'm building a list... have filed a bug or 3
<lamont> well, _a_ bug, iirc.
<lamont> I think that I have more
<lamont> lifeless: I did make my life a bit simpler by making sure that I'm using bzr 1.1-1 everywhere, instead of 0.8.$mumble
<lamont> 0.8.2-1ubuntu3 to be specific
<lamont> and myriad versions in between...
<lamont> bzr uncommit? +1
<lamont> any bzr command that generates copious output not doing the right thing (piping to $PAGER)? -1
<lamont> mostly thumbs up
<LaserJock> lifeless: you guys got a "bzr for git users" doc somewhere?
<lifeless> LaserJock: the wiki, possibly the user manual now
<lamont> lifeless: give me an easy way to bzr import from active git repo, and push commits both ways
<lamont> LaserJock: I'
<lamont> ve mostly been getting the crash-hands-on course
<StevenK> I wish there was a "git for bzr users" -- I really like bzr, but can't get my head around git
<lamont> see the tech talks
<lamont> most notably randalls
<LaserJock> StevenK: I think I might be the opposite
<LaserJock> I don't think I got much out of bzr
<LaserJock> but I find git quite nice
<StevenK> bzr just works like cvs and svn, so I just clicked.
<StevenK> git just looks oddball
<Fujitsu> StevenK: bzr doesn't work like CVS. CVS doesn't work.
<lamont> StevenK: that's what happens when someone designs the plumbing and doesn't care about the porcelain
<StevenK> Fujitsu: Sure it works, it just doesn't do some things well
<lamont> git prior to 1.5?  sucky UI that is not recommendable for anyone other than kernel gods
<StevenK> Heh
<StevenK> Well, even Rusty can't work out git
<lamont> rusty?
<LaserJock> I really like git-cvs
<lamont> LaserJock: parsecvs for the win
<lamont> although you need sane ,v files for that
<StevenK> lamont: Rusty Russell
<lamont> lifeless: yes, postfix broke parsecvs too
<lamont> merge speed in git is rather incredible, I must say
<LaserJock> I think the part of bzr that's gives me problems, and perhaps what I like about git, is the "branch as dir" concept
<lamont> ??
<LaserJock> I just don't like having directories all over so I tend to not branch very much in bzr
<LaserJock> whereas in git my dir structure stays clean even if I have branches all over
 * ogra was proposing a branch as pizza function since ages, but noone heard
 * lamont tends to bounce between branches in one working directory... if I really really need more than one dir, I can clone the branch I want into a sisiter dir
<RAOF> LaserJock: Where as I'm completely the opposite.  git's hidden branch approach smacks of code-simplicity over interface tradeoffs to me.
<lifeless> StevenK: you dont want to get your head around git
 * lamont isn't sure about this "branch as dir" thing...  maybe I need to actually read the users manual...
<lamont> RAOF: hidden branch?  it's a file.
<lamont> you want it in a separate dir, you clone
<lifeless> lamont: problem is, plumbing sets constraints on porcelain
<RAOF> lamont: And then checkout.  Using strange and arcane syntax.
<lamont> yeah... that's why it wants to be pretty static from the beginning
<lamont> RAOF: of course.  clone is well, clone
<emgent> debian #464876
<ubotu> Debian bug 464876 in drupal5 "drupal5: New upstream version 5.7 available, fixes several bugs" [Normal,Fixed] http://bugs.debian.org/464876
<lamont>  git clone postfix test; cd test; git rebase origin/stable/v2.4
<lamont> it's not _so_ arcane...
<lamont> of course the downside is that 'master' in test is then stable/v2.4 in the original (postfix) tree
<lamont> just remember: source management systems all suck.  differently.
<lifeless> lamont: branches in a file in .git -> not discoverable; complex rules to edit, can't use standard shell commands to manage branches, urls are tricky to define well and usefully.
<lamont> actually, .git/refs/head/$branchname is a file... containing the sha1 of the head of that branch
<lamont> and git-branch -a will show all of them
<lamont> hrm.. does dapper dpkg have anything like source:Upstream-Version?
<lamont> nope.
<lamont> sigh
<StevenK> lifeless: moblin are using git, so I have to at least learn a bit
<lamont> StevenK: seriously, watch randall's tech talk
<lamont> once you understand git's "index" (which every source management system has, and almost none export to the user's view), then it all falls into place.
<lamont> until then, it's confusion
<lamont> randall does a good job of giving a tech overview of git.
<StevenK> lamont: Google for "randall tech git talk" or so?
<lamont> lifeless: bzr bisect would be cool to have.
<lamont> StevenK: yep
<lamont> google for "git tech talk" (with quotes) and (last time i did it) there were two results: linus and randal
<lamont> randall
<lamont> even
<lifeless> lamont: https://launchpad.net/bzr-rebase
<lifeless> lamont: exposing the index is not done by most systems for a reason
<lifeless> lamont: its like exposing inodes to the user (and I don't mean C programs) on a file system.
<lamont> lifeless: yeah
<RAOF> lifeless: You know, it seems like all the features I want in bzr are already plugin projects on LP.  Are they going to get an actual release sometime soon?  Please? :)
<lifeless> RAOF: what do you mean
<lamont> lifeless: yeah... the index does tend to confuse the hell out of people without providing them the benefit that understanding it would given them.
<lamont> s/given/give/
<RAOF> Well, there seem to be a lot of useful bzr plugins on LP; things like bzr-git, bzr-rebase, bzr-bisect, etc.  But none of them seem to have released a tarball.
<RAOF> Or been packaged in some other form useful to me.
<lifeless> lamont: s/would/might/
<lifeless> lamont: most users won't get any benefit from the index
<lamont> yeah
<lifeless> they don't /want/ a current state that differs from the working tree in any wa.
<lamont> the index being exposed is one of those things you get when a kernel jock designs an SCM.
 * lamont uses it as a 1/2 commit :0)
<lifeless> RAOF: so package and upload them
<lifeless> RAOF: join the bzr-packaging team
<lifeless> RAOF: tarballs are so 1980's
<LaserJock> lifeless: is there such a team?
<RAOF> Oh, but that's *work*.  Worse, it's work that I have to do! :P  Ok, added to my TODO.
<lifeless> LaserJock: its on alioth
<StevenK> lamont: Googling only shows Linus' talk
<LaserJock> StevenK: the first one is the one you want
<LaserJock> StevenK: it just says "git"
<LaserJock> http://www.youtube.com/watch?v=8dhZ9BXQgc4
<lamont> gah
<lamont> gimme a second
<lamont> http://video.google.com/videoplay?docid=-3999952944619245780
 * StevenK clicks the yummy download link
<lifeless> RAOF: basically, with a vcs every push is a release; folk really stop bothering with tarballs in smaller projects. too much overhead, and too slow.
<lamont> StevenK: any of the october versions are Randall.  Linus was a few months earlier
<lamont> lifeless: overall, I'm very impressed with bzr
<LaserJock> lifeless: except it's hard to distribute and is much harder to find a "stable" release
<RAOF> lifeless: Fair enough.  Bzr builddeb should make packaging from bzr more enjoyable.
<lamont>   * backport to dapper
<lamont>   * source:Upstream-Version expanded inline
<lamont> there. now build-package deals with packages that use source:Upstream-Version
<lifeless> lamont: good :)
<lamont> wc /home/lamont/bin/build-package
<lamont>  254  802 7371 /home/lamont/bin/build-package
<lifeless> LaserJock: uhhh, its trivial to distribute, and tarballs have no magic equality with stability.
<LaserJock> lifeless: it's not trivial to distribute until we get rid of source packages, and no, there is no "magic", but it's more "conventional"
<lamont> lifeless: for anything that's going into a debian/ubuntu/whatever release, trivial packaging of tar+diff is kinda a requirement
<lamont> or at least a tarball
<lifeless> lamont: 'bzr export'
<lamont> yeah - it's trivial for us'ns
<lamont> I was aluding back to the bzr builddeb
<lamont> which I freely admit to never having used
<TheMuso> bzr-builddeb is great.
<jdong> "which I freely admit to never having used"
<jdong> that's coolest sentence construct of the day!
<lamont> jdong: cool sentence construction is just one of my more flashy skills
<lamont> I haz gud wordspeak
<lifeless> in ur channelz hacking ur brainz
<lamont> 'zactly
<lamont> lifeless: so when are we all switching to RCS? :-)
<lamont> my kids go to RCS.
<lamont> hrm.
<lamont> I think that's different
<lamont> </troll>
<jdong> lamont: you you have to pick them up and drop them off individually?
<jdong> :)
<StevenK> And woe betide if your children change names!
<lamont> actually, their start/stop times _are_ staggered 15 min... so the one just gets dropped off early and picked up late
<lamont> www.ridgeviewclassical.com
<StevenK> A classical school.
<lamont> StevenK: _very_.
<StevenK> Damn, I was going somewhere with that, and then my thought train derailed
<StevenK> Oh yes.
<StevenK> A classical school, as opposed to you know, *regular* boring school.
<jdong> to make everyone feel better....
<jdong> at the MIT software engineering course, I am being FORCED to write JAVA CODE in a PAPER NOTEBOOK.
<jdong> of course, 0.5 pages of code later, it turned into a 3 page argument why this is nonsensical :)
<StevenK> I hate doing that in exams.
<regulate> take a different course
<lamont> StevenK: it's more around changes in the modern education ideas
<lamont> which the school kinda, uh, rejects.
<StevenK> lamont: Like computers?
<lamont> like student-desire-drivin curriculum.
<lamont> actually, the school teaches openoffice to everyone
<StevenK> Pah, we never had that when I went to school
<lamont> it's a mindset, not specific curriculum.
<lamont> curricula?
<regulate> curriculae
<regulate> curriculum
<lamont> tardy?  no problem.  sit right there on the bench until the period is over.  you will not interrupt the class and waste 1+ student-hours (30 students, 2 min or so disturbance)
<lamont> little things like that.  very teacher-centered education
<lifeless> lamont: do they get their drugs from CVS?
<lamont> we actually don't have any CVS stores here.  iz very sad.
<StevenK> I nearly fell over when I saw the CVS store in Boston
<StevenK> And then on Friday, pitti and I saw a CVS import
<lamont> StevenK: that just hurts
<lamont> hrm...  closing time... I guess I should start wrapping up
<lamont> dear kde.  70 MB is not a deb.  it's several.
<lamont> kthx
<genii> OK, not sure if this is some dev issue, but here's a weird problem. In 2.6.22-14-generic my usb based rtl8187 works fine but kernel of course can't see my full 8Gb. In 2.6.22-14-server the RAM gets seen but the nic is no good. Even tried compiling from svn from rtl-wifi but getting indecipherable compiler errors on all svn versions 61 thru 67.The exact same code compiles without a groan under -generic
<genii> Some weird PAE thing perhaps?
 * genii hands SNuxoll a coffee
<SNuxoll> yay caffiene
 * lamont relocates homeward
<talcite> hey guys, does anyone know if the sqlite3 in the gutsy repos is compiled with the --threadsafe option?
<beuno> talcite, it would seem from the build log that yes: http://launchpadlibrarian.net/9193582/buildlog_ubuntu-gutsy-i386.sqlite_2.8.17-2.1build1_FULLYBUILT.txt.gz
<LucidFox> Any core-devs involved with Mono here?
<beuno> it has the "-DTHREADSAFE=1" bit in it
<talcite> beuno: thanks
<warp10> Good morning
 * lamont gets home, sleeps.  night all
<Fujitsu> Night lamont.
<LucidFox> Fujitsu, did you check PM?
<thegodfather> superm1: ping?
<superm1> yo
<thegodfather> superm1: hey.. i think you should plan to change the Depends: mysql-server to Predepends
<superm1> on which?
<superm1> er which package particularly at least
<thegodfather> superm1: problem on upgrade is simple.. mythtv wants to backup and update the db, but if mysql is upgraded too, it's not running.. failing to backup and update
<thegodfather> superm1: dunno.. you can figure that out yourself :)
<superm1> ah for folks going from dapper->hardy or gutsy->hardy
<thegodfather> at the moment i am just doing hardy->hardy regular updates
<superm1> and running into that particular issue i suppose?
<thegodfather> problem occours when there is a major myth db update and mysql update at the same time
<thegodfather> so that will be the case also on upgrades from release to release
<thegodfather> or anything that upgrades to hardy
<thegodfather> superm1: yes.. right now
<superm1> thegodfather, okay i'll see what i can do, you should see it in the next hardy update.  let me know if that works out better for you then
<thegodfather> superm1: well it can be simulated if you need to
<thegodfather> superm1: just prepare a fake mysql update in your local repo and a mythtv update at the same time
<superm1> yeah good point
<thegodfather> superm1: make sure that the mythtv update simulate a mysql DB update and zack
<superm1> well i'm fairly confident that you're right on this too, pre-depends should solve it.
 * Mithrandir grumbles at his /dev/sda being renamed to /dev/hda
<ogra> lol, really ?
 * ogra has never seen it this way around
<Mithrandir> happened between -5 and -7 in hardy.
<Mithrandir> unsurprising, this breaks libpam-mount
<dholbach> good morning
<stgraber> moin
<TomJaeger> Stefan Bader is not hanging around here, is he?
<TomJaeger> are there any formal critera to get a patch into the ubuntu kernal?
<TomJaeger> anybody?
<TomJaeger> alright, I'll just post to launchpad
<TomJaeger> quit
<TheMuso> Do MIRs need to be done by FF?
<ionstorm> https://bugs.edge.launchpad.net/ubuntu/+source/linux-source-2.6.24/+bug/190587 whats up with this security risk
<ubotu> Launchpad bug 190587 in linux "Local root exploit in kernel 2.6.17 - 2.6.24 (vmsplice)" [High,Fix committed]
<panthera> hi,
<panthera> for the sake of 'history', i'd like to have all ubuntu revisions ever of my packages in debian.
<panthera> is there something like snapshot.d.n for ubuntu?
<cjwatson> panthera: you should be able to fish them out of links in Launchpad, at least from dapper onwards
<cjwatson> start from https://launchpad.net/ubuntu/+source/PACKAGENAME
<cjwatson> ionstorm: seems to be in pretty good progress
<panthera> cjwatson: nice, thanks.
<\sh> soren, thx
<Riddell> pitti: could you give back digikam
 * Mithrandir stabs gecko with a very sharp spoon
<Mithrandir> actually, cairo.
<simira> Mithrandir: didn't I tell you to stop stabbing people with spoons?
<Mithrandir> epiphany-browser: /build/buildd/cairo-1.5.8/src/cairo-pdf-surface.c:4461: _cairo_pdf_surface_fill: Assertion `_cairo_pdf_surface_operation_supported (surface, op, source)' failed.
<Mithrandir> (when trying to print to PDF)
<soren> Unless there's any particular reason not to, could an archive admin please release the new kernel from NEW?
<Mithrandir> not that postscript fares any better.  *sigh*.
<tjaalton> any hal experts available? I can't get hal-set-property to work from a script ("Could not initialise connection to hald."), when it works if run by hand
<cjwatson> soren: done (amd64 i386 lpia sparc)
<soren> cjwatson: Cool. Thanks.
<soren> cjwatson: Any chance we could get a new debian-installer once the new kernel is published?
<soren> cjwatson: ...and perhaps a respin of the server cd when the new debian-installer is published? Pretty please? :)
<TheMuso> soren: We need new metas I think.
<soren> TheMuso: Not exactly "need".
<soren> TheMuso: d-i specifies which version it wants.
<soren> TheMuso: explicitly.
<TheMuso> soren: Fair enough
<soren> TheMuso: It wouldn't be very nice to have the installer and linux-meta out of sync, though.
<soren> TheMuso: To sum up: Good point!
<soren> :)
 * TheMuso now feels nervous... About to upload packages to implement initramfs error handling... :)
<cjwatson> soren: linux-meta should go in at around the same time, so I'd prefer kernel team coordination
<geser> good morning
<soren> cjwatson: Alright then.
<pitti> Riddell: given back
<pitti> soren: so pkg-create-dbgsym should use a temporary file instead of stdin? hmkay
<pitti> ScottK: argh, sorry about not being at the meeting; I was at dancing school; how did it go?
<\sh> if someone has some time checking licensing stuff: please review this license and tell me if it's usable for universe/multiverse? zend-framework http://framework.zend.com/license
<soren> pitti: Either that or find another way of reading it from stdin.
<ScottK> pitti: It went quite well.  I'm in.
<ScottK> pitti: Thanks for asking.
<Riddell> pitti: did you see that mhb had extra exams so won't make feature freeze for jockey qt
<geser> \sh: what problem do you see with this license? it has a caption of "New BSD License" and also looks very similar to /usr/share/common-licenses/BSD
<\sh> geser, this point: * Neither the name of Zend Technologies USA, Inc. nor the names of its
<\sh>       contributors may be used to endorse or promote products derived from this
<\sh>       software without specific prior written permission.
<geser> \sh: "3. Neither the name of the University nor the names of its contributors
<geser>    may be used to endorse or promote products derived from this software
<geser>    without specific prior written permission." from /usr/share/common-licenses/BSD
<geser> so it doesn't look like a problem
<\sh> geser, so naming the package "zend-framework"  is not covered by this?
<MacSlow> mvo, do you happen to be in a mode of grabbing a newer version of libcompizconfig from upstream atm?
<pitti> ScottK: congratulations! *hug*
<geser> \sh: at this point I'm not sure
<pitti> Riddell: ergh, not given back; my script fails with a HTTP Error 500: Internal Server Error
<pitti> Riddell: yay ever-changing LP
<MacSlow> mvo, I ask because I just happen to run into a bug, which I talked about on #compiz-fusion... Danny fixed it right away... and it is important for the profile-spec
<ScottK> pitti: Thanks.
<\sh> geser, see, that's what was bugging me :)
<pitti> Riddell: mhb> I didn't see it, I just talked to him yesterday and he seemed quite busy
<pitti> with hacking on jockey
<\sh> elmo, you as ftpmaster, any thoughts about this?
<MacSlow> mvo, if you're busy elsewhere I can do it myself and just hand over the .diff.gz/.dsc for upload-sponsorship
<cjwatson> \sh: a package name isn't normally counted as "endors[ing] or promot[ing]"
<cjwatson> \sh: we have plenty of other examples of the same thing in the archive
<mvo> MacSlow: I can do it in a bit, just use your local fixed version for developing in the meantime. it will be uploaded before lunch
<MacSlow> mvo, okyday
<MacSlow> argx
<cjwatson> \sh: p.s. elmo hasn't done active Ubuntu ftpmaster work other than related system administration for a couple of years now. launchpad.net/~ubuntu-archive
<MacSlow> mvo, thanks
<\sh> cjwatson, so it's ok to name the package "zend-framework" without violating the new BSD lic...(and elmo came into my mind because of his duties as debian ftpmaster)
<Riddell> pitti: ok, that was last week, maybe he's back onto it now
<TheMuso> Ok, so I'm assuming that silence means that MIRs can be written, and can be accepted after FF...
<cjwatson> \sh: if this were a problem, little things like python would be in violation. It's fine.
<cjwatson> TheMuso: err
<cjwatson> TheMuso: the incorporation of dmraid into the installer is a feature, and is subject to feature freeze
<TheMuso> Oh ok.
<\sh> cjwatson, thx for the headsup :)
<cjwatson> TheMuso: we treat things on that kind of level rather than the mechanics of "is it an MIR or something else"
<TheMuso> ugh of course
<Mithrandir> siretart: is revu down?
<ScottK> Yes
<Mithrandir> hm, any idea when it'll be fixed?
<ScottK> No.  It had a full hard drive yesterday, but sistypoty isn't around now and he was the one looking into it.
<Mithrandir> ah, ok
<Keybuk> ogra: long running argument, that one
<TheMuso> cjwatson: Are you able to change the status of the initramfs error handling spec? Since I wasn't involved with it, I can't, but have edited the whiteboard and left notes.
<dramen> hello
<dramen> i built my own apt-repository. now when i want to install a programme using "apt-get install ...." i get a warning about authentification of the package
<soren> pochu: gtk-vnc uploaded. Thanks.
<TheMuso> dramen: You need to sign the Release file with a GPG key, and then ad the public key to apt's keyring, so it knows about it.
<soren> pochu: Sorry for the delay.
<pochu> soren: yohoo :)
<dramen> i generated a Release.gpg in the repository and added the key to apt (apt-key add <file>)
<pochu> soren: I was blocked with that for vinagre, so thanks a lot!
<pochu> soren: was the patch update ok?
<TheMuso> dramen: Hrm wel I'm out of ideas.
<cjwatson> TheMuso: I've assigned it to you, so you should be able to change its status now
<TheMuso> cjwatson: Thanks.
<dramen> "apt-key list " shows me the correct data about my keys
<dramen> and "gpg --list-keys" as well
<soren> pochu: Almost :) One line missing, but it was easy to miss.
<cjwatson> dramen: this may be obvious, but you need to 'apt-get update' *after* setting up a proper Release.gpg
<dramen> i did it
<dramen> and everything seems to be all right
<Lure> who is the right person to approve blacklisting specific kernel modules, like suggested in bug 114565
 * persia suspects someone in #ubuntu-kernel, but doesn't actually know
<TheMuso> pitti: If you're around and have a minute, I'd like to have a chat with you about dmraid.
<pitti> TheMuso: I'm 120% busy today anyway due to FF, so please just ask me, and I'll answer (maybe with some lag)
<TheMuso> pitti: Ok. There was talk of adding dmraid to the installer as a feature for hardy, but nothing has been done till now. I happened to have hardware that supported it, and have managed to perform an install using dmraid, which is almost 100% working.
<TheMuso> pitti: Do you think its worth trying to get in, and if so, should I go about writing an MIR for it, assuming that all is well with code etc?
<TheMuso> pitti: Or do you think it shoudl wait for hardy+1?
<pitti> TheMuso: what is dmraid? d-i already has support for setting up RAID?
<pitti> TheMuso: is there a spec for it?
<TheMuso> pitti: Afaik there is no spec. Dmraid is used to use the kernel's devmapper layer to make use of configurations that are saved to hard disks that are configured in a fakeraid/bios raid setup.
<TheMuso> pitti: This is common on a lot of newer motherboards, well since 2002 at least.
<cjwatson> pitti: the existing RAID support doesn't help with dmraid; there's no spec because this is work done upstream by Debain
<cjwatson> Debian
<pitti> TheMuso: MIR wise you can go ahead for my sake, but I don't feel qualified about feasibility of d-i/ubiquity integration; I defer to cjwatson and evand for that
<pitti> (and keep in mind that we are currently DoSed with dozens of MIRs and can hardly keep up, so it'll take a while)
<TheMuso> Understandable.
<TheMuso> pitti: Part of the integration with d-i is already done through partman-dmraid.
<geser> pitti: have you time to give-back ftphs?
<pitti> geser: if my script wouldn't fail with 500: Internal Server Error *sigh*
<Mithrandir> geser: given-back
<pitti> geser: nothing to give back
<pitti> ah, Mithrandir beat me to it apparently
<Mithrandir> yeah, my greasemonkey script doesn't take 500 for an answer.
<StevenK> Hah
<geser> Mithrandir, pitti: thanks
<Riddell> pitti: could you move the dapper packages in bug 184149 to -updates at some point, they're been checked by sru-verification
<ubotu> Launchpad bug 184149 in kdelibs "[hardy]xembed and flash support patches doesn't work for konqueror" [Undecided,Fix committed] https://launchpad.net/bugs/184149
<pitti> Riddell: ok (although the flashplugin isn't updated in dapper yet)
<Riddell> pitti: no but there's one in backports, and it won't do any harm for those with older flash
<pitti> Riddell: bdmurray had to update the one in -backports AFAIR
<Riddell> yes
<pitti> anyway, will move
<pitti> Riddell: btw, the bug mentions 'still broken in hardy', although it's marked as fixed?
<Riddell> pitti: I suspect his konqueror just hasn't found the flash plugin
<pitti> Riddell: copied
<Riddell> thanks pitti
<pranith> hello
<pranith> is there any good decompiler which i can use to decompile binaries to source code. i need this for a project im doing...
<pitti> pranith: if you are talking about decompiling machine code (ELF files), there can't be something like a 'good' decompiler
<pranith> pitti, any decompiler, not necessarily good...?
<pitti> pranith: I don't know any either
<Mithrandir> pranith: gdb can disassemble for you
<pranith> Mithrandir, dissambling is ok. i want a decompiler which can give me C source code. working with assembly is too complex
<Riddell> pitti: so you're unable to give back digikam?
<pitti> Riddell: doing now (just more work)
<frafu> Hello, could anybody please review the main inclusion request for mousetweaks: https://bugs.edge.launchpad.net/ubuntu/+source/mousetweaks/+bug/190208
<ubotu> Launchpad bug 190208 in mousetweaks "Main Inclusion Report for mousetweaks" [Undecided,New]
<pitti> Riddell: done
<Riddell> thanks pitti
<TheMuso> frafu: Is ubuntu-mir subscribed? If so, theres nothing you can do but wait.
<pitti> frafu: we have a huge backlog of MIRs; we'll get to it
<TheMuso> frafu: The main inclusion queue is quite long atm.
<frafu> TheMuso:  yes subscribed
<TheMuso> frafu: Good.
<frafu> But does feature freeze not apply?
<zul> pitti: how convient for the drbd MIR should it be upgraded as well?
<frafu> TheMuso: What about feature freeze? Once feature freeze has passed, will it have to wait ubuntu 8.10? Moreover, once it is in main, will the upgrades (upstream is GNOME) be done similarly as for universe: I prepare the diff.gz .of the new package, file an upgrade bug and subscribe ubuntu-main-sponsors to it?
<seb128> frafu: GNOME desktop has a freeze exception for new versions
<frafu> seb128: thanks for the reply; so I assume that it will make it into hardy. And what about the upgrade procedure? Will the core-dev do everything or is there also a procedure similar to upgrades in universe with sponsoring?
<seb128> frafu: what upgrade?
<frafu> for example when there is a new upstream release?
<seb128> ah, you mean update
<seb128> well, whoever does the updates usually should do those
<seb128> when the package is promoted open sponsorship requests
<frafu> seb128: thanks
<seb128> you are welcome
<saispo> any know if it's possible to resume a broken dpkg-buildpackage -rfakeroot or you must relaunch it from start ?
<persia> saispo: You can resume, but the results may not be what you expect.  Restarting is preferred to ensure reliable behaviour.
<saispo> persia: ok, it's an error about some info missing in control file :/
<saispo> persia: how can i relaunch for test ? :)
<persia> saispo: For something missing in the control file, you really want to run it all over again.
<saispo> ok :/ kernel building take a lot of times :)
<pitti> zul: "how convient for the drbd MIR should it be upgraded" -> parse error
<zul> pitti: i was just wondering about the drbd MIR, i was talking to ivoks and we believe that it should be upgraded
<pitti> ok
<zul> so Im in the process of doing that right now
<pitti> just FYI, my plan is to catch up on emails and some bugs now, and get to the MIR queue tomorrow
<pitti> anything that qualifies for main in principle, but needs some bugs fixed first, can still be promoted later
<zul> pitti: thats fine with me
<pitti> (we need to settle on features now, not components)
<zul> ive been going through the server-team related packages and trying to resolve the issues brought up in the MIR
<pitti> hm, let me do a quick re-review now, so that you guys have some more time
<geser> pitti: do you know when you will find time to fix pkg-create-dbgsym to respect -X from dh_strip calls?
<pitti> geser: this week people will keep me busy with MIRs, sponsoring, reviews, etc., I'm afraid
<pitti> geser: I'll switch to full bug fixing mode next week, and this is on the top of my list
<pitti> if anyone is interested in fixing this, feel free to preempt me, of course :)
<pitti> (even writing a test case for it would save me a lot of time already)
<geser> pitti: no hurry, I'm just curious if it didn't get lost somewhere
<pitti> geser: no, it's definitively not lost; just stalled until after FF
<dholbach> keescook: you said something about syncing imagemagick: the newest response on bug 110178 says that it's in sid now and that 2 packages will ftbfs (dx and vips)
<ubotu> Launchpad bug 110178 in imagemagick "Please sync imagemagick 7:6.3.7.9.dfsg1-1 from debian unstable" [Medium,Confirmed] https://launchpad.net/bugs/110178
<cjwatson> mjg59: did you get a chance to look at the kernel font restoration work for hardy-console
<cjwatson> ?
<mjg59> cjwatson: Afraid not
<cjwatson> are you likely to?
<mjg59> Probably can do this evening
<cjwatson> cool, thanks
 * mvo wonders what the magic switch for git diff is to make it show newly added files as well
<cjwatson> git diff --cached
<cjwatson> if you 'git update-index' everything you've edited, then that will show everything that's due to be committed
<mvo> cjwatson: thanks! that was what I was looking for :)
 * mvo wants to go back to bzr
<cjwatson> I have few words for whomever thought that --cached shouldn't be the default
<mvo> funny, git diff gives me now the changes to the existing files, git diff --cache the diff of the new file. but none shows both
<mvo> joy!
<cjwatson> mvo: see my comment about update-index
<cjwatson> in git you have to explicitly tell it about files you're changing, sort of like in quilt
<cjwatson> although you can do so after editing rather than before, unlike quilt
<mvo> I'm reading the man page for git update-index now, it seems like a simple "git update-index" is not enough (nor --add my-file)
<Mithrandir> mvo: doesn't git add $new_file $file_you_changed and then git diff --cached DTRT?
<mvo> Mithrandir: yes! misunderstood cjwatson earlier. that are indeed the magic words :)
<mvo> thanks
<Mithrandir> no need for git update-index nowadays, just use git add and git rm
<Kano> hi, how about updateing ntfs-3g?
 * mvo nods
<Kano> 1.1120 is pretty old comparted to 1.2129 and also has built-in fuse lite (which uses debian)
<cjwatson> Mithrandir: somebody said on a kernel channel the other day that one should continue to use git update-index because add may stop DoingTRT there
<Mithrandir> cjwatson: yes, that was BenC and I corrected him about 20 lines further along; add is the right way to do it now.
<Mithrandir> (see what git status outputs, for instance.)
<cjwatson> Mithrandir: oh, ok
<cjwatson> I stand corrected
<tkamppeter> hi pitti
<lool> cjwatson: Are you working on #127985?  Now that I'm core-dev, I can actually upload it  :-P
<xivulon> heno: re umenu, you need "touch po/umenu.pot" before running make, forgot to include that file yesterday
<cjwatson> lool: I'm not - please go ahead
<lool> Thanks!
<CarlFK> cjwatson: what should I be reading to get my "partman-auto/choose_recipe All in one partition"  settings right?  (install currently asks for recipe and disk.)
<cjwatson> CarlFK: please ask me again after feature freeze
<CarlFK> oke
<Mez> any xen experts here?
<mathiaz> Mez: you'd better ask zul
<ArM-eye> amon-ra everyone
 * pitti grumbles about someone uploading partman-target without checking it into bzr; this caused a rejected upload for me
<ArM-eye> Do you want to read the reveal?
<ArM-eye> It involves biblical figures
<pitti> evand: can you please commit your partman-target changes to bzr? I already committed/pushed my own ubuntu4, so that needs to be merged
<ArM-eye> yes or no?
<ArM-eye> it must not be given against will
<bazhang> ArM-eye: you got kicked from #ubuntu for that
<evand> dear glade-3, stop renaming my widgets.  No love, Evan.
<tkamppeter> pitti, ping
<jpatrick> cjwatson: prehaps we should ban him? (just in case)
<cjwatson> jpatrick: *shrug* he hasn't come back yet, if he does then I will
<pochu> he was kicked by mdz on -meeting too
<neftune> he seems to be all over freenode
<jpatrick> neftune: network troll, then, anyone problems in #ubuntu channels, give us a call with !ops
<pitti> hi tkamppeter
<keescook> dang, missed dholbach
<pitti> hi keescook
<pitti> keescook: for the imagemagick sync?
<keescook> hiya pitti
<keescook> yeah
<keescook> I was looking at the API changes and was worried
<keescook> but if it's just two ftbfs, that's easy
<keescook> I'm still a bit worried about the ABI changes -- there might be issues no one has noticed yet
<tkamppeter> hi pitti, have you seen the HPLIP packages? Can you upload them before UVF?
<keescook> however, I'd really like to get the updated imagemagick into hardy for the LTS
<pitti> tkamppeter: yes, I will
<pitti> keescook: no problem, I can sync it right now if you want me to
<tkamppeter> pitti, when is the freeze exactly? At midnight UTC today or at midnight UTC at the end of tomorrow?
<pitti> tkamppeter: tomorrow evening, see slangasek's mail
<pitti> well, we deliberately don't specify it up to the second :)
<keescook> pitti: it needs a merge, unfortunately (small change for g++ 4.3 compilation)
<keescook> pitti: I've got it merged locally but was shy to upload it.  :)
<keescook> should I just do it?
<pitti> sure
<pitti> if it doesn't horribly break main
<pitti> keescook: is the gcc 4.3 fix upstream/in Debian's BTS, BTW?
<keescook> well, that's what I mean -- I'm unsure if the ABI changes are going to eat the world or not.
<keescook> pitti: not sure, doko did the ubuntu one, I will check for it.
<pitti> oh, btw
<pitti> I remember seeing an MIR for graphicsmagick
<keescook> eeek
<pitti> which was supposed to supersede and replace imagemagick
<pitti> but I haven't heard anything about this any more from the reporter
<keescook> I think graphicsmagick got attention because Debian hadn't moved imagemagick since 2005.  :P
<pitti> -- hardy/main i386 deps on libmagick9:
<pitti> imagemagick
<pitti> inkscape
<pitti> libmagick++9c2a
<pitti> libmagick9-dev
<pitti> libxine1-misc-plugins
<pitti> rss-glx
<pitti> keescook: ^ not too bad
<pitti> i. e. screensavers, inkscape, and xine
<keescook> I can make sure inkscape works.  ;)
<pitti> oh, and some build deps: human-icon-theme tangerine-icon-theme tango-icon-theme tango-icon-theme-common
<pitti> but I guess the CLI interface didn't change, just the internal library API?
<keescook> okay, I'm going to shove it in -- the list looks small enough that we can sort out problems if they come up.
<keescook> right, just the so bump
<keescook> though I have to wonder if people have lots of work-arounds built up due to bugs in the CLI behavior -- but that's no reason not to upgrade either.
<keescook> (yay alpha masking!)
<webwolf_27> tkamppeter, do those *.dsc files need to be IN the source packages? or accompanied?
<geser> webwolf_27: .dsc is part of the Debian source package (the others are the .diff.gz and .orig.tar.gz)
<webwolf_27> geser, thanks
<webwolf_27> does the *_source.changes belong in the archive as well?
<pitti> webwolf_27: source.changes are an upload vehicle, they aren't kept permanently
<webwolf_27> thanks pitti
<jdstrand> pitti, slangasek, et al: I am adding a profile that exists in apparmor-profiles to a package.  the profile is a conffile in both packages.  I know that Conflicts is not enough-- is there a standard way (ie docs) on how to move a conffile from one package to another?
<tkamppeter> webwolf_27, you do not need to make a tarball, you can put the 4 files .dsc, .diff.gz orig.tar.gz, and _source.changes simply into the same directory on the server. Then the whole kit can be directly passed over into the distro repos.
<webwolf_27> tkamppeter, thanks for the info
<tkamppeter> webwolf_27, but as I have to download the kit anyway to sign it you can also put the four files into one tarball.
<ionstorm> update manager should have a update history
<ionstorm> or does it already?
<webwolf_27> ok I'll tar em
<slangasek> jdstrand: these days, I think all you need is "Replaces"?
<jdstrand> slangasek: mathiaz and I were talking about Replaces
<jdstrand> slangasek: I was reading 7.5.1 of the policy and trying to make sure it did the right thing
<mathiaz> don't you need to conflicts also ?
<pitti> jdstrand: oh, for conffiles that's indeed quite some wizardry
 * jdstrand nods
<pitti> jdstrand: especially if you want to avoid dpkg conffile questions for modified ones
<slangasek> mathiaz: no, conflicts means "remove the named package before installing this other", and I think all you want here is to change the ownership of the conffile
<slangasek> I'm pretty sure that Replaces: now DTRT in dpkg
<jdstrand> I was thinking I needed to do a variation on http://wiki.debian.org/DpkgConffileHandling
<pitti> jdstrand: look at the udev preinst for an example
<jdstrand> but would be very pleased with Replaces
<pitti> jdstrand: yes, that has the recipes, too
<slangasek> yeah, that wiki page is for moving a conffile around, not for changing its ownership
<jdstrand> (hence the variation)
<pitti> for normal files it's Conflicts:/Replaces: package (<< version_that_moved_the_file)
<pitti> but conffiles are special
<slangasek> probably wouldn't hurt to /document/ on that page how to change ownership of a conffile
<pitti> tkamppeter: hplip uploaded
 * jdstrand goes to look at udev...
<slangasek> pitti: udev is moving conffiles around and removing them, which is again not what's happening here
<slangasek> fwiw, libldap-2.4-2 took over a conffile from libldap2 in the recent migration using nothing more than a Replaces:, and there've been no bug reporst
<pitti> it also has prep_mv_conffile() etc.
<mathiaz> jdstrand: apparmor profiles are not conffiles IIRC.
<jdstrand> !
<pitti> as long as it's a conffile which users won't likely change (like an init script), a simple replaces: will probably do
<jdstrand> mathiaz: let me check that
<pitti> mathiaz: erm, they should
<slangasek> pitti: but prep_mv_conffile() is also about moving the conffile to a different *location* on disk, not to a different package
 * jdstrand admits he *thought* they should be too, and therefore assumed
<tkamppeter> pitti, thank you.
<jdstrand> mathiaz: some are, some aren't
<jdstrand> the ones in question are
<jdstrand> well, it installs some conffiles.  others are in doc/ as examples-- nothing is installed as a configuration file
<mathiaz> jdstrand: right.
<jdstrand> slangasek: is libldap-2.3-0 completely gone?
<slangasek> jdstrand: long gone
<jdstrand> slangasek: that was part of my question-- apparmor-profiles should still stick around.  I wasn't sure Replaces wasn't too heavy-handed
<slangasek> jdstrand: oh, but libldap-2.3-0 isn't the package that owned the conffile, it was libldap2
<slangasek> which is not completely gone yet; it /should/ go, but the Replaces: in any case is IMHO correct for your use case
<slangasek> if apparmor-profiles is sticking around, though, it should be a versioned Replaces:
<jdstrand> slangasek: I will give it a shot
<jdstrand> slangasek: agreed
 * jdstrand really would not like to create another recipe for DpkgConffileHandling
<jdstrand> :)
<slangasek> take heart in the fact that if it hasn't been written before now, it's pretty likely that it's not needed. :)
<webwolf_27> tkamppeter, I'm uploading
<webwolf_27> tkamppeter, I'll let you know when they are up
<cody-somerville> Riddell: Hey.
<cody-somerville> Riddell: for bug 191322, I simply packaged it before debian did so I feel it can be synced.
<ubotu> Launchpad bug 191322 in libfile-basedir-perl "Sync libfile-basedir-perl 0.03-0.1from debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/191322
<webwolf_27> tkamppeter, The3 tarball should be on http://www.fam-schoenhaar.de/jeremy/packages/ in about 12 Mins.
<Riddell> cody-somerville: you misunderstand.  it would be nice to have it synced but that is impossible because the orig.tar.gz file is different (run md5sum on them)
<Riddell> cody-somerville: it can be synced next time there is a new upstream .orig file in debian
<webwolf_27> tkamppeter, did you get those tarballs?
<bddebian> Riddell: All of those sync requests were pre-emptive.  New uploads just went in to Debian today. :-(
<mathiaz> slangasek: are you planning to merge php5 before FF ?
<tkamppeter> pitti, I have prepared bug 25966 for the package upload into NEW
<ubotu> Launchpad bug 25966 in ubuntu "NEW PACKAGE: Printer drivers for Brother needed" [High,In progress] https://launchpad.net/bugs/25966
<tkamppeter> pitti, should I upload all the packages to REVU? They will make one REVU entry for each (10 entries).
<tkamppeter> Is it OK for the freeze when the packages are in REVU in time?
<slangasek> mathiaz: had no plans for it, no; I only touched the package to rebuild against libldap-2.4-2
<mathiaz> slangasek: ok. I'll work on the merge then.
<slangasek> mathiaz: enjoy :)
<cody-somerville> Riddell: Okay
<tkamppeter> webwolf_27, a small fix is still needed in your source packages: You need to delete all editor backup files (*~).
<Riddell> bddebian: that's pretty confusing then.  give me a ping when they're actually ready to process
<bigon> will the new queue processed before FF?
<bddebian> Riddell: OK, sorry, I just didn't want to miss the cut-off for Hardy.  BTW, there's one for lordsawar out there too that probably hasn't propigated in Debian either.
<ScottK> Riddell: If you have a moment, would you please accept clamav 0.91.2-3ubuntu2.3~feisty1 in feisty-backports (it's got two CVE fixes in it).
<Riddell> ScottK: done
<ScottK> Riddell: Thanks (my first 'core-dev' type upload BTW).
<pochu> ScottK: oh are you core-dev now? I didn't see any announcement. Congratulations :)
<ScottK> pochu: Thanks (just happened yesterday).
<bddebian> Whoa ScottK, congrats!
<ScottK> bddebian: Thanks.
<ScottK> bddebian: There were 4 others too (including TheMuso).
<bddebian> Dang
<geser> bddebian: when it's your turn? :)
<cody-somerville> Can someone please review http://revu.ubuntuwire.com/details.py?package=thunar-svn-plugin?
<cody-somerville> It requires one more advocation :)
<cody-somerville> mischan
<bddebian> geser: I'll never be worthy :-)
<cjwatson> keescook: openssh with selinux fix on its way into the archive now
<cjwatson> ogra: ^-- the above also includes consolekit support
<keescook> cjwatson: nice, I was _just_ looking at that.  :)  which archive do you mean, btw?  I see it just landed in Debian.  Did you do a sync in ubuntu too?
<cjwatson> keescook: I needed to branch the Ubuntu package for the consolekit support anyway so I just did an upload with that based on the Debian change
<cjwatson> so I meant both archives
<siretart> Mithrandir: yes, I'm tomorrow in the office again (finally!) and will look after sparky via serial console
<pochu> TheMuso: \o/
<gnash> anybody
<ion_> nobody
<gnash> okay
<gnash> i ws askin if anybody can listen to me
<ScottK> !ask | gnash (but not /topic and be on topic)
<ubotu> gnash (but not /topic and be on topic): Please don't ask to ask a question, ask the question (all on ONE line, so others can read and follow it easily). If anyone knows the answer they will most likely answer. :-)
<ScottK> not/note
<gnash> actually i m a very new user ..i even dont know if i m on right thread...here it goes i installed ubuntu gutsy yesterday and the sonund is not working at all..laptop is lenovo y series ...sound card is being detected....checked by lspci....sound not available to root even
<gnash> any suggestions
<ScottK> gnash: Then you should be asking on #ubuntu.  That's the channel for help.
<gnash> okay
<gnash> thank u
<gnash> join #ubuntu
<gnash> i think that is the command
<gnash> ?
<ScottK> gnash: Preceed the command with '/'
<keescook> seb128: do you have details about the pcre3 7.6 incompat issues?  I'm surprised that upstream broke -- they're usually very careful.
<jjesse> question in hardy which will be default firefox 2.0 or firefox 3.0?
<pochu> jjesse: 3
<jjesse> pochu: thanks
<lifeless> why does pulse hate me :(
<cjwatson>         modes.tmp.key 6 add dup length 1 add string /modes.tmp.str exch def
<cjwatson> sigh, RPN makes my head hurt
<lifeless> BenC: new kernel spam in hardy: [163017.896131] wlan0: switched to short barker preamble (BSSID=00:0c:41:f9:3f:12)
<lifeless> BenC: want a bug ?
<mjg59> cjwatson: I think I've got font restoration sorted, but the kernel does some weird things when switching from X. I'll want to look at that a little further.
<mjg59> cjwatson: Amusingly, there's already a font structure in the vt structure
<mjg59> It's just unused
<cjwatson> I think I remember noticing that and swearing
<cjwatson> thanks
<mjg59> Oh, and I need to spend a while looking at the locking
<mjg59> The VT layer is made of fail
<lifeless> yay, pkill pulseaudio restores my music.
<mario_limonciell> cjwatson, wading through debian/changelog from gfxboot, it looks like you brought it in from kanotix some time back.  what was the issue with bringing in grub-gfxboot at the same time (or was there one, or just not a priority)?
<cjwatson> mario_limonciell: not a priority, and would have required care in gfxboot-theme-ubuntu which I didn't have time to give it
<cjwatson> mario_limonciell: plus general consensus was that we didn't want to display a grub menu by default anyway
<mario_limonciell> cjwatson, ah i understand
<cjwatson> and the risk of things going wrong in grub is IMO greater than the risk of things going wrong at CD time
<cjwatson> because at that point you're talking about people's previously working systems
<cjwatson> so for all those reasons I steered clear
<mario_limonciell> cjwatson, would there be an opposition to my bringing it into universe (and letting it live there for now)?
<keescook> can someone familiar with grub and/or dpkg triggers look at 189173 with a +1/-1 ?
<mario_limonciell> at least in the sense of using the normal grub package (that's in main) with the gfxboot patch added on to it
<keescook> I believe it to be sane, but I wanted a second opinion
<cjwatson> mario_limonciell: IMO that should only be done if somebody commits to updating gfxboot-theme-ubuntu to work with it
<cjwatson> mario_limonciell: otherwise all it does is lead people down a wild goose chase
<cjwatson> keescook: looks fine to me
<mario_limonciell> cjwatson, do you know how much is involved with updating it?
<cjwatson> mario_limonciell: I don't think it should be done unless it's actually worthwhile. We shouldn't have useless packages in universe and large complex patches applied to our default boot loader.
<cjwatson> mario_limonciell: probably moderate amounts of work; bear in mind that gfxboot "themes" would in fact be better described as programmed boot loader menus
<mario_limonciell> cjwatson, well we have a use case that is going to be needing it, so it would be preferable that it lives in apt rather than has to go into the factory only
<cjwatson> you can't use gfxboot without a theme, and I doubt you want to use the SuSE one
<cjwatson> you really should investigate this part of it before pulling grub-gfxboot into the archive
<mario_limonciell> understood
<mario_limonciell> well with the impending feature freeze, that's little time to explore it, so I was thinking "get it in" and then sort out the dust right afterward
<cjwatson> the theme is a large part of the feature
<cjwatson> seriously, the name is quite badly misleading
<cjwatson> you are asking to get in a package that just will not work in any reasonable way
<cjwatson> it's a bit more than dust
<slangasek> keescook: the patch in 189173 looks sane enough to me, I'm more concerned about what goes on the other end of it :)
<cjwatson> I've not deliberately broken it for non-syslinux boot loaders, but I'm fairly sure it won't work as is
<cjwatson> and you absolutely need to know what's involved before committing to it
<keescook> slangasek: yes, me too.  I'm trying to find the part of the selinux packages that touches menu.lst.  :P
<slangasek> keescook: also, I'm not sure why this case warrants the complexity of a trigger, as opposed to having those other packages just call update-grub
<michaelfavia> bluez-utils most recent update 3.26-0ubuntu2 is suspiciously missing binary named hidd is this intentional?
<slangasek> the benefit of triggers is to defer all invocations until the end of a dpkg run, but there's no mention of getting the kernel packages to use this and those are the main consumers of update-grub today
<keescook> slangasek: well, it'd be nice if everyone who needed to run an update-grub would trigger it instead of running it each time separately, so I'm for it.
<keescook> true
<slangasek> fair enough
<michaelfavia> it isnt in the changelog and there is an existing question: https://answers.launchpad.net/ubuntu/+source/bluez-utils/+question/24516 would like to update ubuntu documentation to reflect chnages if change is known and intentional.
<michaelfavia> already had 2 support requests.
<mario_limonciell> cjwatson, okay thanks i'll double check with some folks on my team about it
<_MMA_> mario_limonciell: Skype?
<LaserJock> how many times is update-grub run generally for an average apt-get run? I wouldn't think it'd be that many
<soren> keescook, slangasek: libc6 has done this quite cleverly w.r.t. ldconfig. We don't need to touch the kernel packages at all, afaics.
<mario_limonciell> _MMA_, I won't be able to from here
<_MMA_> np. Hit me up later.
<_MMA_> (whenever)
<mario_limonciell> ok
<cjwatson> mario_limonciell: what's the use case here?
 * LaserJock hits _MMA_ 
<mario_limonciell> cjwatson, a localized grub menu is necessary
<_MMA_> :P
<mario_limonciell> cjwatson, and the only way that it seems to be possible to do (or at least has been done) was via the grub-gfxboot
<cjwatson> mario_limonciell: rather than a hidden grub menu, which is the Ubuntu default if at all possible?
<cjwatson> mario_limonciell: it's faintly possible that grub2 might be a saner approach here; there have been recent Planet Debian posts about its localisation support
<soren> keescook, slangasek: Short version: ldconfig has been replaced by a wrapper that checks if it's being called as part of a postinst running. If so, it triggers. If not, it just calls the real ldconfig.
<soren> We could do the same to grub quite easily.
<mario_limonciell> cjwatson, yeah we need to be able to provide locale specific options rather than a hidden grub menu
<soren> And by "we" I of course mean "someone who isn't me".
<soren> :)
<cjwatson> mario_limonciell: try grub2? with a bit of integration work, it might work better, and is already in the archive
<cjwatson> we're probably going to have to migrate to it eventually anyway, and it would be nice to have somebody trying it out
<cjwatson> grub-gfxboot will totally break with grub2 anyway
<mario_limonciell> cjwatson, okay will do, and with it  being in the archive that gives time for the integration work still then
<slangasek> soren: meh :)
<cjwatson> mario_limonciell: http://oskuro.net/blog/freesoftware/time-for-grub2-2008-02-09-17-53
<mario_limonciell> cjwatson, ah very good.  this does seem like a much more feasible route then as you say
<keescook> soren: :)
<cjwatson> mario_limonciell: on the flip side, grub2 is a new boot loader base and is untested in the Ubuntu context (though more people are beginning to try it out in Debian)
<cjwatson> mario_limonciell: but I think it's probably the same order of magnitude of work as grub-gfxboot, and less horrifically painful in the medium to long term
<mario_limonciell> cjwatson, indeed the additional testing that it would see from our usage would probably be beneficial to Ubuntu come the time to switch then
<cjwatson> right, rather than having to throw it away in a year's time or whatever
<mario_limonciell> okay thanks cjwatson
<soren> Wow... Singing and piano lesson spam.. That's a first.
<michaelfavia> hah
<soren> I hope they teach singing and piano better than they spell.
<ion_> I wouldnât mind spam that teaches me to play piano better.
<soren> ion_: I'm not complaining. :) Just saying.
<TheMuso> soren: lol
<soren> Oh, it's Argentinian. Some of it might just be dialect.
<persia> Riddell: wildmidi was both rejected and accepted.  Am I missing something?
#ubuntu-devel 2008-02-14
<gouki> Sorry about the offtopic, but .. what are the possible locations for a startup file to be? I've searched all the ones I know but can't find the script which is getting started at boot time (and I don't want him to).
<TheMuso> gouki: /etc/init.d
<TheMuso> gouki: You looked there?
<gouki> Did a -R ls on all folders, TheMuso
<TheMuso> WHats the package?
<gouki> synergys
<TheMuso> thats not in hardy...
<gouki> !?
<gouki> I don't get it. I'm not using Hardy
<TheMuso> Well I don't easily have access to gutsy atm
<TheMuso> so I can't check there
<soren> There was never a package called synergys in Ubuntu.
<soren> gouki: Are you using Ubuntu? :)
<gouki> I know there isn't a package called synergys. I'm talking about a script, not a package.
<gouki> The software is called Synergy
<gouki> What I'm asking is, where could this script be listed to start at boot time...
<TheMuso> gouki: dpkg -L syngergy will show you all files belonging to that package.
<TheMuso> syngergy even
<TheMuso> gah
<TheMuso> you know what I mean
<slangasek> TheMuso: but only if it's packaged, and he's suggested it isn't packaged
<TheMuso> slangasek: Right.
<TheMuso> Mind is sorta elsewhere, on other things.
<gouki> TheMuso: I have already done that. Still, no indication of the script on a startup directory
<gouki> BRB
<soren> keescook: Hmm... "sponsoring trigger creation patch "? Who wrote it?
<soren> keescook: ...and you forgot to add debian/grub.trigger
<soren> :)
 * keescook cries
<keescook> soren: fixed.
<calc> azeem: ping
<sparr_> after i apt-get source a package, i can build it with configure/make, but how do i build the package?
<LaserJock> sparr_: dpkg-buildpackage does that
<LaserJock> sparr_: https://wiki.ubuntu.com/PackagingGuide/Complete might be some good reading
<mgunes> was gthumb removed from the default install as part of hardy-reducing-duplication?
<RAOF> I believe so, yes.
<gnudles> hi
<gnudles> where can I find nautilus team?
<gnudles> I'm testing ubuntu alpha 4
<pitti> Good morning
<gnudles> yes, good morning...
<pitti> tkamppeter_: you can just upload them, so that they will be in NEW
<mvo> good morning pitti
<pitti> hey mvo
<gnudles> today is the feature freeze....
<gnudles> I have a question
<LaserJock> morning pitti and mvo
<gnudles> with the new nautilus, why can't I copy a file to the same directory?
<mvo> hey LaserJock
<LaserJock> mvo: I took care of desktop-multiplier, btw
<LaserJock> hopefully you won't be getting more emails about that ;-)
<gnudles> right... keep ignoring me...
<RAOF> gnudles: Have you checked out the nautilus bugs on launchpad?
<LaserJock> gnudles: I doubt people are ignoring you, probably they just don't know the answer
<RAOF> gnudles: This is possibly not the best place for such a question, either (#ubuntu-bugs or #ubuntu+1 are possibly better).
<RAOF> gnudles: Also, it works for me.  Although the question seems somewhat odd: why would you want to copy something to the same place?
<dholbach> good morning
<RAOF> Howdie dholbach!
<dholbach> heya RAOF
<gnudles> RAOF: If I want to copy a source file template for example
<RAOF> gnudles: Do you mean 'copying a file "foo" from mydir/ to mydir/ does not produce a file "copy of mydir"'?
<gnudles> it shows me a dialog
<RAOF> Of whether or not you want to overwrite the file with the same file, yes.
<RAOF> This seems to be not-totally-unreasonable behaviour.
<gnudles> "copy of foo" you mean...
<RAOF> Yes.  Of course :)
<gnudles> no
<gnudles> once it was like this
<RAOF> Ah.  So this is a regression from gnome-vfs.
<RAOF> File a bug.
<gnudles> today a dialog appears...
<gnudles> another thing
<gnudles> in the dialog, you can add option for renaming if a file with the same name already exists...
<mvo> LaserJock: thanks!
<RAOF> gnudles: A valid feature request.  Again, file a bug :)
<gnudles> ok
<gnudles> great! firefox 3 at last...
<gnudles> :)
<gnudles> crap!!!!!! all my bookmarks disappeared :,(
<DktrKranz> Could a buildd-admin give-back hdf5 on lpia? Thanks.
<pitti> DktrKranz: nothing to give-back, it's in depwait
<pitti> mvo: should that worry me? "Fehl http://archive.ubuntu.com hardy Release"
<pitti> mvo: at the end it complains about not being able to access the keyring
<mvo> pitti: possible, can you paste me the exact error message?
<DktrKranz> pitti: oh, indeed! I misread. Sorry.
<pitti> mvo: http://paste.ubuntu.com/4582/
<mvo> pitti: what does apt-key list say?
<pitti> 'gpg: SchlÃ¼sselbund `/etc/apt/trusted.gpg' erstellt'
<pitti> oh, I bet I know
<mvo> meh
<pitti> mvo: I ruined my file system yesterday (silly error)
<pitti> and lost some files
<mvo> *PPUUUHHH*
<mvo> thanks
<mvo> I was very worried for a moment :)
<pitti> I should really reinstall this box
<mvo> pitti: if you have the latest apt, please run "apt-key net-update"
<mvo> just for the fun of it
<pitti> right, but to get this I need apt-get working :)
<mvo> heh :) ok, if you don't have a current one, then yes
<mvo> "sudo apt-key update" may also help, depending on the damage on the FS
<pitti> mvo: yep, that helped
<mvo_> hey glatzor__
<glatzor__> morning mvo!
<tjaalton> pitti: hi, I uploaded a new nvidia-settings which enables the binary again (sigh :), but the old upload was already sitting in NEW, so should I do something special?
<pitti> tjaalton: let me reject the old one then to avoid confusion
<tjaalton> pitti: ok thanks!
<pitti>  412897 | S- | nvidia-settings      | 1.0+20071221-0ubuntu | five days
<pitti>          | * nvidia-settings/1.0+20071221-0ubuntu1 Component: multiverse Section
<pitti> tjaalton: ^ so this should be killed?
<tjaalton> yes
<pitti> done
<tjaalton> rock!
<tjaalton> it turned out that the binary nvidia-settings shipped with the drivers is buggy, and the separate version can be patched so..
<glatzor> mvo: I am currently turning apt-dbus into an extra backend, so that it can be merged in the main repository
<tjaalton> this should be a win-win
<glatzor> mvo: but the dbus backend infrastructure is still a moving target.
<glatzor> mvo: is there a similar function to git log -p in bzr?
<bryce> hi glatzor
<tkamppeter_>  piiti, you mean I can directly dput them into Multiverse?
<glatzor> servus bryce.
<glatzor> how are you progressing?
<bryce> glatzor: pretty well - http://bryceharrington.org/files/screenrez_a.png
<glatzor> bryce: have you found any aspects in my user interface that you could reuse?
<bryce> glatzor: definitely; I borrowed a lot of the layout and the icons
<glatzor> takes some time ... I am currently participating in the worldwide I-have-got-the-slowest-internet-connection-contest :)
<bryce> glatzor: mpt's mockup he did for you was also quite inspiring
<glatzor> bryce: you had to skip the fancy widget part?
<glatzor> bryce: has sÃ¸rensen already started on the widget?
<bryce> glatzor: yeah, I evaluated the time I had until FF and decided that was going to be too ambitious
<glatzor> bryce: really cool
<bryce> as it is I'm a couple days before
<bryce> er, behind
<glatzor> bryce: really nice
<mvo_> bryce: have you heard anything from upstream yet? if they like it?
<tjaalton> sandmann replied
<bryce> I don't completely understand what sorensen's working on, but it looks quite different from our concepts.  I don't understand how it's implementing multi-screen
<tjaalton> bryce: did you see soerens reply?
<bryce> sorensen said it's all in there, but I guess I'd need to study it more to see how it does it
<soren> pochu: I've not sent the extended key event stuff to Debian on purpose.
<glatzor> tjaalton: bryce: have you seen any code of his planned x extension? he wanted to add fade effects
<bryce> I tried compiling and running his code, but the only piece I could get to run didn't do anything
<tjaalton> glatzor: nope.. sounds nice
<soren> pochu: It's not completely finalised.
<soren> pochu: In Ubuntu I have control over both ends of the wire.. In Debian, not so much.
<glatzor> bryce: the actual monitor handling is now done by gnome-settings-daemon?
<tjaalton> hum, the vmware-stuff in lrm is ancient
<glatzor> bryce: does gdm now use the settings-daemon in ubuntu?
<bryce> tjaalton: yeah I don't know what to think of the reply.
<soren> tjaalton: There's vmware stuff in lrm?
<tjaalton> soren: yes, player, server, tools
<soren> tjaalton: Oh, that.
<tjaalton> soren: not built in hardy
<soren> tjaalton: Right, I remember now.
<bryce> glatzor: I've not gotten to the gnome-settings-daemon part yet
<ivoks> question for kde people; libqwt5-qt4-dev - any plans to move this in main?
<glatzor> bryce: what are your plans for handling the new overriding nature of xorg.conf?
<bryce> glatzor: redhat is developing a patch against gnome-settings-daemon to expand how it handles the monitor setup. I haven't looked at it though.  But it would seem most sensible to follow their design.
<tjaalton> soren: do you know if we have the right to update those?
<tjaalton> copyright doesn't mention anything
<soren> tjaalton: No clue. Sorry.
<bryce> glatzor: well, the work I'm doing is only for cases where xorg.conf does not need modification
<tjaalton> soren: ok, no worries :)
<bryce> glatzor: for situations where people do need to override things in xorg.conf, we'd need a different tool.
<bryce> glatzor: there is also the case of bulletproof-x, which will need that kind of a tool as well
<tjaalton> bryce: I'll bring back "Device" in the Screen-section, which should at least make aticonfig and nvidia-settings to work again
<glatzor> bryce: how does pitti now deals the proprietary driver installation?
<bryce> tjaalton: good idea
<bryce> glatzor: sorry, don't understand the question?
<glatzor> bryce: yeah, funny grammar
<bryce> heya soren
<soren> bryce: Hey.
<glatzor> bryce: how does the restricted drivers tool change the driver in the xorg.conf now?
<bryce> tjaalton, glatzor:  I've been having fun today screwing up my monitors by hitting Apply on this gui.  ;-)
<tjaalton> hehe
<bryce> glatzor: ahh - I gather that's what tjaalton was just referring to via aticonfig and nvidia-settings
<tjaalton> not really
<bryce> no?
<tjaalton> jockey works right now, but aticonfig crashes
<tjaalton> just like dc-gtk :)
<bryce> heh
<tjaalton> nvidia-settings fails to write the config, which actually is a blessing since it would write all sort of crack
<mvo_> dosn't jockey use the displayconfig code for the modifications?
<glatzor> mvo_: I haven't followed the jockey rewrite
<bryce> mvo_: I knew that envy uses guidance-backends now, but didn't know that jockey did too
<glatzor> bryce: the rate configuration won't be allowed in your tool? or just not yet implemented?
<bryce> glatzor: it's there - but it's smart now; if you only have one rate available, it displays as a label rather than a dropdown
<pitti> glatzor: jockey still uses guidance-backends nowadays
<glatzor> bryce: doesn't this result in small flickering when changing screens?
<glatzor> pitti: hello
<pitti> hi glatzor!
<glatzor> bryce: you could also disable the combo box.
<bryce> glatzor: for LCD's (which is what I took the screenshot on) 60 Hz is fine
<bryce> glatzor: true...
<glatzor> bryce: flicking of the user interface, since it has to replace a widget when you select a different monitor in left chooser
<bryce> glatzor: oh, no it's perfectly solid
<bryce> I need to figure out how to do screencasts or something
<glatzor> bryce: what is the primary status? does the applet move the panels to a different screen when it is set?
<glatzor> bryce: I would be careful with the same-as position, since it requires that the screens have got the same resolution
<glatzor> bryce: that is why I had three radio buttons (disable, extend, clone)
<bryce> glatzor: the 'primary' is basically what I'm calling an output that other outputs are relative to
<bryce> glatzor: however it's been proving ornery in the coding so I'm not sure having a 'primary' screen adds that much
<bryce> glatzor: yes you're right about the same-as (aka clone or mirror).  It probably will take a lot of testing to get right.
<glatzor> bryce: how do handle the virtual size issue?
<bryce> glatzor: right, that's a remaining issue
<bryce> glatzor: I decided to focus on only non-xorg.conf changing functionality
<glatzor> bryce: the other parts can perhaps never be done right :)
<bryce> glatzor: my thought is to use a script or something attached to an Advanced button or something to update Virtual, but I'm ignoring it for now
<glatzor> advanced buttons are evil :)
<bryce> yeah yeah
<bryce> well ultimately (maybe xserver 1.5??) it'll become unnecessary to specify Virtual anyway
<glatzor> bryce: perhaps a small check if the virtual size allows to display two displays could be added to the applet
<bryce> glatzor: yup
<bryce> also since increasing virtual often results in forcing DRI/Compiz to have to be turned off, I thought a popup dialog warning the user might be of value
<glatzor> bryce: indeed
<RAOF> bryce: Thinking of xrandr, do drivers other than nouveau suffer from http://bugs.freedesktop.org/show_bug.cgi?id=14394 ?
<ubotu> Freedesktop bug 14394 in Driver/nouveau "[NV4B] Composite broken on 2nd head" [Normal,New]
<RAOF> The fact that the patch is against the X server makes me think so, and it's a really curious bug to run into.
<bryce> interesting
<bryce> RAOF, for most typical multi-head systems (at least ones I've played with), compiz gets disabled entirely because you go beyond the Virtual limits
<RAOF> bryce: But this kills metacity (& Kwin I think) too.
<bryce> RAOF: hrm
<RAOF> Metacity as of .8 uses the COW.
<tjaalton> compiz 0.7 should have "multi-head support", but I'm not sure what it means here
<bryce> RAOF, hmm, well this is a configuration I've not really tested myself much
<bryce> RAOF, offhand it does sound driver-specific, but I don't really know; I've never run anything like this
<tjaalton> RAOF: have you tried the patch yet?
<stgraber> moin
<RAOF> tjaalton: Not yet.  I mean to grab our X package and add the patch, but I haven't tried yet.
<mvo_> tjaalton: this is really more about the window managment capabilities, those got improved a lot for multihead in compiz 0.7
<RAOF> bryce: I don't have a non-nvidia card handy to test, but if you've got an intel cand or somesuch that bug should be easy to trigger, if it exists.
<tjaalton> RAOF: hmm, I have an intel box next to me, and it could borrow the monitor from the Sunray terminal ;)
<glatzor> mvo_: how can i see the diff of a commit after adding the "content" to the commit?
<glatzor> mvo_: any git gurus around?
<cjwatson> git diff --cached
<glatzor> cjwatson: thanks a lot
 * ogra would so love to not find a frozen laptop on his desk every morning ... *sigh*
<Riddell> ivoks: no, why is it needed?
<ivoks> Riddell: i'm asking cause this lib is needed for bacula's QT console
<ivoks> since we are moving bacula to main, we'll have to drop qt console :(
<ivoks> or build it for universe...
<Riddell> ivoks: so write a MIR for libqwt5-qt4-dev
<iRon> Riddell: ping
<ivoks> Riddell: that crossed my mind too...
<iRon> Riddell: could you please check your mail
<Riddell> iRon: doing so
<pitti> cjwatson: do I need to pay attention to something special when I'll change the seeds for e. g. slocate -> mlocate?
<pitti> cjwatson: e. g. I guess I should add that to the platform.hardy branch?
<cjwatson> pitti: platform.hardy/desktop-common has dlocate
<cjwatson> err, slocate
<cjwatson> so it makes sense to change that, along with ubuntu.hardy/server-ship
<cjwatson> although as I said on ubuntu-devel I think it ought to be in platform.hardy/standard really
<pitti> cjwatson: right; so changes in platform.hardy will be picked up by *-meta/running update, not by merging to the other *.hardy seeds?
<pitti> cjwatson: I agree about standard (and removing it from desktop and server-ship)
<pitti> cjwatson: hm, installing mlocate doesn't remove slocate
<cjwatson> pitti: changes> right
<cjwatson> pitti: yes, seems to be intentional to ease migration, although I see the problem you're raising
<pitti> I don't see anything in /etc/cron.daily/slocate  that tests for mlocate presence
<cjwatson> pitti: however, we could fix this by changing slocate's cron job not to run if mlocate is there
<cjwatson> much like locate's cron job does
<pitti> ah, it sets the /etc/alternatives/updatedb to mlocate
<cjwatson> well, sort of does, it checks whether it's been diverted
<cjwatson> [ -e /usr/bin/updatedb.findutils ] || exit 0
<cjwatson> pitti: yes, though /etc/cron.daily/slocate runs slocate explicitly
<cjwatson> so how about:
<cjwatson> -if [ -x /usr/bin/slocate ]
<cjwatson> +if [ -x /usr/bin/slocate ] && [ ! -x /usr/bin/mlocate ]
<cjwatson> the only downside I can see is that it'll mean that running slocate explicitly won't work any more, but I'm not too concerned about that
<pitti> why not simply add a Conflicts:/Replaces:?
<cjwatson> update-manager can deal with encouraging people to remove it, rather than requiring a hard Conflicts
<cjwatson> I don't like adding Conflicts arcs when we don't have to
<pitti> it would mean to leave package cruft around
<mvo_> sure, we can add it to the obsoleted packages
<pitti> but right, I guess we'll demote slocate
<mvo_> in update-manager
<pitti> and then u-m will clean it up, right?
<cjwatson> pitti: I think update-manager is good enough, yeah
<pitti> ... checking rdepends ... right, slocate has no rdepends at all (except *-desktop)
<cjwatson> uploaded slocate with the above diff
<pitti> thanks
<mvo_> cjwatson: I added slocate to the forced obsoletes, that means that for most people it will get removed (unless they object of course)
<cjwatson> great, thanks
<pitti> ok, mlocate MIR looks good, thanks for the great and detailled review
<pitti> cjwatson: I'll do the seed changes, promotions, etc. now
<cjwatson> hooray
<pitti> cjwatson: I won't update *-meta yet, since the component changes need to get published first
<xivulon> evand, heno, can you please apply the following patch to umenu? http://paste.ubuntu-nl.org/55953/
<xivulon> cannot ssh from here
<pitti> cjwatson, mvo_: hm, should mlocate in standard be a recommends or a strict depends? (I lean towards recommends)
<pitti> server didn't depend on it so far either
<cjwatson> pitti: recommends, IMO
<cjwatson> I'm surprised it isn't already a recommends in desktop-common
<pitti> just an oversight, I think
<cjwatson> hmm, we could do with new language-support-* for the firefox upgrade
<pitti> cjwatson: the split? that's on my list for today
<cjwatson> I think actually it's that we need new mozilla-firefox-locale-*
<pitti> ah, right
<edwin_> does anyone prefer grid layout over embedding hboxes in vboxes and vice versa?
<persia> Does anyone have a timestamp for start of FeatureFreeze?
<pitti> cjwatson, mvo__: AFAIK the installer and gnome-language-selector will get along if a language does not have a language-support-XX package, right? I'd like to remove all the ones with an empty Depends: to remove some cruft
<pitti> as a preparation to merging/using ArneGoetje's 'split support packages' branch
<pochu> persia: the end of the day in the last timezone of the world oh please :)
<cjwatson_> pitti: sure
<cjwatson> pitti: oh, err
<persia> pochu: Maybe.  Something like 12:00 or 24:00 UTC would work as well.  I just want guidance on when to stop accepting UUS stuff that hasn't been pushed for FFe.
<cjwatson> pitti: the installer will warn and say that the CD doesn't contain full support for your language
<pitti> persia: I don't think anyone will measure that precisely
<persia> pitti: OK.  I won't fuss about it then, and just stop sponsoring when it stops being a reasonable "14th February" for me.  Thanks.
<pitti> cjwatson: oh, even if there is a language-pack-XX in the archive, but not a -support one?
<pitti> persia: sounds pragmatic and appropriate
<pitti> cjwatson: well, I can leave them around for a while, they'll be practically orphaned
<cjwatson> pitti: the check is for what's on the CD
<cjwatson> pitti: in practice it'll always have fired for !en anyway
<cjwatson> pitti: so it might well not matter; it only does that check for CD installs
<pitti> right, we'll retain language-support-en anyway
<cjwatson> I don't particularly mind if empty language-support-* go away
<pitti> cjwatson: I meant the bits that try to install support and -pack from the network
<pitti> ISTR reading the code and seeing that they are tried independently
<cjwatson> they are, and it shouldn't care if they fail either
<pitti> ok, great
<zul> piti: for munin it should be running as a munin user not nobody correct?
<pitti> zul: yes; doko indicated that it already does that, though
<pitti> so it might just have been a misunderstanding
<zul> ok
<tkamppeter> pitti, hi
<pitti> hi tkamppeter
<tkamppeter> pitti, I have corrected the .changes file from s-c-p, was I typo in the old version number, can you upload it now?
<pitti> tkamppeter: ok
<tkamppeter> pitti, I have also all files of the Brother driver now, should I put them directly into Multiverse?
<pitti> tkamppeter: if you think the packaging is ok now, then please just upload them, so that they'll land in NEW
<zul> pitti: ill leave as it is then
<pitti> tkamppeter: setting Section: multiverse/text would be good, yes
<pitti> (but it's just a bonus)
<tkamppeter> With the section, I will tell it to the packagers, that they can correct that in a later version.
<pitti> tkamppeter: btw, you know that you don't normally need to use -v, right? just for merges
<tkamppeter> So without -v it defaults to take simply one ChangeLog entry?
<pitti> right
<pitti> tkamppeter: nevermind about Section: we'll override it to multiverse in the NEW queue
<persia> tkamppeter: Yes.  Note that it is always safe to use -v with an rmadison call to get the current version, even if you are just doing a standard update.
<pitti> tkamppeter: scp uploaded
<tkamppeter> pitti, thanks.
<glatzor> mvo__: I would like to move the description formating done in UpdateManager/AppInstall and the changelog fetching method to python-apt
<MacSlow> I need some MOTU-help
<MacSlow> how do I make sure a file gets installed in /usr/share/compizconfig, which has been added via a debian/patch/02_some.patch?
<MacSlow> obviously adding the usual bits to Makefile.am and creating a 99_autoreconf.patch does not seem to be enough
<MacSlow> help greatly appreciated
<persia> MacSlow: For MOTU-help, asking in #ubuntu-motu is a good idea.  You might find using debian/$(package).dirs to help, or debian/$(package).install, depending on the contents of your rules file.
<mvo__> glatzor: sure, that sounds reasonable
<frafu> doko: are you Matthias that reviewed the following MIR: https://bugs.edge.launchpad.net/ubuntu/+source/mousetweaks/+bug/190208
<ubotu> Launchpad bug 190208 in mousetweaks "Main Inclusion Report for mousetweaks" [Undecided,Incomplete]
<jdstrand> pitti, slangasek: thanks for your help with migrating a conffile from one package to another
<jdstrand> pitti, slangasek: what I ended up implementing was slangasek's suggestion, with the addition of a versioned Conflicts
<pitti> jdstrand: you're welcome
<jdstrand> pitti, slangasek: you can see what I came up with at https://wiki.ubuntu.com/ApparmorProfileMigration
<jdstrand> pitti: and I should also thank you for your apparmor/cupsys work-- as I used it as a template ;)
<pitti> heh, good to hear if it was useful
<jdstrand> totally
<azeem> calc: pon
<azeem> g
<calc> azeem: hi
<azeem> heya
<calc> azeem: i heard you were going to be updating opensync in debian?
<azeem> well
<azeem> if the upgrade path is reasonably clear, I would, yeah
<calc> azeem: going from 0.19 -> 0.2x isn't clear?
<azeem> no, both the database and the configuration format has changed
<calc> azeem: hmm
<azeem> there's now a configuration updater for 0.3x, but I haven't tested it
<calc> maybe put a debconf message saying its not backwards compat would work? 0.19 is 10 releases old
<azeem> it should be possible to just wipe the database and do a slow-sync
<azeem> that'd be the emergency cop-out maybe, yeah
<calc> well it hasn't been updated in 16 months...
<calc> perhaps its a the DD doesn't want to do the extra work cop-out instead?
 * calc doesn't know the details of the work involved but 16 months is a relatively long time
<asac> calc: in which binary package is the openoffice firefox/mozilla plugin btw? i installed openoffice.org but don't see anything ooo related in /usr/lib/firefox/plugins
<calc> looks like not much else uses the libraries, etc except opensync itself so its not a really nasty conversion
<azeem> calc: it's rather the DD hoped 0.40 would be ready in time for hardy cop-out
<calc> azeem: ah i see :-)
<calc> azeem: mozilla-openoffice.org
<azeem> eh?
<azeem> s/azeem/asac/ I assume
<calc> azeem: oh yea
<geser> pitti or Mithrandir: please give-back: bzr doxygen. Thanks.
<calc> asac: mozilla-openoffice.org
<calc> asac: its only available on i386/powerpc
<calc> asac: its broken on the other archs aiui
<Mithrandir> geser: given-back
<azeem> calc: I can upgrade those packages in Debian (in fact, the only reason I consider it now is because of hardy, lenny should be fine for 0.40), but how much time do I have?
<asac> calc: ah ... ok. that explains it
<azeem> I got work to do now, and today is Valentine's day...
<asac> calc: any progress?
<pitti> geser: Mithrandir beat me to it
<Mithrandir> pitti: and I didn't even use a script. :-P
 * asac wonders how comes that its avail on powerpc ... strange
<pitti> Mithrandir: I repaired mine, but it was too slow
<calc> azeem: aiui part of it is holding up synce 0.11 upload, but i don't know the details (which was why i was asking about it)
<Mithrandir> pitti: smart bookmarks in ff are quite fast ("us $packagename"), then one click to get to the latest build, then a click on a button per failed build.
<calc> asac: i hope to have something by tomorrow, i have a few other patches to integrate as well
<pitti> Mithrandir: I typed "giveback bzr doxygen"
<Mithrandir> I wish LP had something like https://launchpad.net/distros/ubuntu/hardy/+source/glibc/latest
<pitti> I haven't installed geasemonkey for ff 3.0 yet
<asac> calc: ok ... great. if you have questions let me know. maybe do a testbuild so we know that this is really pending
<azeem> calc: yeah right
<azeem> calc: I was rather asking, "If I don't upload today (missing FF), will somebody be able to get those packages synced for hardy still?"
<calc> azeem: heh i just notice opensync is actually in main, so you would have to ask slangasek about that i guess
<calc> azeem: and/or follow the FF exception page on wiki
<asac> carlos: any ETA on ffox 3 locales?
<asac> carlos: we would need them asap i guess
<Mithrandir> asac: what does Could not find compatible GRE between version 1.9b3pre and 1.9b3pre.
<Mithrandir> mean?
<asac> Mithrandir: which application? i means that an application cannot find the right xulrunner
<asac> it looks in /etc/gre.d/
<Mithrandir> asac: firefox-3.0
<asac> thats strange ... did you hold back xulrunner-1.9?
<Mithrandir> no
<Mithrandir> but firefox-3.0 is held back
<asac> Mithrandir: ok that explains it. what holds your firefox 3 back?
<Mithrandir> locale stuff
<Mithrandir> (yes, I saw you talked about it above)
<asac> yeah ... ok i should have added a breaks as well
<asac> Mithrandir: yeah ... you have to live without locales for a while. i want to get an ETA from carlos who promissed that we get locales from launchpad this time
<asac> if its too long i will just package new upstream versions the old way i guess
<Mithrandir> asac: a "Breaks" would have been useful.. so I wouldn't have upgraded xulrunner or whatever breaks firefox.
<bddebian> Riddell: If/when you get around, do you want me to revive those sync requests for etw,qonk, etc now that they have hit unstable, or just let you know here?
<asac> Mithrandir: can you still downgrade xulrunner-1.9?
<Riddell> bddebian: what's the 'etc'? then I can just do it
<asac> i will upload a new xulrunner with breaks asap then i guess
<bddebian> Riddell: Sorry, etw, dd2, and qonk
<Mithrandir> asac: yes, by hand.  If I can find a web browser so I can get to launchpad so I can fix my web browser..
<Mithrandir> seems like 2.0 still works.
<bddebian> Riddell: I don't think you marked the lordsawar one invalid right?  It should be there now also.
<Riddell> hmm, someone is already doing syncs? pitti?
<pitti> Riddell: no, I'm not
<asac> Mithrandir: thats luck
<Riddell> cjwatson: are you doing syncs?
<cjwatson> Riddell: no, it's seb128
<cjwatson> (I looked in ps and w earlier)
<Riddell> ok, bit confusing of him
<Riddell> maybe he's done his 35 hours for the week :)
<Riddell> bddebian: I've set them up, I guess seb will come back at some point and flush them
<bddebian> Riddell: Thanks
<tkamppeter> pitti, I have uploaded the packages now. They should appear in the NEW queue now.
<tkamppeter> pitti, what will happen with the packages now to get into Multiverse or Restricted?
<pitti> multiverse
<undertaker> all:
<slytherin> Does anyone know why this bug is not actually fixed even though it says fix released - bug 178525 The service files are still missing.
<ubotu> Launchpad bug 178525 in bluez-utils "no available bluetooth services" [Undecided,Fix released] https://launchpad.net/bugs/178525
<slytherin> StevenK: ping
<juliank> Any chance to get ndisgtk into main? - Bug #191860
<ubotu> Launchpad bug 191860 in ndisgtk "Main Inclusion Report for ndisgtk" [Undecided,New] https://launchpad.net/bugs/191860
<slytherin> StevenK: I believe you fixed that bug related to service files. But there are actually no service files installed.
<neighborlee> is  it true  gthumb has been removed from hardy ?
<neighborlee> if so why
<pitti> neighborlee: just from the default install
<ion_>     gthumb | 3:2.10.6-0ubuntu3 | http://archive.ubuntu.com hardy/main Packages
<neighborlee> pitti, may I ask why
<neighborlee> oh wait..cause fspot is enough ;)
<pitti> neighborlee: we ship f-spot by default and taught it about a 'destination directory' for import, which was deemed sufficient
<neighborlee> fspot has no animation support ..or so I h ear is that correct ? ( maybe this is wrong  venue to discuss this , but I wanted to verify)
<neighborlee> and honetly I still think a patent discussion about mono is stil relevant isnt' it ?
<neighborlee> or is that off limits
<neighborlee> if so where should I discuss it ;)
<pochu> On debian-legal? :P
<neighborlee> LOL
<pochu> It's in Debian Main.
<pochu> And we trust Debian. We are even less strict...
<neighborlee> im just saying im being forced to use something that has less features and take more disk space and has 'patent issues' ;)
<pochu> Is this another "let's kill mono" thread?
<neighborlee>  I dont feel good about that ;)
<neighborlee> it is not.
<neighborlee> its a legitimate question about linux future ;)
<neighborlee> I dont know where else to h ave this discussion honestly :)
<neighborlee> the forum is a joke, as it wont get anywhere.
<neighborlee> devs hang here typically.
<neighborlee> though I dont kn ow h ow many of you know about the patent issues..or if im just not aware of the entirety of it all
<neighborlee> it sounds like a mess to me.
<neighborlee> but I dont want to come across like a complainning bitch either ;)
<pochu> neighborlee: regarding those /patent issues/, that's not up to the devs, but to the archive admins. And I tried once f-spot and it looked nice to me, except that it copied all my pictures, but that's fixed now I believe.
<neighborlee> it is nice visually
<neighborlee> but IF what im told is right..
<neighborlee> it has no animation ability
<neighborlee> gthumb does , or so in told.
<neighborlee> but if they are going for 'visual' I guess I understand    ..but im still not sure about this patent crap it sounds very IFFY to me.
<slytherin> neighborlee: By animation do you mean slideshow?
<neighborlee> but I suppose this isn't quite the right venue :(
<neighborlee> slytherin, no
<neighborlee> im told it wil import animations , where suposedly fspot wont
<neighborlee> or so im told.
<ion_> Video support would be nice indeed.
<neighborlee> yes indeed
<slytherin> neighborlee: So you have based your discussion on what someone have told you, not what you have actually seen.
<neighborlee> slytherin, I see no reason they would lie.
<neighborlee> typically ubuntu users aren't liars.
<pochu> neighborlee: I see no reason why the archive admins will include software with patent issues.
<neighborlee> hmm let me try to verify
<neighborlee> typicallly I would agree
<neighborlee> one would think ;)
<neighborlee> assuming they are aware of all the ramifications.
<slytherin> neighborlee: No. What I am saying is that if you use f-spot and really feel that it is inferior to ghtumb, sure go ahead and file a bug with all the points. As far as I am concerned f-spot rocks
<neighborlee> rocks is irrelevant
<neighborlee> disk space,,memory consumptioin stabiloity and patent issues IMO loom largely
<neighborlee> but as I say im not sure this is the RIGHT venue for that disucssion
<neighborlee>  ;)
<neighborlee> im not sure where the right place is honestly for it ;)
<ion_> I have had no problems with disk space or memory consumption, it has been stable, and personally i couldnât care less about patent trolls.
<neighborlee> ion_, I hope your not calling me a troll ;)
<ion_> Nope, unless you own stupid software patents.
<neighborlee> I dont ;)
<neighborlee> I defintely dont
<slytherin> neighborlee: When I say rock, it includes everything you mentioned except I don't think there are patent problems. It is just FUD.
<neighborlee> that is the claim yes ;)
 * ScottK wonders if any of these patents have numbers?
<neighborlee> im not so sure its right.
<cjwatson> neighborlee: if there are *real* patent issues to discuss, then let's discuss them on a case-by-case basis. But we cannot have a conversation about imponderable speculation.
<neighborlee> well in part  think I worry about stability of mono aps..I mean just look what happened to beagle ,,it got replaced by  someething else..makes you wonder about mono apps in general if you ask me..and its not like there aren't alternatives to fspot and  tomboy both, but then trouble is half agree, and slightly over half agree mono shoudl be gone..at least the forum shows those numbers anyway..but then I undersgtand ubunt is a meritoc
<neighborlee> racy ;))
<cjwatson> beagle's lead developer lost interest, AIUI; I don't think that necessarily says anything about the implementation language
<neighborlee> cjwatson, ok what about the latest lawsuit against novel and redhat..is that legit or something  totally separate
<neighborlee> cjwatson, possibly
<cjwatson> which lawsuits?
<neighborlee> you dont know about it???
<neighborlee> o_0
<cjwatson> there have, as I understand it, been a number of companies suing them at various times
<pochu> emilio@pochu:~/dev/projects/revu/trunk$ apt-cache show f-spot gthumb | grep ^Size
<pochu> Size: 1426538
<pochu> Size: 1367408
<pochu> ^-- disk space doesn't look like a very strong argument...
<neighborlee> cjwatson, is the one where novel paid M$ 42billlion in damages
<neighborlee> cjwatson, with no specifics as to why they did
<ion_> neighborlee: Itâs not fair to compare F-Spot to Beagle. Beagle feels bloated and resource-hungry. F-Spot does not.
<cjwatson> neighborlee: reference, please
<neighborlee> im jus saying they both use the same language...
<neighborlee> cjwatson, let me find please hold
<cjwatson> are you referring to http://www.groklaw.net/article.php?story=20071011205044141 ?
<neighborlee> let me see
<neighborlee> cjwatson, do you at least know about the forum discussion on ubuntu about removing mono ?
<neighborlee> if not you shoudl read it..20 pages or so but if you read fast its no biggie ;)
<neighborlee> its informative imo
<neighborlee> cjwatson, im not sure if that is the one, but its one of them yes...
<pochu> We have seen the threads in ubuntu-devel-discuss@ and they lead to nowhere IMHO.
<slytherin> can someone take a look at debdiff attached to bug 178525. It should re-fix the bug and another bug 191704
<ubotu> Launchpad bug 178525 in bluez-utils "no available bluetooth services" [Undecided,Confirmed] https://launchpad.net/bugs/178525
<ubotu> Launchpad bug 191704 in bluez-utils "hidd binary removed form bluez-utils package unable to connect as a result" [Undecided,Confirmed] https://launchpad.net/bugs/191704
<cjwatson> neighborlee: given that Novell's revenue for the financial year 2007 is about $1 billion, I'm afraid I don't believe your "42billion in damages" claim, hence my request for a reference
<ion_> neighborlee: If F-Spot or Mono infringe on some patents, feel free to point out the patent numbers.
<neighborlee> pochu, http://ubuntuforums.org/showthread.php?t=594767 < ok sorry i should have offered url...it is tha tone
<cjwatson> neighborlee: it is not the first such thread, and I have read previous ones
<neighborlee> cjwatson, and whlie its not staggering.more want it gone than want it to stay ..
<cjwatson> forum votes are interesting, but not binding on Ubuntu development
<neighborlee> cjwatson, I agree
<cjwatson> we have taken a decision on this before
<cjwatson> the current archive reflects that decision
<neighborlee> what about the wiki that was submitted about mono removal ?
<\sh> 14th Feb -> FF means "last day to push new stuff in" or "after 13th 23:59:59" no new stuff,please?
<neighborlee> did that even get discussed ?
<cjwatson> at some point you have to stop endlessly revisiting decisions unless concrete new evidence regarding patents is brought forward
<cjwatson> rather than vague claims
<neighborlee> was it submitted by a team member or just a regular user
<cjwatson> anyone can create a wiki page
<cjwatson> frequently, anyone does
<neighborlee> right , I was jus asking if 'anyone' did or a developer
<cjwatson> to my knowledge that did not arise from the development community
<cjwatson> but you could check for yourself; the wiki exposes revision history
<neighborlee> I did check but could not find who did it to ask them
<neighborlee> ill recheck
<neighborlee> I mean I know who did it, but im not sure how to contact them, but let me verify that
<cjwatson> if this is https://wiki.ubuntu.com/No-Mono-by-Default, none of the people involved in that are Ubuntu developers
<neighborlee> yes  thats the one
<cjwatson> and, with all due respect, Canonical would be the target for any patent infringement lawsuits and it's up to Canonical to decide whether it's a worthwhile risk
<neighborlee> well it looked very professionally drawn up, so I kinda assumed it probably was ; (
<neighborlee> and at the time I wasn't aware 'anyone' could create wikis there for such things
<cjwatson> you know that now
<neighborlee> it looked like a development wiki basically is what i meant
<neighborlee> yes
<cjwatson> it's trivially easy to create a page that looks like that, because there is a template for it
<neighborlee> ah ic well that explains that
<cjwatson> developer specifications usually include less advocacy, too
<neighborlee> ok
<slytherin> Can anyone look at my debdiff please and let me know if it need any refinements so that I can do those in next half hour.
<pitti> ArneGoetje: I fixed the langpack-o-matic split branch sufficiently and merged it into trunk; building packages now
<tjaalton> are there limitatons to what the package revision must be for a new package? I uploaded some plugins for vdr yesterday, but can't see them in the queue. They were based on packages that are not in debian, so I just added ubuntu1
<tjaalton> bbl ->
<pitti> ArneGoetje, cjwatson, mvo: FYI, split language-support packs all uploaded now; if I ever get back ssh, I'll NEW them
<cjwatson> 16:30:09 ERROR   Unhandled exception from processing an upload
<cjwatson>  -> http://launchpadlibrarian.net/11924746/vG8MMJpPVrrLkVUTSDwRmR4knlT.txt (Ubuntu MOTU Developers <ubuntu-motu at lists.ubuntu.com>: no @ found in email address part.)
<cjwatson> tjaalton: ^-- probably that
<juliank> Any chance to use aufs instead of unionfs as the default in Hardy? The only missing part is Bug #187259
<ubotu> Launchpad bug 187259 in casper "Add support for Aufs" [Undecided,New] https://launchpad.net/bugs/187259
<cjwatson> we can add support, but I doubt it will be the default
<ogra> cjwatson, i belive we have the module in l-u-m already
<ogra> the mythbuntu guys just wrote a ltsp kiosk client using aufs
<cjwatson> right, I just don't think it's appropriate to change the unionfs implementation at this point in the cycle
<ogra> /opt/ltsp/i386/lib/modules/2.6.24-7-generic/ubuntu/fs/aufs/aufs.ko yeah
<juliank> cjwatson: AFAIK, aufs is faster and more stable than unionfs
<ogra> right
<cjwatson> juliank: I'm not arguing with that, but at least with unionfs we have a rough idea of where the bugs are
<cjwatson> better the devil you know etc.
<juliank> cjwatson: Also, the Debian Live project uses it, too.
<cjwatson> Debian is further away from a release than we are
<cjwatson> and TBH Debian's live CDs are an order of magnitude less heavily used than ours
<juliank> cjwatson: Kanotix uses it with the same kernel we use.
<cjwatson> same comments apply
<cjwatson> I'm happy to merge it and people can try it out from there
<cjwatson> but the default will still be unionfs
<cjwatson> it's just not something I'm comfortable changing at feature freeze
<juliank> cjwatson: So we won't complete https://blueprints.edge.launchpad.net/ubuntu/+spec/livecd-unionfs-alternatives (Priority: medium)
<mjg59> juliank: The aim should be to have stuff implemented by feature-freeze, not push them in untested at the last second in the hope that it'll be stabalised by release
<cjwatson> the first step with this sort of thing is always to make it available as non-default so that people can try it out
<juliank> mjg59: Many distributions switched from UnionFS to aufs, because unionFS was to unstable. They are happier with aufs noew
<cjwatson> if testing *in the context of Ubuntu* finds that it is performing better *for us* (NOTE EMPHASIS) then we can consider flipping the switch at that pooint
<cjwatson> point
<mjg59> juliank: Which makes it a wonderful thing to investigate and integrate, at some point less than 6 hours before feature freeze
<cjwatson> I've merged your branch and changed the default to unionfs
<cjwatson> uploaded
<pitti> Riddell: FYI, I just uploaded a new jockey with mhb's -kde package \o/
<juliank> cjwatson: thx
<juliank> cjwatson: We could also add an aufs entry to isolinux, so people having problems with unionFS can find it.
<cjwatson> ITYM gfxboot-theme-ubuntu
<cjwatson> but yes, it's a possibility, although I shudder to think of how to present that in a reasonable UI
<Mithrandir> add "unionfs=au" to the kernel command line and document it, IMO.
<juliank> We could just add an entry 'Boot...Ubuntu (Alternative UnionFS)' to the list.
<cjwatson> Mithrandir: (union=aufs, implemented by the casper change above)
<Mithrandir> juliank: Boot Ubuntu (with Alternative gobbeligock) ?
<cjwatson> juliank: no way, I just got rid of all the entries from the main menu that weren't sensible user-comprehensible options
<Riddell> pitti: awooga
<Mithrandir> seriously, most people won't have a clue whatsoever what unionfs is.
<cjwatson> ogra: still around? could you have a look at the seed change in http://paste.ubuntu.com/4594/ ?
<evand> stick it and safe graphics mode in a submenu?
<Mithrandir> "Troubleshooting" "try one of those until it works".
<cjwatson> the F6 menu has this kind of option now
<cjwatson> evand: already done, safe graphics mode is on F4 now
<cjwatson> F6 is a garbage-bag of random boot options at the moment
<cjwatson> but I would like it to be verified to work in the context of Ubuntu before advertising it
<ogra> cjwatson, looks fine apart from the fact that ltsp can go but i can clean up later
<cjwatson> we have had some very subtle bugs in the past that would not necessarily show up on other distributions
<cjwatson> ogra: yeah, I left it in because Ubuntu doesn't have it on all architectures at the moment
<evand> ah, neat!
<cjwatson> ogra: we should figure something out about bootability of these CDs
<cjwatson> ogra: it would be nice to give people something better than this-disk-is-not-bootable-you-fool
<ogra> bootability ?
<ogra> hmm
<ogra> but what would you give them ? selections ? reboot, minimal system etc ?
<cjwatson> I'm not sure :)
<cjwatson> probably can't even give them a minimal system
<cjwatson> maybe a nice note that this is an add-on disk and they need to install Ubuntu first
<ogra> usplash alike
<cjwatson> or gfxboot
<juliank> Other topic: I would really like to see ndisgtk in main (Bug #191860), it's a widely used frontend for ndiswrapper. It's there since dapper and has 21526 installations.
<ubotu> Launchpad bug 191860 in ndisgtk "Main Inclusion Report for ndisgtk" [Undecided,New] https://launchpad.net/bugs/191860
<ogra> hmm, yeah
<_MMA_> juliank: What would being in Main do? Moving to Main for some things can mean more restrictions.
<juliank> _MMA_: many users requested to have it installed by default. You should also see https://blueprints.edge.launchpad.net/ubuntu/+spec/easy-ndiswrapper
<_MMA_> With the ability to pull from Universe, its not really necessary. Unless there is something in place that would stop Ubuntu from doing it.
<juliank> It's also very stable and does not need to be updated very often.
<TomaszD> hello, carlos told me to stop by, can someone from the dev team please include my Polish translation into a universe package paprefs? The upstream vendor doesn't respond. https://bugs.launchpad.net/ubuntu/+source/paprefs/+bug/191854
<ubotu> Launchpad bug 191854 in paprefs "Translation template unavailable for paprefs" [Undecided,New]
<TomaszD> the translation is attached to the bug report
<juliank> _MMA_: Users would like to have it included on the CD, and AFAIK adding packages from universe is not possible. And its users need it configure their internet access, so they may not be able to get it from a mirror.
<_MMA_> juliank: Adding packages from universe is now possible.
<cjwatson> _MMA_: not for Ubuntu it isn't
<_MMA_> I was about to add that. :P
<cjwatson> I think that's sort of relevant ;)
<_MMA_> I type slow.
<cjwatson> sigh, I need yet another germinate change for this Edubuntu seed rearrangement
<cjwatson> lamont: happy Christmas
<_MMA_> Was gonna say I didnt know if you had it set up for Ubuntu or not.
<cjwatson> intentionally not
<_MMA_> I figured.
<lamont> cjwatson: just tell me the number and I'll expedite it
<juliank> cjwatson, _MMA_: Having ndisgtk on Hardy disks (amd64+i386) would be cool.
<cjwatson> juliank: I agree with you, am just too flat out to do anything about it myself. you only filed the main inclusion report two hours ago :)
<cjwatson> seriously, it's one thing core developers leaving things to the last minute (part of the nature of things), but when you need sponsorship and assistance from other people to make changes, turning up on feature freeze day is more optimistic than anything else
<cjwatson> (I know you had the casper/aufs thing for a while but you only said the branch was ok to merge today)
<cjwatson> lamont: I'll do a merge for you
 * _MMA_ reminds himself to to work on his JACK MIR for Hardy+1.
<lamont> cjwatson: thanks
<luisbg> _MMA_, MIR?
<cjwatson> lamont: chinstrap:~cjwatson/germinate/germinate_0.11ubuntu11*
<cjwatson> lamont: will file an RT too
<luisbg> _MMA_, why JACK in main?
<_MMA_> So we can build in JACK support for packages in Main. PulseAudio for 1.
<luisbg> _MMA_, that makes sense
<lamont> cjwatson: is there a way to tell ssh (in ssh_config et al) if Host matches this pattern, then append $foo to it?
<cjwatson> hmm
<cjwatson> unfortunately I think not, there's no expansion syntax
<lamont> because for my other christmas presents, I want that one, and an ssh client hack for control mastery that says "if the other end said ETOOMANY, then be master instead of slave, and uh DTRT wrt control file"
<lamont> cjwatson: how fast you want that germinate?
<cjwatson> lamont: well, I'd like to land the edubuntu-addon changes tonight if possible ...
<cjwatson> although after telling somebody else off for being late I may not have a leg to stand on :)
<lamont> it's a question of 60 min, or do I get out and push
<cjwatson> 60 mins is fine
 * cjwatson blinks. curl build-depends on openssh-server?
<lamont> (play human cron)
 * lamont wonders if there's an open bug against the dhcp server that if you stop networking and restart it, you need to restart the server...
<lamont> hrm... syncing data to my laptop at 12MB/s on a 100Mbps lan kinda tanks everything else.
<lamont> cjwatson: and yes, I prefer nice pretty-n-merged packages to "pull this from bzr, kthx" :-)
<cjwatson> lamont: I am so looking forward to DC hosts running hardy
<lamont> you and all of IS
<tjaalton> cjwatson: sheesh, copy-paste bit me big time :)
<cjwatson> tjaalton: heh
<tjaalton> apparently I was a bit tired at the time, oh well
<lamont> cjwatson: if you promise not to get used to it, germinate has landed
<cjwatson> lamont: ooh. thanks
<cjwatson> lamont: did I get lucky timing?
<lamont> something like that..
<lamont> cron.daily runs at :3 and :33
<cjwatson> beer[lamont] += 1 then
<lamont> so I happened to look at it around :52 ish, ran cron.daily, and then fat-fingered the 'look at the queues' a few minutes later and re-rean cron.daily... go me.
<lamont> and that cron.daily caught the binary - that part was fortuitous timing
<asac> carlos: ping
<cjwatson> ogra: Edubuntu converted to an add-on CD, at least theoretically; I confess I haven't yet tested it and have no idea whether it'll work first time
<cjwatson> ogra: but I'm far too exhausted now to take it any further
<cjwatson> ogra: you probably ought to be able to fix it up from here in light of what I've done
<asac> bryce: how can i figure the dpi that X detects for my monitor?
<bryce> asac: xdpyinfo | grep resolution
<bdmurray> Amaranth: Would tagging compiz bugs based off the plugin be helpful?
<Amaranth> bdmurray: i don't think so
<Amaranth> bdmurray: Well, it might help me decide what ones to ignore if launchpad gives me a way to search for "all bugs that don't have tag foo" :)
<bdmurray> Amaranth: If the bug is about a specific plug should the package not be compiz but compiz-fusion-plugins-main or extra?
<Amaranth> if that's what package the plugin is in, yes
<bdmurray> And is the mapping between name in CCSM and the actual plugin pretty intuitive?  It looks like it to me.
<bdmurray> Or is there something we could look at / point to that would show the mappings?
<seb128> jamiemcc_: hi, do you plan to roll a new tracker tarball? the hardy feature freeze is now and we will likely review if we want to keep tracker enable for hardy, having a new version with svn bug fixes could be useful there
<jamiemcc_> seb128: yeah I was planning for this weekend - can it wait that long?
<jamiemcc_> seb128: its all bugfixes as there are no neew features at present
<seb128> jamiemcc_: yes, we can always get freeze exceptions, no problem, having it next week would just be nice because we likely want to look at it soon
<bdmurray> Amaranth: Is there something we could look at / point to that would show the mappings? or is just guessing based of the plugin name effective enough?
<Amaranth> bdmurray: I just do dpkg -S libfoo.so
<Amaranth> where foo is the plugin name
<jamiemcc_> seb128: yeah i understand - but we have to lots of testing before doing a release to help rpevent regressions
<seb128> jamiemcc_: the current concern is that it creates quite some cpu and io load and not used a lot by applications yet
<mario_limonciell> seb128, did you look at the bug that pitti commented on today regarding gmyth?
<seb128> mario_limonciell: yeah, we discussed it on IRC, neither of us knew exactly what it brings
<bdmurray> Amaranth: right, my question is does the plugin name match up to what it is called in ccsm pretty well?
<seb128> mario_limonciell: slomo pointed the gstreamer code doesn't work when using 0.7 or something I think?
<mario_limonciell> seb128, it brings support to watch recordings via native protocol for myth
<seb128> mario_limonciell: dunno what is myth, can you describe it from a newbie user point of view?
<mario_limonciell> seb128, i've gotten things working at home doing a local build with gmyth integrated
<jamiemcc_> seb128: we will try and tune things so its not noticeable by auto pausing when user is moving mouse or pressing keys
<mario_limonciell> seb128, its a tv recording server
<mario_limonciell> seb128, you schedule recordings, and then it does them for you
<Amaranth> bdmurray: almost not at all, about half the time
<mario_limonciell> seb128, there is a native viewer out there, but its a bit big.  so for casual usage on a secondary or tertiary machine, this is most ideal
<Amaranth> bdmurray: i dunno how to map the two automatically, i just do it in my head
<seb128> mario_limonciell: how responsive is upstream? will you look after totem bugs, etc for the next years? ;-)
<mario_limonciell> seb128, for gmyth, very responsive.
<seb128> mario_limonciell: because that looks like rather a small usecase and we have already lot to do, I don't want to maintain that for 3 years
<bdmurray> Amaranth: it looks like it is in the xml files
<Amaranth> bdmurray: well, yeah
<mario_limonciell> seb128, well its a "plugin" and off by default
<mario_limonciell> so shouldn't hurt the majority of people
<Amaranth> bdmurray: the name of the xml file is the name of the plugin, then inside there is the name that ccsm shows
<mario_limonciell> i'll be glad to get myself and the rest of ~ubuntu-mythtv to triage related bugs though
<mario_limonciell> especially until gmyth is in debian (that's the eventual plan)
<bdmurray> Amaranth: okay that might help people out then
<seb128> pitti: ^
<seb128> mario_limonciell: what about the gstreamer code and 0.7?
<mario_limonciell> seb128, i've pulled the appropriate patches from the vcs already for gstreamer
<mario_limonciell> and  they are part of gstreamer-0.10-plugins-bad now
<mario_limonciell> well once gmyth clears NEW at least, and it can build against it - the source package is in depwait right now
<seb128> thekorn: the retracer crashes on     raise ValueError, "Unsupported attachment-type '%s'" %type(attachments)
<seb128> is that a known issue?
<seb128> commentsbase.py", line 15, in __init__
<thekorn> seb128, do you know the content-type of the file which should be added,
<seb128> ValueError: Unsupported attachment-type '<type 'set'>'
<seb128> hum
<thekorn> och, that's bad
<seb128> that was on bug #191065 apparently
<ubotu> Bug 191065 on http://launchpad.net/bugs/191065 is private
<thekorn> hmm, it's private :(
<seb128> hum, I can view this one
<seb128> can't
<seb128> can't type neither ;-)
<somerville32> I can't view that bug either
<crevette> good night
<thekorn> seb128, the retracer is running the code of the .main branch of py-lp-bugs, right?
<seb128> thekorn: it's running the hardy package version
<TheMuso> c/
<TheMuso> gah
<propagandist> anyone know of a package using cdbs that also creates a python debug package?
<seb128> propagandist: gnome-menus
<propagandist> seb128: :o} thank you!
<seb128> propagandist: you are welcome
<thekorn> seb128, just checked the code, that's definitely a unknown issue
<seb128> thekorn: http://paste.ubuntu.com/4599/
<thekorn> thanks, let me create a bugreport and ask someone from the bug team to remove the"private" attribute
<thekorn> seb128, I created bug 191963 to track this issue
<ubotu> Launchpad bug 191963 in python-launchpad-bugs "ValueError: Unsupported attachment-type '<type 'set'>' " [Undecided,In progress] https://launchpad.net/bugs/191963
<seb128> thekorn: thanks
<keescook> slangasek: I assume we should just simply _not_ merge pcre3 7.6 for Hardy.
<slangasek> keescook: yes, I expect so
<seb128> thekorn: seems to crash on bug #191627 now
<ubotu> Launchpad bug 191627 in terminator "terminator crashed with GError in reconfigure_vte()" [Critical,Incomplete] https://launchpad.net/bugs/191627
<Robi1> WINE is broken in hardy
<Robi1> fix
<Robi1> +how do I
<thekorn> seb128, same error?
<seb128> thekorn: yes
<slangasek> keescook: not completely out of the question that it /could/ be merged, but standard freeze rules apply, offer not valid in all states, yada yada
<thekorn> let me check, sound like a change in edge
<Robin_> `23meg_
<seb128> thekorn: hum, the retracer should not be using edge
<keescook> slangasek: yeah.  I have no driving need to merge it.  :)  I like stability, thanks.
<thekorn> seb128, right,
<keescook> Robin_: best to file a bug report (and look for duplicates first) along with steps to reproduce
<Robin_> Do I need to register a launchpad account
<keescook> Robin_: and then check with #ubuntu-wine too  (LP account: yes)
<yogi> when is hardy alpha 5 expected to roll of from the compiling farm?
<keescook> yogi: https://wiki.ubuntu.com/HardyReleaseSchedule
<Robin_> WINE seg faults... how can someone mend this package with the stream it's stupid :)
<Robin_> anyway off to launchpad then
<yogi> keescook: thanks!
<yogi> are there any 'daily snapshot' cd images? (like debian has)?
<yogi> I hate downloading 650MB of ISO + 300MB of updates ;)
<LaserJock> yogi: cdimage.ubuntu.com
<_MMA_> cdimage.ubuntu.com
<_MMA_> :P
<yogi> thanks a lot!
<keescook> _MMA_: http://en.wikipedia.org/wiki/Jinx_%28children%27s_game%29
<_MMA_> Yeah, I owe Jordan a Coke now. :P
<LaserJock> hmm
<LaserJock> 'cept I'll have to move to NC to collect
<thekorn> seb128, I cant reproduce this error here, parsing of this bugreport works
<_MMA_> LaserJock: ;P
<seb128> thekorn: k, weird
<thekorn> seb128, the retracer is running on dapper, right?
<seb128> thekorn: yes
<thekorn> seb128, ok, will check this error in a dapper vm tomorrow,
<seb128> thekorn: thanks
<thekorn> you are welcome
<bryce> ogasawara: can you take a look at 187855?  trying to determine if it is a kernel bug or not
<ogasawara> bryce: sure
<ogasawara> bryce: hard to say if it's a kernel bug, but I'll post a comment to get more info.  do you know if timo has a reference he can point us to regarding upstream claiming it's a kernel issue?
<bryce> great thanks; you might ask tjaalton about that on the bug (I was wondering the same thing)
<_Angelus_> guys
<_Angelus_> i wanted to know...
<_Angelus_> do the developers know that the bootup splash doesnt work on 64bit computers?
<_Angelus_> i mean...  on kubuntu 64bit
<ion_> Is there a bug report? If not, please report it.
<mjg59> There is, and it's not all 64 bit machines
<_Angelus_> 90% the problem is that ubuntu uses vesafb-tng instead of vesafb, vesafb-tng is not compatable with most 64bit computers
<_Angelus_> there never was a fix , the only fix i found is, to compile a custom kernel, which worked fine...
<_Angelus_> so probably this issue would be solved if the kernel compiled by ubuntu for 64bit systems would use vesafb..
<mjg59> _Angelus_: Uh. No.
<mjg59> We don't use vesafb-tng, and usplash doesn't use vesafb.
<mjg59> It does vesa directly.
<_Angelus_> hmm
<_Angelus_> im reading a post from some german comunity
<mjg59> The issue is in x86emu
<_Angelus_> which have a fix
<mjg59> _Angelus_: Well, it's wrong (I wrote usplash and the vesa code it uses)
<_Angelus_> http://ubuntuforums.org/showpost.php?p=4057740&postcount=3
<_Angelus_> it says that gutsy by default doesnt load vesafb? :/
<_Angelus_> and its blacklisted?
<mjg59> Yes, we don't use a framebuffer by default
<mjg59> By default, usplash only uses a framebuffer on ppc
<_Angelus_> i see
<mjg59> We can't make the default setup use vesafb
<mjg59> It interacts poorly with some graphics drivers and suspend/resume support
<faketang> anyone here familiar with the installer for server, as in /usr/bin/main-menu on the disk's initrd?
<_Angelus_> well, i will try to enable vesafb and the other 2modules listed in this guide and see if it solved the problam
<mjg59> It'll probably work around the problem, but it won't solve it
<_Angelus_> why would the bootup splash need x86emu?
<_Angelus_> cant the bootup splash be compiled for x86_64 ? :/
<mjg59> No, because you can't run 16-bit code on a 64-bit kernel
<mjg59> It's your video card BIOS code that's the problem
<faketang> where would I be able to find the source code to /usr/bin/main-menu?
<_Angelus_> mjg59: then why does gentoo for example can have a bootup splash on amd64 arch? :S
<_Angelus_> and i heard gentoo and ubuntu use the same bootup splash system
<mjg59> _Angelus_: We don't use the same bootup splash system
<crimsun_> faketang: apt-get source main-menu.  See also http://d-i.alioth.debian.org/doc/talks/debconf6/paper/ .
<mjg59> usplash works fine on many 64 bit systems
<mjg59> It's just some recent ones where the video BIOS triggers bugs in x86emu
<_Angelus_> i see
<_Angelus_> mjg59: if this guide im trying works and solves the issue, is there somewhere where i can post it so people with the same problem find it with ease?
<faketang> crimsun_: I have no main-menu in any my repos (main/restricted/universe/multiverse); I have seen that debconf paper, but it doesn't explain how to modify the installer
<mjg59> _Angelus_: Not really. This will almost certainly be fixed by hardy release - I just haven't had time to write the appropriate debug code yet
#ubuntu-devel 2008-02-15
<crimsun_> faketang: hmm?  The source is available since dapper.
<soren> faketang: Did you try the command crimsun_ wrote?
<_Angelus_> ah it would be good mjg59, because when first gutsy was out, i had to compile a custom kernel for my system to get it to work
<faketang> crimsun_ / soren: I see main-menu in the main pool for security, but it's not showing up in hardy
<soren> ...
<soren> faketang: type: "apt-get source main-menu"
<crimsun_> also, is(are) your deb-src line(s) for main active?
<soren> faketang: Or grab it from bzr. See https://edge.launchpad.net/main-menu
<taggart> aren't there automatically generated diffs between debian and ubuntu packages? I found http://merges.ubuntu.com/ but it doesn't seem to have the package I'm looking for (ia32-libs)
<LaserJock> hmm, for me it doesn't show up in an apt-cache search but apt-get source works fine
<soren> LaserJock: apt-cache doesn't show d-i compontents.
<soren> or components.
<LaserJock> taggart: patches.ubuntu.com
<LaserJock> soren: yeah, that's interesting
<taggart> LaserJock: looking thanks
<soren> LaserJock: Not really.
<soren> LaserJock: They're not in Packages{,.gz,.bz2}
<taggart> LaserJock: found it, great!
<LaserJock> soren: I guess I would have expected it to find the source package, but thinking about I don't know why I'd expect that :-)
<faketang> interesting -- as LaserJock noted, it's only in sources but not as a compiled package
<soren> LaserJock: :)
<soren> LaserJock: apt-cache showsrc main-menu will show it, thoug.
<soren> though.
<LaserJock> right
<_Angelus_> mjg59: the guide worked
<LaserJock> I just thought apt-cache search would be a bit more inclusive ;-)
<mjg59> _Angelus_: Yes, it will do. But now you have vesafb, and so there's the potential for other things to go wrong
<_Angelus_> what i did was , added fbcon vesafb vga16fb /etc/initramfs-tools/modules , and commented vesafb
<_Angelus_> vga16fb from /etc/modprobe.d/blacklist-framebuffer. then updated the initramfs image
<_Angelus_> mjg59: well, better then a blank screen or a bunch of words comming out dough
<_Angelus_> mjg59:  can i make you a small question before i go ?
<mjg59> Sure
<_Angelus_> mjg59: i saw nvidiafb commented in /etc/modprobe.d/blacklist-framebuffer.  is there only a kernel nvidiafb  or the binary package from nvidia provides an nvidiafb too? if so, which is better, vesafb or nvidiafb?
<mjg59> There's only a kernel one, and it doesn't support newer nvidia hardware
<_Angelus_> oh
<_Angelus_> ok
<_Angelus_> thanks alot mjg59 :) see ya dude, and try to fix the bootup splash for the next release :P
<_Angelus_> peaze
<emgent> pitti, ping
<TheMuso> emgent: He is not likely to be around at this time.
<TheMuso> emgent: Either email him, or hilight him with the question/statement you would like to let him know about.
<TheMuso> highlight
<emgent> TheMuso, hehehe thnks :P
<emgent> s/thnks/thanks/
 * StevenK searches for 'bzr restore'
<RAOF> StevenK: Do you mean 'bzr revert'?
<StevenK> RAOF: Yes. My brain was promoting restore, probably from the output of svn revert
<StevenK> prompting, even
<RAOF> Heh.
<lifeless> ?
<StevenK> lifeless: Do you have a highlight for bzr and svn or something? :-)
<RAOF> lifeless: bzr has a serious bug.  It can't guess what command the user wanted to run when presented with a word that's similar to the bzr command they were after :)
<StevenK> Haha
<slangasek> bzr needs smarter merging, it should figure out what I want to merge without being told
<selckin> s/bzr/git/ win
 * RAOF has unleashed the whirlwind.
<StevenK> RAOF: Do you feel suitably abashed?
<RAOF> Eh.  Whirlwinds can be fun.
 * RAOF wishes this machine wasn't under such memory pressure that only my current task is paged in.
<ion_> lifeless: Oh, btw, one of the annoyances: i donât like that what goes to ~/.bazaar/locations.conf is, well, there instead of under project/.bzr
<zoke> What are the specific reasons for not adopting a Fedora style philosophy for keeping packages more updated ?
<soren> And what is this "Fedora style philosophy" of which you speak?
<zoke> keeping with upstream changes, bringing them quickly and keeping the delta as small as possible
<zoke> could is be done via -updates or -backports ?
<mjg59> -backports would be the appropriate place
<zoke> -backports is unoffical though, yes ?
<mjg59> No
<RAOF> No.  It's official.  There are processes & such, and the repositories are hosted on Ubuntu mirrors.
<zoke> oh, never mind then
<RAOF> Backports *could* do with more people testing, of course.
<ln-> if you already like Fedora, why not use Fedora?
<zoke> I like Ubuntu, it's just some times the lack of sync with upstream irks me slightly
<lifeless> selckin: really, thats quite a silly comment
<lifeless> ion_: you can put most things in .bzr/branch/branch.conf if you want
<selckin> lifeless: agreed
<ion_> lifeless: Can bzr push --remember do that?
<lifeless> ion_: it does in tag supporting branches
<ion_> Ok, thanks
<pochu> Any archive admin who can do the sync from bug 189243 before slangasek changes the topic? Thanks
<ubotu> Launchpad bug 189243 in libcrypto++ "please sync libcrypto++ 5.5.2-1 from Debian testing" [Wishlist,Confirmed] https://launchpad.net/bugs/189243
<jaldhar> hello I'm trying to solve a problem in the Debian pgp4pine package where on Ubuntu the user gets *** stack smashing detected ***: /usr/bin/pgp4pine terminated
<jaldhar> but recompiling it with gutsy doesn't help.  What should I look for?
<superm1> StevenK, thanks for catching that issue with bluez-utils.  I was starting to get rather frustrated that my BT mouse stopped working a few days ago.  I just apt-get source'd it and then saw your changes :)
<StevenK> superm1: No problem :-)
<TheMuso> StevenK: Get that SDL stuff sorted?
<StevenK> TheMuso: Nope.
<TheMuso> StevenK: Damn.
<Talcite> hey guys, I'm looking for the Totem-plparser 2.21 source code. Would it be sitting it bugzilla or anything like that?
<pochu> Talcite: svn.gnome.org
<Talcite> pochu: thanks
<thegodfather> superm1: do you have any idea why mythfilldb and mythbackend are crashorama?
<thegodfather> superm1: and btw.. the Predepend thing is wrong.. because we run the backup in preinst, at that time mysql is still down. it means that we need to do some more hacking in that direction i think
<thegodfather> Predepend will try to configure mysql before mythtv, but that guarantees only that the mythtv postinst will run after mysql is up
<superm1> thegodfather, the backup doesn't happen in the preinst anymore
<superm1> the backend process does it itself
<superm1> after it starts up
<superm1> so the predepend should be right now
<thegodfather> superm1: ok cool
<thegodfather> superm1: did you ping anybody to get mythtv-common out of NEW?
<superm1> libmyth-python is whats stuck in new right now
<thegodfather> yeah i know that :)
<superm1> i haven't since there is a very large line ahead of it
<thegodfather> ok
<superm1> but if you'd like to feel free :)
<thegodfather> well more than i like, i need
<thegodfather> otherwise my frontends can't upgrade and connect to the backends :)
<superm1> have you seen any performance problems with recent packages?
<superm1> because I change mcpu/mtune to march
<thegodfather> superm1: not sure really.. i noticed some skipping with dvd player, but i can't pinpoint the problem to be mythtv
<superm1> and i've seen some indications from people that its not working as well for them.  I've been having issues myself performance wise before that, but wasnt sure if it got worse
<thegodfather> superm1: the main frontend is slow generally
<superm1> yeah
<thegodfather> superm1: can you be more specific on what kind of perf problems you see?
<superm1> well particularly video playback on higher resolutions is where the issue would see
<superm1> like > 720x480
<thegodfather> what kind of video...
<thegodfather> i have that setup (>720x480) but i got it running 2 days ago
<thegodfather> so i don't have much to compare
<thegodfather> and no HD sources yet
<thegodfather> (real HD)
<superm1> ah i see
<superm1> well i'm doing some ppa builds for users to compare with the old cpu/tune and the new arch to see if there are performance differences
<superm1> so those will be ready in a few hours
<thegodfather> dmb: hi, are you awake by any chance?
<dmb> yes
<dmb> can i help you?
<thegodfather> dmb: one quick question.. are you the same dmb that has been hacking on the HVR4000/HVR3000 in cx88 driver?
<dmb> i'm guessing no, because i don't even know what that is
<dmb> what is the cx88 driver?
<thegodfather> dmb: hehe ok thanks :) worth a shot
<thegodfather> dmb: v4l-dvb upstream
<dmb> oh
<dmb> didn't know any other dmb's existed besides me :P
<thegodfather> well no big deal.. just curious :)
<dmb> np
<warp10> Good morning
<superm1> cjwatson, I branched from cdimage at http://people.ubuntu.com/~cjwatson/bzr/cdimage/mainline/ to add a mythbuntu alternate disk.  Would you be able to review if these changes are sufficient for building us an alternate disk?  I don't have the ability to build a local mirror as that calls for, so I can't verify it.  I pushed them to http://bazaar.launchpad.net/~mythbuntu/ubuntu-cdimage/mythbuntu-cdimage/
<dholbach> good morning
<ion_> good evening
<dholbach> hi ion_
<ion_> Howdy
<AnAnt> Hello, I filed bug #191933 and #192053 , who should I subcribe them too ? and are there any tags to add to them ?
<ubotu> Launchpad bug 191933 in mozilla-firefox-locale-all "mozilla-firefox-locale-all conflicts with firefox 3" [Undecided,New] https://launchpad.net/bugs/191933
<ubotu> Launchpad bug 192053 in ubuntu "update-java-alternatives does not handle alternatives for firefox-addons-javaplugin.so" [Undecided,New] https://launchpad.net/bugs/192053
<slomo> slangasek: FF did not happen yet?
<tkamppeter> h pitti
<tkamppeter> hi pitti
<pitti> Good morning
<pitti> emgent: contentless pong
<pitti> hi tkamppeter
<emgent> hehehe :P
<pitti> erk, why is ndiswrapper in main? *shudder*
<\sh> moins
<slytherin> Doesn't synaptic support the 'Homepage' field yet?
<tkamppeter> pitti, it seems that your upload of s-c-p got stuck.
<pitti> tkamppeter: I saw your mail
<pitti> I didn't get a reject mail
<pitti> I'll just reupload it
<pitti> tkamppeter: done
<tkamppeter> pitti, now I got a reject message telling that mandatory info in the dsc file is missing, not telling which info. Strange, as I have only replaced the upstream source, I did not change anything in debian/control or so.
<pitti> tkamppeter: what does it say exactly?
<pitti> tkamppeter: hm, that's weird, it didn't even get signed here
<pitti> tkamppeter: I'll rebuild the source pakcage here and try again
<LucidFox> seb128> yes, I did post the F-Spot galleryexport bug upstream, and it already got fixed in SVN :)
<LucidFox> http://bugzilla.gnome.org/show_bug.cgi?id=516620
<ubotu> Gnome bug 516620 in General "[0.4.2] GalleryExport makefile tries to delete /usr/lib/f-spot/extensions/GalleryExport.addin.xml" [Normal,Resolved: fixed]
<seb128> LucidFox: ok, thanks
<seb128> LucidFox: see https://wiki.ubuntu.com/UbuntuDevelopment/PatchTaggingGuidelines, following that would be nice
<pitti> tkamppeter: ah, you gave me two different sets of files, one with a broken version number
<pitti> tkamppeter: I reuploaded, should have worked now
<LucidFox> I'll follow that in the future, thanks
<seb128> LucidFox: thank you
<pitti> mvo: hm, I got a cron.daily email now
<pitti> mvo: http://paste.ubuntu.com/4603/
<pitti> mvo: can this be quiesced?
<mvo> pitti: thanks. I know why, it will happen only once or when the key changes. but its probably best to file a bug so that I can ensure that the initial one is quite as well
<pitti> ok, will do
<mvo> thanks
<pitti> mvo: bug 192074
<ubotu> Launchpad bug 192074 in apt "uninteresting cron mail about key update" [Undecided,New] https://launchpad.net/bugs/192074
<MacSlow> argx... package retrieval is broken
<pitti> mvo: any idea about bug 75273?
<ubotu> Launchpad bug 75273 in apt "Apt constantly sigsevs on edgy" [High,Fix committed] https://launchpad.net/bugs/75273
<mvo> pitti: let me check
<pitti> mvo: at least a shallow apt-get update/apt-get install/apt-get dist-upgrade test would be nice
<pitti> to know that it wasn't broken for some silly reasons
<mvo> pitti: right, I add test instructions
<mvo> pitti: sorry for delay
<pitti> NP, I just thought it was a bit urgent
<mvo> hm, there are test instructions already, I will poke bdmurray or pedro about #75273
<pitti> mvo: and update-manager 0.45.4 sits in edgy-proposed for ~300 days now, too
<mvo> pitti: what is the bugnumber for it?
<pitti> bug  #109216
<ubotu> Launchpad bug 109216 in update-manager "upgrade not possible with 0.45.3" [Undecided,Fix committed] https://launchpad.net/bugs/109216
<pitti> mvo: there might be more, -proposed has two versions
 * mvo checks
<mvo> pitti: bug #109216 updated
<ubotu> Launchpad bug 109216 in update-manager "upgrade not possible with 0.45.3" [Undecided,Fix committed] https://launchpad.net/bugs/109216
<pitti> mvo: I sub'ed sru-verification
<mvo> thanks pitti
<mvo> I do #107716 next
<ion_> I really, really, really wish Hugin 0.7 gets released in time to still get to hardy.
<pitti> Riddell: can you please seed jockey-kde? I just NEWed it
<Riddell> pitti: ok
<tjaalton> pitti: hey, aren't you _the_ hal-wizard, or do you know one?-) I've got a problem with hal-set-property, it refuses to work when run from a hal script, but the same command works when run by hand. sent an email to hal list but so far no replies
<pitti> tjaalton: it's run as different users?
<tjaalton> pitti: basically so, hal scripts are apparently run as haldaemon? but it's strange that it can't connect to hald which is run with the same privs?
<pitti> tjaalton: I have only used it as root so far
<pitti> tjaalton: usually hal addons are run as root
<pitti> but they might choose to setuid() of course (and some do)
<tjaalton> hmm, ok. I'll try to debug more
<tjaalton> the script would set the xkb layout etc for input-hotplug..
<BenderUnit22> cÃ xmotoap
<BenderUnit22> Sorry. :/
<pitti> yay we know your password now
<BenderUnit22> Nah, cat. :)
<tjaalton> oh she knows it as well?-)
<BenderUnit22> :)
<Fujitsu> Can somebody please give back geda-(gattrib|gnetlist|gschem|gsymcheck|utils) on all architectures?
<pitti> zul: ping @ 189589
<pitti> zul: ^ bug
<pitti> Fujitsu: done; next time, please use {a,b,c} shell globs :)
<Fujitsu> pitti: Thanks, will do so in future.
<MacSlow> is there anyway I can inject a -j4 for make when doing packagbuilding to leverage the two cores of my cpu?
<MacSlow> I just want that to be locally maybe picked up from some env-var instead of stuffing it permanently in the package (some file under debian) itself
<awalton__> MacSlow, I think there's a variable called MAKEFLAGS you can set that will be passed to all the children of make.. it might get nasty though with lots of recursive make calss.
<awalton__> *calls
<asac> MacSlow: dpkg-buildpackage has a -j flag too
<asac> according to man it will set MAKEFLAGS accordingly
<ogra> in pbuilder its --debbuildoptions (gets handed through to dpkg-buildpackage)
<slytherin> Can anyone please explain this condition - db_get bcm43xx-fwcutter/cut_firmware || true
<pitti> tkamppeter: just looking at the Brother Software Open License Agreement; this looks sufficiently free for universe to me; do you think otherwise: ISTR that you wanted to have it in multiverse?
<zul> pitti: hi
<zul> yeah we didnt realize they were in universe already at the time.
<pitti> tkamppeter: oh, I see; no source code
<pitti> tkamppeter: (I was just reading the license before)
<mjg59> pitti: Haha
<pitti> zul: 'they'?
<zul> pitti: dendorbates
<zul> ill close it
<pitti> you guys confuse me today :)
<slytherin> pitti: I tried testing the latest jockey for broadcom chipset. I have one question though.
<pitti> zul: ah, you mean xen-3.2 binaries are already in universe; ok
<pitti> slytherin: sure?
<zul> pitti: yeah sorry about it I just woke up as well
 * pitti hugs zul; sorry, was just lacking context :)
<slytherin> pitti: jockey is supposed to use b43-fwcutter for firmware extraction right? And it (jockey) should show a dialog for selecting a local file or downloading from net right?
<pitti> slytherin: it currently doesn't show a download dialog, no; it leaves the downloading and install to b43-fwcutter
<pitti> I'd like to add the dialog for local files again, though
<slytherin> pitti: Yes, that is what I wanted to ask. Also I am trying to fix a problem with b43-fwcutter. Can you explain what this condition is - db_get bcm43xx-fwcutter/cut_firmware || true
<pitti> slytherin: I think it tries to guess the answer from the old bcm43xx-fwcutter package
<pitti> thus, if you already answered the 'download?' debconf question for bcm43xx, it won't ask you again
<pitti> tkamppeter: *grumpf* this brother thing uses /usr/bin/brprintconfcl1 and /usr/local/Brother</data stuff>; this is horrible
<slytherin> pitti: What if question from bcm43xx-fwcutter package is not present? Will it assume the answer to be true? (|| true part)
<jaldhar> I asked this last night but I guess no one was around
<pitti> slytherin: no, the || true just means that the script doesn't abort if the answer is not present in the debconf db
<jaldhar> I'm trying to solve a problem in the Debian pgp4pine package where on Ubuntu the user gets *** stack smashing detected ***: /usr/bin/pgp4pine terminated
<jaldhar> but recompiling it with gutsy doesn't help.  What should I look for?
<pitti> hi jaldhar
<pitti> jaldhar: does this result in a SIGSEGV?
<pitti> jaldhar: in that case, apport should have picked it up and generated a crash report
<jaldhar> heh actually it just kills my xterm
<jaldhar> no crash report
<pitti> !
<pitti> your xterm? wow, that's harsh
<dholbach> MOTU Q&A session in 17 minutes in #ubuntu-classroom
<slytherin> pitti: Ok. if I understand it correctly the script will go ahead and try to download the firmware if old answer is not found. This is kind of problematic as the user may not have access to net and it will throw an error. Please let me know when you have added the old dialog again so that I will file a bug against the fwcutter package.
<jaldhar> pitti: the debian bug is #457947 if you would like to take a look.  The submitter has provided some extra information
<pitti> jaldhar: ah, I see, SIGABRT; we explicitly ignore this since we got too many crash reports for cases where abort() was called, which weren't actually package bugs
<pitti> jaldhar: I'm afraid that involves a real gdb session
<jaldhar> ok.  So let me see what I can come up with.  Thanks.
<SlimG> ArneGoetje: I got some issues with my norwegian characters (they look like this now: Ã¦Ã¸Ã¥, they should look like this: ÃÂ¦ÃÂ¸ÃÂ¥) at my keyboard in kubuntu hardy after the last update, Riddell told me to ask you, here's the output of locale (three errors): http://pastebin.com/m21925474
<MacSlow> asac, ah cool thanks for the tip
<MacSlow> mvo, just wondering... do you know why zoom was kicked from compiz-fusion-plugins-main?
<mvo> MacSlow: zoom is part of the compiz-plugins package, fusion-plugs-main has ezoom
<mvo> MacSlow: do you use zoom? I found ezoom superior in  a lot of ways
<MacSlow> the only use for zoom I have is taking closer tools to certain UI-elements now and then... and for that I prefer this "zoom-to-selection" of the normal zoom-plugin
<MacSlow> ezoom does not offer that
<mvo> MacSlow: ok, zoom should still be there, no sure if we enable it by default, because of ezoom
<MacSlow> mvo, only moved in category
<slytherin> is there a problem with main mirror?
<LucidFox> If any buildd admins are here, please rerun build for midori https://launchpad.net/ubuntu/+source/midori/0.0.17-1 on architectures other than i386
<LucidFox> (they failed due to dependence on a package in NEW)
<pitti> LucidFox: kicked
 * pitti looks at ogra -- "etc/ /" and "usr /" in classmate-tools-0.1/debian/classmate-tools.install ???
<ogra> pitti, do ysou insist in having a makefile ?
<pitti> ogra: no, but I wonder why you install upstream /etc/* and /usr/* into /
<ogra> oh, the slashes
<pitti> sholdn't that just be "etc" and "usr" ?
<ogra> hmm, i wonder why they dont end up in /
<ogra> yeah, actually it should, but the binary looks ok
<pitti> hm, dh_install should fail on that
<pitti> ogra: ok, if it actually works, fine for me; I just wondered, because it looks weird
<ogra> http://paste.ubuntu.com/4609/
<ogra> well, its surely ugly
<pitti> ogra: man dh_install says "the
<pitti>        installation directory is given relative to the package build directory."
<ogra> but the result is ok
<pitti> I guess that could also be interpreted as "whatever you specify, we'll prepend debian/package"
<ogra> hmm
<pitti> ogra: ok, thanks for the heads-up
<ogra> i'll clean it up anyway
<pitti> just confusing, but apparently it is correct under above interpretation
<pitti> "useradd -c "ClassmatePC Admin User" -m -p '$1$HNdD8xtG$ZYTwxGjrIBCyw3DYvtUoA0' -s /bin/bash" in classmate-settings.postinst?
<pitti> ogra: ^ I heavily object to a static default password; that's not really a secret then :)
<pitti> ogra: shouldn't this be locked by default and instead get a debconf/other interactive dialog to set passwords?
<ogra> nop
<pitti> oh, it's even written in a comment ("edubuntu")
<ogra> that wont stay this way
<ogra> (see pm for details)
<jdong> anyone know where isight_usb went with the latest hardy kernel?
<jdong> uvcvideo can't cope with the isight
<mjg59> jdong: Fabio's the right person to ask about that - he touched it last
<mjg59> My hardware got stolen, so I've no clue
<dholbach> mjg59: ugh... what got stolen?
<mjg59> dholbach: My Mac and a Dell
<dholbach> shit :(
<mjg59> Plus some other bits and pieces
<dholbach> how did that happen?
<mjg59> SOmeone broke in through the back door
<mjg59> Which reminds me, I need to phone the insurance company
<dholbach> it might be tough to find something there, but did you check on ebay?
<mjg59> Heh. Not really worth it
<dholbach> I at least tried it, when they stole my car
<mjg59> No important data on it
<mjg59> And this way I get a hardware upgrade :)
<dholbach> OK
<jdong> mjg59: ouch :(
<dholbach> are the buildds/archive/something in manual mode or something?
<pitti> dholbach: no, why?
<dholbach> oh, I'm still waiting for the fix that asac uploaded this morning
<pochu> sladen: hi, am I late for FeatureFreeze? The topic here says the archive is open for development... is it ok if I upload a new aMule (universe) which also finish the libcrypto++ transition?
<pochu> slangasek: ^ that was for you.
<pochu> sladen: sorry
<pitti> dholbach: given that I chase binary NEW since this morning I can tell you that the buildds are operating full speed :)
<asac> dholbach: the mirrors still don't have those locales?
<dholbach> ok
<pitti> pochu: that sounds like a bug fix
<pochu> pitti: yes but it's also a new upstream snapshot
<pitti> pochu: if it has new features, please ask the new motu-release team
<pochu> pitti: alright, thanks.
* pitti changed the topic of #ubuntu-devel to: Archive: Feature freeze | 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
<asac> doko: Xb-Npp- headers got lost for the sun-java plugin packages :( ... maybe commit them to svn and send them to debian as well (I assume you prefer to sync)?
<\sh> doko: could you explain why we can't ship the java-doc zip packages, which are needed by sun-java*-doc package? :)
<dholbach> bdmurray, thekorn: do you think it'd make sense to upload py-lp-bugs / bughelper to the bughelper-dev team ppa for older releases too?
<dholbach> bdmurray, thekorn: it's not really supported for older releases, but it might make sense - what do you think?
<doko> \sh: read the license agreement they require, on download
<doko> asac: really? I'll look at it next week
<asac> doko: thanks.
<bdmurray> dholbach: so kind of like backports? that makes sense to me
<dholbach> bdmurray: we just need to make sure we upload it as    <version>~gutsy1 , etc
<bdmurray> dholbach: okay, I'll try to get to it before the class next week then
<dholbach> rock on
 * dholbach hugs super-bdmurray
 * bdmurray hugs dholbach 
<sistpoty|work> dholbach: just had the idea to maybe use gobby for the library session during the open dev week... do we have a gobby server somewhere, which I could use?
<dholbach> sistpoty|work: gobby.ubuntu.com
<dholbach> IRC could work too :)
<sistpoty|work> dholbach: cool, thx!
<dholbach> mako: nxvl_work just told me that there is a edubuntu meeting at the same time we plan the CC meeting
<nxvl_work> mako: 20 Feb 20:00: Education Team
<mathiaz> dholbach: and there is a server team meeting one hour after
<dholbach> nxvl_work: I mailed him in case he's not around here
<nxvl_work> dholbach: i think he must be online, as he has just edited the wiki, just not pending on the IRC
<nxvl_work> dholbach: but thats ok, i will wait :D thanks!
<mako> nxvl_work: you are off by one day, i think
<mako> nxvl_work: proposed cc meeting is *at* 20 on the 21st
<mako> apparently, i typed it incorrectly into the wiki :)
<mako> sorry about that!
<nxvl_work> mako: not on the wiki
<nxvl_work> mako: heh, ok
<nxvl_work> :D
<mako> sorry for the confusion
<tgelter> morning all
<tgelter> I can't get a custom config I've created to be recognized by debian/rules when I try to build
<tgelter> $ AUTOBUILD=1 NOEXTRAS=1 fakeroot debian/rules
<tgelter> binary-thinkpadmake: *** No rule to make target `binary-thinkpad'.  Stop.
<tgelter> any ideas?
<tgelter> all: ping
<seb128> does anybody knows why we use /media for windows partitions mounting? the fhs describes it as "This directory contains subdirectories which are used as mount points for removeable media such as floppy disks, cdroms and zip disks."
<seb128> I'm having a discussion with the mandriva GNOME maintainer about how what gvfs should be listing
<seb128> and they have the windows partitions mounted under /mnt so they think /mnt should be listed
<seb128> where we use /media and don't list things in /mnt in nautilus
<persia> seb128: I'd prefer unmounted partitions not to be in /media.  I have a couple partitions I only mount manually, and it is odd that there is a difference between calling `sudo mount /data` and double-clicking the icon for the partition in nautilus.  This isn't directly related to Windows partitions, but I suspect a change for Windows partitions would also address my use case.
<persia> The justification being that fixed partitions not listed as automount in /etc/fstab aren't "removable media".
<seb128> persia: well, they should not be in /media then, but they are
<seb128> persia: and unmounted partitions are nowhere since they are not mounted
<seb128> persia: nautilus uses gnome-mount and do the mounting when you double click on something not mounted
<persia> seb128: Right, but if I double-click the icon in "Computer", it mounts to /media, whereas if I run `mount /dev/sdb1` it mounts to /data.
<persia> (maybe I have a different issue, and should go research it and report a bug)
<seb128> why would it mount to data?
<seb128> when using mount you need to either have it in fstab or specify the mountpoint
<persia> seb128: Because there is an entry in the fstab to mount it there, but not to mount on boot.
<seb128> ok, that's something you added
<seb128> and gnome-mount should probably respect it
<seb128> that's a gnome-mount bug and I different issue than my question ;-)
<persia> Ah.  Nevermind then, I have a different bug.  I'll dig up some details, and report it then.
<persia> I still think fixed disks aren't removable media, and support not mounting them in /media
<seb128> well, that's not what we do now
<seb128> and why was my question ;-)
<jeromeg> hello
<sistpoty|work> seb128: /mnt seems an equally bad choice (temporarily mounted partitions) to me... not too sure where it *should* go then though
<jeromeg> seb128: once metacity 2.22 is released, are you against a backport to gutsy ?
<mario_limonciell> seb128, now that gmyth is in universe, I've attached a patch for totem to that bug to activate it (it just modifies build depends in control.in), and verified it.  slomo_ offered to upload it, so was there anything else related to this that would be troublesome?
<persia> My memory of Mandrake (which may not apply to Mandriva) is that there were many subdirectories under /mnt used to mount different things.
<seb128> jeromeg: no, why should we? I'm not in the backport team and don't do backports anyway
<seb128> mario_limonciell: I've seen that but I've quite busy at the moment, will look later
<mario_limonciell> seb128, okay thank you.
<jeromeg> seb128: yep yep, I know, but as it's maintained by the desktop team which you are one of the leaders, I just wanted to know your thoughts on this
<seb128> jeromeg: I don't see the interest, that's only a window manager, new versions are not bringing a lot and I don't expect many users still running gutsy when hardy will be available
<jeromeg> seb128: well, it brings the compositor
<jeromeg> except that, yes, it has no real interest
<seb128> echos I've had is that's it not that fancy and quite slow for many users
<seb128> but as said I'm not part of the backport team, they can backport it if they want, I've no objection
<seb128> doesn't seem a priority to me though
<jeromeg> ok
<jeromeg> thank you
<seb128> you are welcome
<jeromeg> got to go bye
<persia> seb128: No evidence that this was the basis, but the best documentation I can find is https://wiki.ubuntu.com/PartitionConfigure
<seb128> persia: that spec has been deprecated
<persia> seb128: Right.  Like I said "No evidence that was the basis".  Still, if that was discussed at uds-mtv, it may have germinated the discussion that led to the current state.  Anyway, I can't find anything else :(
<persia> seb128: Maybe https://wiki.ubuntu.com/PartitionProber (although old and possibly pre-specs)
<persia> Aha!  https://blueprints.launchpad.net/ubuntu/+spec/mount-all-local-filesystems specifies /media/
<mario_limonciell> bdmurray, ping, i had a question about one of the debugging pages you wrote
<bdmurray> mario_limonciell: okay, I might have just been the last person that edited it but what is your question?
<slangasek> Amaranth: I see that you set the milestone yourself for bug #184720; is this being worked on?
<ubotu> Launchpad bug 184720 in compiz "readd intel 965 to blacklist" [High,Triaged] https://launchpad.net/bugs/184720
<Amaranth> slangasek: ah, well...
<mario_limonciell> bddebian, well I'm attempting to debug a suspend related issue as described here: https://wiki.ubuntu.com/DebuggingKernelSuspend, and after the failed suspend continue to reboot.  well since the RTC has a completely wrong value due to the nature of this, fsck is forced.  this ends up taking longer than 3 minutes, and institutes a reboot afterward as well
<mario_limonciell> corrupting the rtc and losing the valuable data
<Amaranth> slangasek: I'd have to talk to bryce, tjaalton, and mvo about what we're going to do with the 965.
<bdmurray> mario_limonciell: "You can avoid a long fsck delay by using 'tune2fs'"
<mario_limonciell> bdmurray, oh but nvm it looks like i completely missed an option above
<mario_limonciell> yeah
<bryce> Amaranth: yeah we need to get that sorted out soon
<mario_limonciell> bdmurray, sorry for bothering you :)
<bdmurray> mario_limonciell: np if you discover what options to use somebody seems to have asked about that
<slangasek> Amaranth: ok; I'm marking it as 'beta' for the milestone then so it doesn't distract from critical bugs that should be worked on immediately for alpha-5, but please don't let that stop you from working it out sooner :)
<bdmurray> mario_limonciell: I mean the default ones
<Amaranth> slangasek: just need to get everyone on at the same time to figure it out
<Amaranth> I just pinged them, maybe they'll show up :)
<Amaranth> oh, here is bryce already :)
<bryce> Amaranth: tjaalton says 965 with greedy turned on, exa is ok.  I'm not sure what we'd need to change to make that the default for 965.  Maybe just some dexconf logic?
<bryce> for non-965 I think we'd like to stay with XAA for now
<Amaranth> bryce: That'd be something you'd want to do for only that 965 so it should be a change inside the driver itself
<bryce> I could probably code the change, but I'd need more direction about exactly what the change needs to be (I've not tested with greedy yet myself)
<mario_limonciell> bdmurray, ah yeah I'll add the default one to that page.  Thanks
<bdmurray> mario_limonciell: thank you!
<tjaalton> bryce, Amaranth: right, change the driver itself since changing dexconf is always fragile, and it doesn't help those who upgrade
<Amaranth> tjaalton: You're going to do this, then?
<tjaalton> btw, my irssi doesn't highlight the channels where my nick has been mentioned other than in the beginning of the msg. did I break my config?
<persia> tjaalton: I'm fiddling with recommends for nvidia-settings, just in case you happen to bump into the same thing.
<tjaalton> Amaranth: maybe we can coordinate this with bryce
<tjaalton> persia: lrm suggests it, isn't that enough?
<persia> tjaalton: Except nvidia-settings has a versioned Recommends: on nvidia-glx, which wasn't satisfied by Provides: .  I'm testing a solution (as even Dapper has a new enough nvidia-glx we shouldn't have to specify a version), and will upload within the hour.
<tjaalton> persia: oh ok, please fix it :)
<persia> The issue is that the driver recommended the settings package, which recommended the old driver, which self-conflicted :)
<tjaalton> heh
<bryce> tjaalton, Amaranth, I can take a look at making changes to the driver, if you can give me a bit more detail about what would need changed specifically?
<tjaalton> bryce: I need to look at the code first ;)
<mario_limonciell> when suspending with g-p-m, is /etc/acpi/sleep.sh still called, or is it all pm-utils stuff that doesn't touch sleep.sh anymore?
<bryce> tjaalton: what is the option that needs to be switched on?  (grep -i greedy in the source returns nothing)
<frafu> Hello, I would like to have a piece of information about mir and feature freeze: mousetweaks is a module in the process to pass mir. As feature freeze has passed, a freeze exception is required. My questions: Who is supposed to ask for the freeze exception: the person from the mir team that accepts mousetweaks into main, or the person that submitted mousetweaks to mir (that would be me) ?
<bryce> ah, Option "MigrationHeuristic" "greedy"
<tjaalton> bryce: yes, it's actually an option for EXA, so maybe it's passed on to the server
<eddie> so, is the latest version of hardy doing?
<tortoise> I'm the developer of onboard and python-virtkey which are both in main, who do I contact to update them in Hardy?
<persia> tortoise: You've just missed the deadline to make it easy.  Your best bet is to file a bug, and follow https://wiki.ubuntu.com/FreezeExceptionProcess, although https://wiki.ubuntu.com/DeveloperResponsibilities may help you identify someone to help.
<ScottK2> tortoise: Additionally, indicate if they've been updated in Debian already as sync'ing from there takes a lot less work and is considered lower risk.
<mvo> slangasek: the "Could not calculate the upgrade" you reported, did it mention firefox anywhere?
<bryce> tjaalton, Amaranth, ok, working on a patch...
<slangasek> mvo: update-manager said nothing except for that error message, which seems to discourage debugging. :)  apt-get dist-upgrade reports a firefox problem, yes.
<mvo> slangasek: ok, thanks
<bryce> hmm, just need to sort out how to pass an option back *up* to the server from the driver.  hrm
<tjaalton> bryce: or match the device there
<tjaalton> and patch the server too
<bryce> yeah possibly
<tjaalton> or only the server
<bryce> tjaalton: hmm, so far I'm not finding other instances of options being passed back to the server; perhaps it's not allowed to do it
<tjaalton> bryce: jbarnes seems to be online, why not ask him directly :)
<tjaalton> if this is possible or not
<bryce> tjaalton: heh, that's exactly what I was thinking... already asked
<tjaalton> cool :)
<ion_> Re: the new background image: WTF? :-)
<jwendell> seb128, around?
<seb128> jwendell: yes
<jwendell> seb128, does hardy support system-bus activation ? (This is a question in a bug I've opened)
<jwendell> http://bugzilla.gnome.org/show_bug.cgi?id=513138
<ubotu> Gnome bug 513138 in clock ""Set" button in locations doesn't work" [Normal,Unconfirmed]
<seb128> jwendell: yes
<jwendell> seb128, thanks
<seb128> jwendell: the service is installed and bus activation is working
<asac> bryce: stupid question. should XRenderComposite work for all drivers?
<bryce> asac, it should for most of the major drivers, but no, not all of them
<asac> bryce: are there different operations, where one might work for all and some other operation won't work (e.g. especially tile)
<asac> (sorry i have not clue at all ... just looking at cairo code :))
<bryce> asac, not sure - Amaranth may know
<asac> bryce: ok, one more: is tile an operation for xrendercomposite or is that something different?
<Amaranth> err, Render compositing is different from the Composite extension
<Amaranth> anything that has to do with Render should work everything
<Amaranth> err, everywhere
<bryce> ah ok
<Amaranth> worst case (most of the time, actually) it just happens in software
<asac> Amaranth: i have no clue. i just see that if cairo uses XRenderComposite for tiled backgrounds we get garbage for some drivers, and if we use XTile it works :)
<Amaranth> this is why EXA is important, actual hardware accelerated Render :)
<asac> the garbage happens for XAA
<Amaranth> asac: what drivers?
<Amaranth> when using XAA with intel and ati basically the entire Render extension is done in software
<asac> i know about fglrx, ati and i think intel (but not sure about that)
<asac> Amaranth: do you have intel?
<asac> you could try by using preview on ubuntu wiki with ffox 3
<Amaranth> nope, i have nvidia
<asac> http://people.ubuntu.com/~asac/corrupted1.png
<asac> darn
<asac> i think jorge confirmed that it happened for him with intel + XAA as well
<Amaranth> fglrx, ati, and intel would all be using the same software version
<asac> yeah ... where is that?
<Amaranth> nvidia has their own code
<Amaranth> Somewhere in the X server, I guess
<asac> makes sense then
<asac> hehe
<asac> bryce: ^^
<ion_> asac: That looks like a good mode to browse the Ubuntu forums. Youâre guaranteed to get more informative and sensible content.
<asac> lol
<keescook> okay, this always eludes me, and I can never find good examples.  If I'm moving a file from one binpkg to another binpkg in the same srcpkg, how do I set up the conflict/replace bits?
<mjj29> from A to B then B replaces/conflicts A (<< ${binary:Version})
<keescook> mjj29: hm, perhaps I had it backwords.  I will try again.  thanks!
<bryce> asac, I've not seen that particular issue with firefox 3 on -intel with EXA
<bryce> asac: maybe pop into #cairo and we can question cworth on it?
<asac> bryce: read above: XAA
<asac> bryce: well ... cworth already knows about this issue :)
<bryce> tjaalton: ok, hacked up a couple patches to fix exa / 965, posted to bug 177492
<ubotu> Launchpad bug 177492 in xserver-xorg-video-intel "EXA is balls-achingly slow" [Critical,Confirmed] https://launchpad.net/bugs/177492
<tjaalton> bryce: that was quick
<bryce> tjaalton: I've not tested that they apply or work or anything
<sistpoty> tjaalton: are there plans to make nvidia-glx a virtual package?
<bryce> tjaalton: lemme know if you get a chance to test those patches; I'm going to grab lunch and then get back on the xrandr gui stuff
<tjaalton> sistpoty: no plans, what's the use case?
<tjaalton> bryce: yep, I have all the hardware right here ;)
<sistpoty> tjaalton: no idea... just saw an upload of nvidia-settings from which I guessed that
<tjaalton> sistpoty: ah, no there was a "conflict" before that change
<sistpoty> tjaalton: ah, k... I'm adding the proper conflicts now btw. :)
<sistpoty> (maybe not proper, but rather defensive...)
<tjaalton> bryce: intel compiled, xserver failed but probably not due to the patch
<bryce> failed on compile or boot?
<tjaalton> bryce: btw, intel needs another patch to force xaa for !I965G
<tjaalton> compile
<tjaalton> right, I had some git master version of mesa sources
<bryce> ahh
<tjaalton> another try
<tjaalton> could an archive admin push the latest lrm (built) to the archive? there was a silly bug which makes nvidia owners very sad
<tjaalton> bryce: ha, now the build failed again
<tjaalton> bryce: http://pastebin.ubuntu.com/4623/
<bryce> tjaalton: er, odd I thought I left that out of the patch, one sec
<tjaalton> hmm, maybe I had a wrong version then
<bryce> oh whoops no I see my error
<bryce> the xserver patch should say:
<bryce> +    if (pScreenInfo->flags & EXA_MIGRATION_GREEDY) {
<bryce> +        pExaScr->migration = ExaMigrationGreedy;
<bryce> +    }
<bryce>  
<bryce> ...uploading fixed patch to the bug...
<jdong> bryce: schweet! fixing -intel slowness?
<bryce> jdong: yeah
<jdong> that's always a good thing :)
<bryce> jdong: well more of a workaround
<jdong> meh fix workaround.... X will be faster :)
<bryce> jdong: but tjaalton says it'll let us close a whole mess of EXA/965 bugs. dell, intel, and many others will become happy
<tjaalton> it's not perfect but satisfactory
<jdong> awesome, that's good to hear
<bryce> tjaalton: originally I had implemented my change by adding a new boolean parameter migrationGreedy to the pScreenInfo data structure, but then I realized it would be better to put it in the flags param since that'd be less invasive and wouldn't risk ABI issues
<bryce> but I forgot to change that one part of the xserver patch over
<tjaalton> heh, right
<tjaalton> bryce: ok here goes..
<jdong> tjaalton: aaah X doesn't start anymore (kidding :D)
<tjaalton> jdong, bryce: starts, but the hack doesn't seem to work yet :/
<tjaalton> I got broken shadows and stuff
<bryce> hrmble
<tjaalton> there's no mention on the log about forcing it
<bryce> tjaalton: ok, well I'm in the midst of xrandr hackery, but will plan to look into it more when I get some time
<bryce> maybe one of the other options also needs set or something
<bryce> or maybe there's too many checks in the patch, and something is preventing it from turning on
<tjaalton> bryce: maybe the first defined(I830_USE_EXA)?
<tjaalton> hmm no
<bryce> did you build the -intel driver after installing the patched xserver?
<bryce> if it's done the other way 'round, then the greedy stuff won't get compiled in
<tjaalton> ah
<tjaalton> ok, another try
<tjaalton> nope, the same
<tjaalton> bryce: I'll check it again in the morning
<tjaalton> night ->
<bryce> tjaalton: thx, night
#ubuntu-devel 2008-02-16
<persia> sistpoty: Thanks for fixing nvidia-settings harder, although even Dapper had a sufficient version of nvidia-glx.
<TheMuso> c
<TheMuso> ugh wrong tab...
<keescook> asac: any idea how to get paste-into-window-loads-URL to working ff3?  (they changed it in ff2 too!)
<keescook> asac: oh, nm, it's middlemouse.contentLoadURL still ... seems it forgot my setting.  :)
 * Hobbsee waves
<Hobbsee> can someone extend my ubuntu-members membership here?
<asac> keescook: oh ... i think thats a bug ;)
<minghua> Hobbsee: You should be able to extend it yourself, AFAIK.
<Hobbsee> minghua: that requires me having my launchpad password
<asac> keescook: thanks for reminding me ;) ( i had a patch for a similar issue in ffox 2)
<Hobbsee> which is on my home laptop.  as is my password safe, which didn't seem to get transferred over here.
<minghua> Hobbsee: Oh okay.
<calc> i picked up an old style corded phone and was able to prove my phone/dsl trouble was ATT's fault
<calc> so they are coming to fix it tomorrow :-)
 * calc had thought it was his crappy 'inside' wiring
<calc> its probably not too great either but at least its ATT fault so it can get fixed sooner that way
<calc> i actually have no dial tone but the dsl is sorta working
<Hobbsee> calc: since when do you want a working phone anyway?
<lamont> slangasek: you around?
<warp10> Good morning!
<j1mc> hi all - does anyone know anything about linux-meta 2.6.24.8.8 on xubuntu?  it's been producing "uinstallable binaries" for a good while now.
<j1mc> i've mentioned it around the xubuntu-devs, but it doesn't seem to be getting fixed.  i'm not sure what the issue is - does it affect other xubuntu flavors?
<j1mc> s/xubuntu/ubuntu
<persia> j1mc: Likely to be examined and fixed next week.  This being a weekend many people are doing other things (especially the kernel folk).
<j1mc> persia: ok... is it a known issue?  i think i've seen it for the past month.
<persia> j1mc: It's at least reported, but I don't know to who it is known.  To verify, try searching the bugtracker, or asking in #ubuntu-bugs.
<geser> Mithrandir: could you move libxstream-java to multiverse as it build-depends on sun-java6-jdk? Thanks.
<geser> Mithrandir: please move libini4j-java to multiverse too as it build-depends on jetty. Thanks
<persia> Mithrandir: Please don't move libini4j-java to multiverse: see bug #192336
<ubotu> Launchpad bug 192336 in jetty "Please migrate jetty from multiverse to universe" [Wishlist,Confirmed] https://launchpad.net/bugs/192336
<mjj29> are multiverse things allowed to depend on non-free things?
<mjj29> (or doesn't sun-java6 count as non-free over here)
<persia> mjj29: multiverse maps roughly to contrib + non-free, but only roughly.
<mjj29> ah, right
<mjj29> I thought restricted == non-free?
<elmo> no, restricted is non-free drivers only
<mjj29> ah, right
<persia> mjj29: There are two separations: main/universe and free/non-free.  These are orthogonal, so we have four different targets.
<mjj29> ah, right, I see
<slytherin> pitti: may I bug you about a powerpc bug?
<jwendell> openoffice is broken my hardy updates...
<geser> asac: any idea how I can get my LP cookie out firefox 3 into a file that works with python-launchpad-bugs? it should look like the cookies.txt from firefox 2
<pygi> mr_pouit, ping
<arcticpenguin380> if i want to use reiser4 would i have to recompile the kernel?
<ScottK> arcticpenguin380: Please see /topic.  For support see #ubuntu or #ubuntu+1 if you are running Hardy.
<selckin> if you have to ask, you don't want to use it
<ScottK> That too.
<keescook> geser: eek.  I hadn't run into that yet, but I'm sure to soon.  :)
<lifeless> yay -8 doesn't boot at all :(
<keescook> lifeless: really? odd hardware?
<lifeless> keescook: D430
<lifeless> keescook: kernel comes up, initramfs then spins forever; I use cryptsetup
<lifeless> but no password prompt occurs, nor does it time out to a shell for me to manually mount root
<keescook> ah, fun.  haven't tried a cryptsetup boot yet
<Elly> hey, random question: anyone know how to get root on a vax running openvms with physical access? We found one (someone threw it out) and we need to log in =P
<lifeless> I probably need to do a stop=premount or some such thing
<lifeless> and fiddle
<keescook> geser: http://people.ubuntu.com/~kees/scripts/cookies-sql2txt
<geser> keescook: thanks
<superted> does anyone know how often the language packs will be released in hardy ?
<superm1> if any members of ~ubuntu-archive are around this weekend, would you mind looking into why something hasn't published after 23 hours?  It's not in NEW or anything like that, but yet it is still not on a.u.c.
<superm1> https://edge.launchpad.net/ubuntu/+source/mythplugins/0.21.0~fixes15967-0ubuntu1/+build/515248
<geser> superm1: some packages from mythplugins (e.g. mythcontrols) got published on amd64 and ppc
<superm1> geser, that's odd.  i386 hasn't seen anything yet
<Fujitsu> ./win 6
<Fujitsu> Oops.
#ubuntu-devel 2008-02-17
<slangasek> lamont: nope :)
<lamont> slangasek: heh.
<lamont> how about now?
 * lamont bbl
<thegodfather> superm1: ping?
<superm1> hey
<thegodfather> yo
<thegodfather> where did you find that Depends: on libnet-upnp-perl?
<superm1> its in NEW
<thegodfather> i can't even find the package in debian
<thegodfather> ok
<superm1> i also built it on the mythbuntu PPA
<superm1> if you are looking for a binary version
<superm1> until it clears NEW
<thegodfather> what's the mythtv PPA?
<superm1> edge.launchpad.net/~mythbuntu/+archive
<thegodfather> thanks
<thegodfather> hmmmm
<thegodfather> why did you make a perl module Arch: any ?!?!?
<jdong> pfft beta tester elitism ;-)
<superm1> argh that's a good point
<superm1> it shouldn't be should it....
<superm1> whoops :)
<thegodfather> ok i found it somewhere else :)
<superm1> where?
<thegodfather> something is wrong in the upgrade
<thegodfather> now i have 2 backends processes running
<superm1> how is that possible?
<superm1> it stops them before starting the package upgrade
<thegodfather> ops no sorry
<thegodfather> misread
<thegodfather> superm1: http://debian.slimdevices.com/pool/main/libn/libnet-upnp-perl
<superm1> wonder why that was never brought into debian though...
<superm1> well i fixed the build so its arch all
<lamont> well.  that was fun.  not.
<thegodfather> lamont: ?
<lamont> thegodfather: re-iped the house
<thegodfather> lamont: ehhe... if you want to have fun, 2nd week of March i am going to empty/clean/fill/rewire my office :))
<lamont> heh
<lamont> I'm glad I'm too far away to come play
<thegodfather> lamont: with the amount of work that needs to be done i am almost dealing to play tickets for volunteers :)
<lamont> hey
<lamont> heh
<thegodfather> before i had the rack it was a 3 days job to empty clean refill
<thegodfather> now i expect to take at least a week
<Chipzz> \
<ion_> /
<persia> |
<Fujitsu> -
<RAOF> \
<ion_> fujitsu: More like a â :-)
<persia> ã¼ works too
<ion_> :-)
<warp10> Good morning
<Tonio_> hi everyone
<thegodfather> superm1: still around?
<thegodfather> hmm something is _NOT_ right
<thegodfather> pitti: ping?
<thegodfather> pitti: looks like something is wrong.. check this out:
<thegodfather> https://edge.launchpad.net/ubuntu/hardy/+source/mythplugins/0.21.0~fixes15967-0ubuntu1
<thegodfather> pitti: published 3 days ago
<thegodfather> pitti: there are no binaries on archive.ubuntu.com.. at least not all of them.. and the strange thing is that i can see ppc binaries there that are not supposed to be there at all
<thegodfather> pitti: not sure if it's a mirroring problem or archive admin or a combo
<thegodfather> elmo: ^^ perhaps you want to check this one too.. just in case
<persia> There's been a strange dearth of updates for a couple days: it might not just be that package.
<thegodfather> persia: indeeed... it's easier for the to track something spotted :)
<Fujitsu> thegodfather: a.u.c isn't syncing from drescher for some reason. The reason that the other binaries are there is that the i386 set was in NEW, so was published a couple of days after the rest.
<thegodfather> superm1: btw.. for all the plugins, you really want Depends: libmyth = version and not >=
<Fujitsu> cprov confirmed this morning that drescher's copy of the archive is fine.
<thegodfather> Fujitsu: ok
<Nafallo> Fujitsu: it's not a problem with archive most likely.
<Nafallo> Fujitsu: gb.archive sees the same thing.
<thegodfather> Nafallo: gb.archive rsync's from archive
<thegodfather> so if archive is broken all mirrors are
<thegodfather> what matters is that dresher is ok
<thegodfather> that excludes a bug in LP publisher
<Nafallo> thegodfather: wrong. the official mirrors rsyncs securely from internal machines.
<Nafallo> and from each other.
<thegodfather> Nafallo: no, the official mirrors don't rsync from drescher
 * Fujitsu presumes there's something else that syncs from drescher, which the mirrors sync from.
<Nafallo> thegodfather: but from other internal machines? you're not saying every mirror on the planet rsyncs from one machine that people as well use in sources.list are you? :-/
<thegodfather> Nafallo: archive.u.c is a pool of machines and there are some dedicated to official mirrors
<thegodfather> if the main rsync that pushes to this pool is broken
<thegodfather> all mirrors are brokn
<Nafallo> right...
<thegodfather> so why am I wrong according to you?
<Nafallo> not any more :-)
<Nafallo> just that archive was a single machine last time I checked :-)
<thegodfather> Nafallo: when was that? at warty release time?
<thegodfather> or when there was a security emergency where we pull off all the mirrors
<Nafallo> thegodfather: hehe. not sure mate :-)
<Nafallo> quite a while ago anyway.
<LimCore> hello
<LimCore> https://bugs.launchpad.net/ubuntu/+source/gnupg/+bug/15485
<ubotu> Launchpad bug 15485 in gnupg "kmail don't ask the phrase for gpg-encrypted mails" [Medium,Fix released]
<LimCore> I hit this bug today, should I reopen it?
<LimCore> on 7.10 amd64
<stgraber> ogra_cmpc, ogra, cjwatson: Is there any ISO available for Edubuntu with the last seed/germinate changes ? (the newest I see on cdimage is from the 14th)
<cjwatson> stgraber: it's broken right now for reasons I haven't finished debugging, since I made the major changes on Thursday and then was off sick on Friday. I'll look into it on Monday if nobody beats me to it.
<cjwatson> stgraber: BTW you should always look into the CD build logs first
<cjwatson> stgraber: start at http://people.ubuntu.com/~ubuntu-archive/cd-build-logs/
<pranith> why has the always on top feature been removed in 7.10?
<achilles> pranith: has it?
 * achilles still has it
<pranith> achilles, under which menu item do u have it?
<pranith> i dont find it in view?
<achilles> right mouse click?
<pranith> oh! :)
<pranith> i was searching it there...
<pranith> in view..
<pranith> thnx
<pranith> :)
<achilles> pranith: no problem :-)
<TheMuso> c
<TheMuso> ugh wrong tab
<TheMuso> c
<TheMuso> gah
<ion_>    c
 * ion_ sighs at the comments in bug #192310 :-)
<ubotu> Launchpad bug 192310 in hyphen "package openoffice.org-hyphenation-en-us None [modified: /var/lib/dpkg/info/openoffice.org-hyphenation-en-us.list] failed to install/upgrade: trying to overwrite `/usr/share/myspell/dicts/hyph_en_US.dic', which is also in package openoffice.org-hyphenation" [High,Confirmed] https://launchpad.net/bugs/192310
<Adri2000> icedax is a binary package in universe, but its source package cdrkit is in main. I assume it's a bug?
<ScottK> Adri2000: Not necessarily.
<TheMuso> Adri2000: There are a lot of packages with source in main, and binary in universe.
<slangase`> lamont: not then either... you could just ask your question? :)
<thom> lamont likes the big build up too much :D
<Adri2000> ScottK, TheMuso: and can a package in main suggest a package in universe? if not then there is a bug with cdrkit-doc (main) and icedax (universe)
<ScottK> Adri2000: IIRC suggest yes, recommend I don't think so, depend definitely not.
<jpatrick> what a hostname
<ScottK> jpatrick: Depending on the context it is either the machinename or the fully qualified name.
<ScottK> e.g. mail or mail.example.com
<Adri2000> ScottK: ok
<jpatrick> ScottK: either way ;-)
<TheMuso> c
<TheMuso> ugh wrong tab
<luisbg>  ROFL at Daniel's photo in planet!!!
#ubuntu-devel 2009-02-09
<slangasek> (other than a question of the distribution of developer time)
<superm1> slangasek, there have been a number of failures (not reported to the tracker though)
<superm1> slangasek, i'm attempting to see how difficult fixing some of them are.  if it's not doable today, then we'll be skipping A4
<slangasek> superm1: ok
<Adri2000> slangasek: ok. then the sooner it's in debian unstable and synced to jaunty the better. when do you think it could be uploaded to debian?
<slangasek> Adri2000: I don't know, not having looked at it at all yet.  Maybe within the week if left up to me; I can't speak for any of the comaintainers
<Adri2000> ok
<calc> is there a way to pad a number in shell, eg seq 000 150 and have the numbers show as 001, etc ?
<directhex> yes
<directhex> -w
<calc> thx!
<directhex> jms@destiny:~$ seq -w 99 100
<directhex> 099
<directhex> 100
<directhex> and so to bed
<freazer> Hi, I need some help with mdadm and update-initramfs, can anybody point me to a channel [on another server if necessary] that can help? my dpkg is completely crippled because it thinks a raid device is missing
<d-b> hi i'm not 100% sure of the current status of reporting bugs in launchpad. but last time my friend had an issue he had to login to launchpad to report it (8.10), is this the case and if so would it not be possible to send bugs for users without a launchpad id to another place, like a mailing list ?
<LaserJock> d-b: I think the ubuntu-users list has been used for that in the past. I'm not sure though if that's the current recommended process
<d-b> LaserJock: ok. but can a user report bugs there atm via the gui bug reporting interface ?
<LaserJock> d-b: I don't think so
<d-b> LaserJock: do i add this as a wishlist item ?
<d-b> and if so where should i best do this
<LaserJock> I'm not sure
<LaserJock> I think generally we discourage people from using the mailing list
<LaserJock> it should be more of a last resort I'd think
<d-b> still where should i propose this ?
<lifeless> you should start with a discussion, perhaps on the forums, or the ubuntu development mailing lists
<lifeless> either MOTU or -devel, probably -devel though the topic lines are a bit grey
<LaserJock> -devel would be the most general
<lifeless> *if* you get a consensus forming filing a bug on launchpad is appropriate, but honestly, I don't think this is percieved as a problem by the community.
<lifeless> Its pretty nice not having spam come in as new bug reports on packages, and knowing you can contact the users that filed reports.
<d-b> lifeless: right but there is a group of users who do have a launchpad account and might not want to sign up for one.
<d-b> its just the extra effort that they might not want to go to after gnumeric  or oo.o crashes with their work...
<LaserJock> d-b: sure, but generally those bugs aren't going to be very useful
<johanbr> I don't thin kthere is a problem with a dearth of bug reports.
<lifeless> d-b: you are asserting that this group is sufficiently large to generate unique bug reports, and that they will go to the effort of filing the report and working with devs to get it fixed
<lifeless> d-b: this is an unsubstantiated claim; the barrier to entry to get an lp account is nearly zero (have an email address, receive one email at it, click on a link).
<d-b> lifeless: i do not. i assume that if the bug is not already reported and enough information is able to be reported then it might be worth receiving a bug report.
<d-b> sure if it is not going to contain info then .. its pointless.
<lifeless> d-b: arguing that this barrier is higher than the barrier to file and work through a bug report in the first place is pretty doubtful as an assertion
<d-b> lifeless: right. but ok so lets consider the alternative platform... i dont' need a microsoft account to file a bug when that crashes.
<Hobbsee> and does anything happen to those bug reports, most of the time?
<d-b> i'm suggesting these bugs could be used differently.
<lifeless> d-b: actually, last time I filed a bug with MS I needed a credit card with AUD 280 on it
<d-b> Hobbsee: nothing ^^
<Hobbsee> (the MS bug reports, i meant)
<d-b> Hobbsee: i have no idea. all i know is the software doesn't get much better.
<ScottK> d-b: Mailing lists make very poor bug trackers.
<lifeless> redhat uses bugzilla, same as lp vis-a-vis accounts
<lifeless> novell, same
<lifeless> gentoo I haven't filed bugs on
<lifeless> gnome use bugzilla, needs an account too
<ScottK> Same with KDE.
<lifeless> all of sourceforge need accounts
<lifeless> savannah needs accounts
<LaserJock> lifeless: sourceforge doesn't need an account to file
<d-b> ScottK: it was just a suggestion... i agree that the use of an account is useful but perhaps if you submit a bug report and then they click on a validation email it could work better / if the gui allowed the user to sign up quickly for launchpad ?
<lifeless> LaserJock: it doesn't?
<LaserJock> lifeless: no, you can file as "anonymous"
<d-b> like i'm just trying to suggest making it easier for new users to submit bugs...
<lifeless> LaserJock: oh, eep, my bad
<ScottK> d-b: Also, in comparison to every attempt at a bug report I ever made to Microsoft got zero repsonse.  Here stuff actually gets fixed sometimes.
<LaserJock> ScottK: sometimes ;-)
<d-b> ScottK: totally agree.
<LaserJock> d-b: if we were lacking bug reports I can understand wanting to make it easier
<lifeless> d-b: I've said my bit; talk to the larger community, get consensus. I think you'll get a resounding 'not a big issue'. We have lots of bugs
<ScottK> d-b: If you have suggestions on improving the Launchpad signup process, you should probably discuss it with Launchpad developers in #launchpad.  We've really got no control over that here.
<lifeless> There isn't a perception that we are missing out on important r-c bugs
<d-b> lifeless: yeah mostly likely these would be small fidly bugs. sure.
<lifeless> (with the number of beta users we get, that do file bugs, missing an rc bug would be a surprise)
<ScottK> lifeless: It does seem to me that fewer people are reporting bugs.  I do think there is a problem, but not that LP accounts are too hard to get.
<LaserJock> d-b: the problem I see with adding an "anonymous" button is that people will just be lazy and hit that generally
<ScottK> Won't help the currenlty not to bad spam situation either.
<LaserJock> d-b: if it actually were a "use only if you absolutely can't do a Launchpad" account I could maybe agree
<d-b> LaserJock: well i meant like "email here" then you could have them click something in their email...(which could be used to spam people )
<lifeless> ScottK: I think we have a bunch of issues in bug reporting and management; as I raised in the MOTU/community sessions at UDS
<ScottK> Agreed.
<ScottK> I just don't think this is one of them.
<LaserJock> d-b: ok, but that's essentially the same thing as getting a Launchpad account, and an account is much more useful
<lifeless> ScottK: but adding anonymous accounts is rather orthogonal; and adding unverified email access is just a 'please be a spam multiplier' request
<ScottK> Yep.
<d-b> ok. i don't think that bug sure. i agree its not that important.
<d-b> *remove bug
<LaserJock> considering that we're currently at over 43k open bugs I'm not all that eager to add anonymous bug filing :-)
<Hobbsee> why not? Then one could make bug stew ;)
<LaserJock> over 47k
<LaserJock> hmm, and 40k of them are unassigned
<d-b> LaserJock: and of those 7k out of interested how many are reported upstream if required...
<LaserJock> that I have no idea
<LaserJock> I think a decent number get upstream, probably more than are assigned if I had to guess
<tritium> LaserJock: speaking of bugs, we want to invite you down to NM to speak to the LoCo.  Maybe we can have a bug jam.
<LaserJock> tritium: ok, have your people call my people and set something up ;-)
<tritium> LaserJock: roger that ;)
<LaserJock> tritium: where is Ubuntu NM HQ?
<tritium> LaserJock: Albuquerque is where most of our members are located
<LaserJock> nice
<tritium> Home of the MITS Altair.  You might say birthplace of the PC, really.
<tritium> I won't mention that Microsoft was first headquartered here too.  Well, I guess I just did.  ;)
<LaserJock> tritium: well, I'm glad you guys managed to kick them out
<tritium> LaserJock: ;)
<dholbach> good morning
<ion_> ing
<dholbach> hi ion_
<ion_> Whatâs up?
<dholbach> getting up, sipping my coffee and triaging my inbox - and it's snowing again Berlin
<dholbach> how are you doing?
<ion_> Quite okay, thanks
<ion_> About to go to sleep. :-P
<dholbach> :)
<pitti> Good morning
<pitti> cjwatson: glib pkgstriptranslations> I didn't fix it, I could never reproduce it
<pitti> cjwatson: so I'll have another look
<slangasek> morning
<pitti> hey slangasek
<slangasek> pitti: I'm working on shuffling invocation of the hotkey-setup code into modprobe.d, as we discussed; but how should this be future-proofed against the module being compiled into the kernel, or against the module being included in an initramfs?
<pitti> slangasek: it'll still have an init script, right? maybe postinst could test whether modinfo thinkpad_acpi exists, and if not, call update-rc.d?
<pitti> (just a hack, though)
<slangasek> hmm, eew :)
<slangasek> there's no way to get udev to trigger it for us? :)
<pitti> slangasek: I think there is
<pitti> slangasek: but I'd rather have Keybuk's advice for that
 * slangasek nods
<slangasek> that seems the more reliable way, though - "do this when the hardware is seen by the kernel" rather than "do this when the module is loaded"
<pitti> slangasek: if you have a corresponding device in /sys, you can still call something on that
<pitti> slangasek: maybe it's in fact better to write this as an udev rule in the first place, rather than a modprobe.d script
<pitti> since that's what we actually want (based on device, not based on module)
<pitti> slangasek: and since it gets autoloaded, it must have something in /sys that triggers it (see modinfo thinkpad_acpi|grep ^alias)
<slangasek> sure, seen that previously :)
<pitti> cjwatson: glib> one possible reason is that glib defines DEB_BUILD_OPTIONS_PARALLEL
<pitti> cjwatson: and sets MAKEFLAGS; wouldn't MAKEFLAGS apply to debian/rules itself, too?
<pitti> it has two dh_testdir etc. as well
 * pitti asks soyuz guys
<pitti> cjwatson: ok, now I'm pretty sure that the buildds define DEB_BUILD_OPTIONS="parallel=2" or something similar
<pitti> however, why does this only happen for glib2.0, and not for any other package, ever?
<pitti> ah, because it sets MAKEFLAGS
 * scizzo- thinks that someone tried to talk to him in this channel a few days ago but irssi does not have it in backlog.... :(
<slangasek> scizzo-: mis-tab-completion
<scizzo-> o...right...
<scizzo-> now I feel unimportant... :P
<slangasek> sorry :)
<pitti> cjwatson: ok, fixed pkgbinarymangler uploaded (with locking)
<slangasek> pitti: autosyncing from testing grabs us 104 updates; do you want to look them over at all before I commit?
<pitti> slangasek: I'll do some random samples, but in theory all of them should be RC fixes
 * slangasek nods
<pitti> slangasek: I read the changelogs from a to m, they all look sane to me
<pitti> so thumbs up from me
<slangasek> ack, flushing
<pitti> slangasek: for the "eliminate/minimize acpi-support/powernowd/acpid" spec Robbie asked me to contribue to, is there already an existing blueprint?
<slangasek> good question
<slangasek> doesn't look like it
<slangasek> (wiki says BLUEPRINT: TBD)
<pitti> ok
<pitti> slangasek: btw, HotkeyArchitectureSpec's release note says "removed acpi-support"; I don't think that's feasible, I'll update that
<slangasek> right
<cjwatson> pitti: yay, thanks. I suspect we'll have to delete that broken binary somehow
<pitti> cjwatson: as soon as the new pkgbinarymangler is in the buildd chroots, I'll upload a no-change glib2.0, but I don't know how automatic/manual the buildd chroot upgrade is
<pitti> I asked in soyuz, but nobody is really awake yet
<pitti> cjwatson: how was it worked around last time?
<cjwatson> SQL DELETE
<pitti> \o/
<cjwatson> Julian should know
<cjwatson> buildd chroot upgrade> I don't know offhand either, ask #is maybe
<pitti> cjwatson: we can't just reject the binaries from accepted?
<cjwatson> but they'll probably recommend waiting for Adam to wake up
<cjwatson> I tried that, it refuses
<pitti> cjwatson: hm, just worked for me
<cjwatson> curious
<cjwatson> oh, maybe I forgot to say -Q accepted, duh
<pitti> I just bumped the build prio of pkgbinarymangler
<pitti> although it seems that there is a more general problem with buildds
<pitti> none of the i386 ones grab any
<slangasek> siretart: hum, who is Fabian Greffrath?
<gaspa> seb128: Hi, saw your comment. I really wanted to do it but I haven't had time ( and I still need an account for bugzilla )
<seb128> gaspa: hi, what comment? I do comment on hundred of bugs every week
<gaspa> lol, sorry...
<gaspa> bug #327003
<ubottu> Launchpad bug 327003 in gnome-panel "add transparency to panel run dialog." [Wishlist,Confirmed] https://launchpad.net/bugs/327003
<directhex> he's a busy bunny is seb128
<seb128> ah ok, thanks for the work on it, the screen looks good ;-)
<dholbach> but normally seb128 remembers all the bug numbers
<dholbach> seems like he's getting old :)
<slangasek> haha
<seb128> directhex: I will look at your sync requests today if nobody else is quicker
<directhex> cool, thanks
<gaspa> seb128: in the meantime, do you think it can be included? Or it needs review?
<seb128> dholbach: don't worry I just got a cold, I should be back to normal in a few days ;-)
 * directhex is a little concerned @ debian NEW delays right now. seems the ftp-master team is busy with other things
 * dholbach hugs seb128
<seb128> gaspa: I would prefer having comments from somebody who has a clue about all that, would it work for people who have no compositor?
 * seb128 hugs dholbach
<gaspa> seb128: it works for me, without compositor.
 * directhex checks seb128's lp account, ensures he's in the dholbach-huggers group
<slangasek> jelmer: bzr-svn 0.5.0-1 build-depends on python-subvertpy, not in the archive (Debian or Ubuntu)?
<jelmer> slangasek, subvertpy is in NEW atm
<slangasek> ok
<jelmer> slangasek, there's a package in the bzr PPA
<jelmer> slangasek, I was just talking about dholbach about the best way to get it into jaunty
<slangasek> one that I can sync into Ubuntu, so I can sync bzr-svn? :)
<slangasek> ok
<directhex> jelmer, oh, the joys of uploading apps when their deps are in NEW for a few months :)
<directhex> jelmer, we've got that problem for finishing off the mono 2.0 transition \o/
<dholbach> jelmer: just add the link to the PPA on the bug report
<jelmer> dholbach, will do
<dholbach> super
<slangasek> jelmer: and how about bzr* uploads to Debian unstable? :)
<slangasek> jelmer: the version of python-subvertpy in Debian NEW is less than the one in the ppa; what do you think about getting 0.6.1-1 uploaded to Debian NEW, and then fakesyncing it into Ubuntu?
<directhex> slangasek, problem is if he doesn't wait for the current one to clear NEW, then it's to the back of the queue with the new version
<slangasek> that's not my understanding of the Debian NEW queue ordering
<directhex> slangasek, it's my experience.
<slangasek> seb128: eh?  it's my archive day and I'm in ~/syncs :)
<seb128> slangasek: I did ssh, ls, noticed and closed my ssh ... ie if somebody is hijacking your syncs that's somebody else ;-)
<slangasek> hrm
 * pitti is innocent
<pitti> well, at least wrt. to cluttering syncs ATM :)
<seb128> we have 3 new people who have ssh access now, maybe we need to start being carreful with locks
<slangasek> seb128: https://bugs.launchpad.net/ubuntu/+source/bzr-svn/+bug/325930/comments/3 - token collision or something?
<ubottu> Ubuntu bug 325930 in bzr-svn "Please sync bzr-svn 0.5.0-1 (universe) from Debian experimental (main)." [Undecided,Fix released]
<slangasek> seb128: I was addressing you because yours was the name in the email :)
<seb128> urg
<seb128> how did that happened?
<slangasek> good question
<seb128> james_w: hello?
<seb128> slangasek: did you run syncbugbot at all today?
<slangasek> seb128: yes, that's what I've been using
<slangasek> I just don't understand why I'm getting your cookie
<seb128> slangasek: it seems you are using my launchpadid for some reason?
<siretart> slangasek: a very nice and active contributor to pkg-multimedia.
<siretart> slangasek: why do you ask?
<lool> siretart: I guess because of his debian-devel@ post
<james_w> hello seb128
<slangasek> siretart: what lool said; a curious post citing ffmpeg as an example
<siretart> ah, right, ffmpeg is a delicate example. we (lool, fabian and I) have been discussing 'weak' build dependencies last week and I suggested that we should raise that topic on debian-devel
<slangasek> ah
<slangasek> then I repeat here what I said on debian-devel: opportunistic build dependencies are a terrible idea :)
<cjwatson> wouldn't hold your breath even if it were a good idea, that idea has been floating around for approximately a decade
<directhex> "weak" build deps?
<siretart> however the mess with alsa not being available on non linux arch makes the build depends line look horrible as well
<directhex> as in build-suggests?
<cjwatson> "install this build-dependency if it's available, but don't complain if it isn't"
<directhex> build-recommends!
<directhex> i like it. make it so, number one!
<cjwatson> siretart: my recommendation would be to take the approach used by debian-installer
<lool> I didn't know about the control fields proposal and all
<siretart> well, in effect that is what ffmpeg needs. In multiverse there are additional libraries ffmpeg can make use of
<cjwatson> siretart: build-deps written out line-by-line in debian/control, debian/genbuilddeps can be run manually to sync this into the actual Build-Depends line
<lool> (I share the concerns raised on debian-devel@, but saved myself the time to word them properly since others did)
<cjwatson> siretart: so when merging you can throw away any changes to the Build-Depends line itself and just run debian/genbuilddeps after resolving all the other conflicts
<lool> cjwatson, siretart: Right, we have something like this in gstreamer packages
<cjwatson> this makes it a lot easier to deal with complex build-deps
<directhex> lool, OOo writes its own buil-deps too
<lool> And we allow end users to add some features by rebuilding the packages with some flags
<siretart> hm. debian/control is already generated in ffmpeg...
<lool> cjwatson: But I guess you need to run that and upload a different source to ubuntu though
<cjwatson> lool: yes, I don't regard that as a major problem though
<lool> It's not, but one of the goals is to have the same source package in Debian and Ubuntu; I don't think I would mind libfaad-dev | ubuntu-minimal though
 * slangasek chuckles
 * lool already has some hacks for backports, I think Ubuntu could be supported here as well
<cjwatson> aesthetically horrible but probably functional
<directhex> cjwatson, it's a delightfully elegant hack, no?
<lool> Let's call it pragmatic!   :-P
<cjwatson> directhex: your notion of elegance and mine are clearly different :)
<directhex> hacks which make you groan & go "that's horrible!" are the best kind!
 * slangasek wails and gnashes his teeth at the elegance
<directhex> well, not as good as the ones that make you got "oh, that's just..." at a loss for words to convey the beauty of it
<cjwatson> my notion of elegance is closely associated with generality
<apw> evand, ping
<evand> apw: pong
<apw> evand, just looking at usb-creator and i see symlinks say "need to fix this"
<apw> wondering if you have any context on why its not enabled, security perhaps/
<apw> ?
<evand> vfat doesn't support symlinks, AIUI
<apw> ahhh, its a vfat fs we make
<apw> yeah that would break it
<evand> the "need to fix this" comment is poorly written :).  It should say something to the effect of "does this subtly break anything?"
<apw> well that answer to that is yes :) it breaks the alternate installer
<apw> specificlaly the cd upgrade part, but its probabally easier to fix the way it works
<evand> hooray
<pitti> thekorn: good morning
<pitti> thekorn: do you know how to entirely disable cookie caching in ~/.python-launchpad-bugs.conf?
<evand> indeed; we're in a bit of a bind from the usb-creator perspective as we want to stick with vfat to ensure compatibility with already formatted by Windows USB disks.
<apw> evand, yeah, not sure its sensible to try and fix it, the link thats missing is to a directory too
<apw> so the chances of representing it are low
<evand> ah, ok
<thekorn> pitti, hi, I don't think there is a switch for this (yet), let me look at the code to be sure
<pitti> thekorn: ok, thanks
<james_w> cjwatson: https://code.launchpad.net/~james-w/ubuntu-seeds/platform.jaunty.apt-transport-https for you to review at your convenience.
<james_w> cjwatson: it adds it as Recommends on standard
<thekorn> pitti, hmm, no, no such option and no easy way to not write the cookies to thiss file
<ogra> seb128, if i delete mail in my inbox my evo reliably crashes, is that known already ?
<seb128> jaunty?
<ogra> yep
<seb128> there is a crasher which is known an seems to be triggered when deleting mails which have images if you have the option to load those
<ogra> though i didnt try the delete icon in the toolbar yet ... i'm used to use the del key
<ogra> seb128, hmm, doesnt happen with the toolbar icon
<seb128> should not make a difference
<seb128> it might depends of the emails
<ogra> but it was spam that got through which included the last two times at least
<ogra> *included pics
<seb128> right, that's a known issue
<seb128> it tries to load the image and you deleted those before it was done
<ogra> ah, k
<ogra> ah, it doesnt seem to happen if i'm fast enough (before it starts the download)
<ogra> only if the download process actually runs
<seb128> right
<seb128> known issue no need to open a new bug
<ogra> great :)
<cjwatson> apw: we should probably just remove our reliance on that symlink. Is it just cdromupgrade? I reassigned that bug to update-manager rather than closing it ...
<cjwatson> james_w: merged, thanks
<james_w> thanks cjwatson
<apw> cjwatson, yeah its still there, i was looking at fixing usb-creator, but thats not going to happen now i know the underlying reason
<apw> will look at fixing the script instead
<cjwatson> the dists/stable and dists/unstable symlinks are definitely legacy
<apw> i assume those refer to the debian aliases for their releases
<ogra> cjwatson, is  /build/config/armel/ixp4xx/netboot.cfg originally coming from debian like that (despite your recent changeds indeed) ?
<ogra> (in d-i)
<cjwatson> ogra: yeah
<cjwatson> apw: right
<ogra> weird, someone on the debian-arm ML pointed out their ernel is armeb so wouldnt need endianess swapping
<ogra> *kernel
 * ogra tries to find out why ours doesnt boot at all
<cjwatson> ogra: http://bazaar.launchpad.net/~kamion/debian-installer/main/annotate/head%3A/build/config/armel/ixp4xx/netboot.cfg (though that branch needs an update)
<ogra> right, both call devio ... strange ...
<ogra> i can boot the kernel standalone but not from di-nslu2.bin
<apw> is it normal for a package to require you have python-distutils-extra installed for a source build and not tell you?
<ogra> should be in the build-deps either by itself or through a dep of something there
<jelmer> slangasek: sorry, was away
<jelmer> slangasek: I was waiting until squeeze before uploading to sid again, although new RC-bugs would be very unusual at this point
<jelmer> directhex: I was under that impression as well, though I've never tried it in fear that my uploads would end up at the tail of the queue
 * directhex REJECTs jelmer 
<apw> mvo, seems you own update-manager, is that a direct debian sync?
<ogra> heh
<ogra> is u-m in debian ?
<apw> dunno hard to tell, its one of those things where the normal" version number tell you everthing"  rule falls down
<apw> to restate things, i have a patch for it, what do i do with it
<apw> it behaves oddly as it claims to have a real maintainer, unlike most packages
<cjwatson> it's maintained in Ubuntu
<ogra> right
<cjwatson> (in the absence of mvo telling you otherwise) either attach the patch to a bug report; or create a branch (since it's in bzr), commit your patch there, and send a merge request
<ogra> apw, the control file should tell you about the original bzr branch
<cjwatson> debcheckout update-manager; cd update-manager; fiddle; bzr push lp:~apw/update-manager/name-of-your-branch
<ogra> pfft, always these advanced tools
<apw> ahh missed the "its in bxr" whine, its simply not loud enough
 * slangasek fixes apt to depend on figlet
<directhex> slangasek, figlet is non-free. try toilet
<mvo> apw: hello, what is the issue with update-manager?
<slangasek> oh, thank you - would've been terribly embarrassing to get the wrong banner printer pulled into the base system ;)
<apw> mvo, an issue with cdromupdate when converted to a usbstick.  symlinks get lost, it doesn't work.  simplest solution to avoid using the links.  am just pushing a bzr branch with a proposed fix
<mvo> apw: aha, cool. just give me branch location when the push is finished
<apw> mvo will do, its a trivial change
<directhex> slangasek, well, putting apt into restricted would be awesome, but...
<slavik> will evolution come with the libmapi plugin in 9.04?
<seb128> slavik: evolution-mapi will be available, not sure if it will be in the default installation or universe though
<directhex> evolution-mapi is the non-OWA exchange thing, yes?
<slavik> yes
<directhex> neato
<slavik> it's supposed to be part of gnome 2.26
<seb128> that's the new version using openchange
<slavik> but it also depends on samba4
<slavik> hence me asking
<seb128> it's waiting for review right now
<seb128> slavik: it will be in universe for sure
<slavik> seb128: k, thanks ... I tried building it myself, but couldn't get it to work
<slavik> awesome
<seb128> there is a package available in a ppa, look to the need-packaging bug on launchpad
<slavik> looking, heh
<slavik> found it
<apw> mvo, branch should be here, hopefully I handled the changelog right, let me know if you need me to change it or have any commentslp:~apw/update-manager/cdromupgrade-avoid-links
<mvo> apw: thanks, merging now
<mvo> apw: thanks, looks good
<apw> mvo, cool
<slangasek> cjwatson: can you help me understand why adding '* Extra-Exclude: libjtidy-java-doc' to ubunt.jaunty/supported doesn't appear to have affected component-mismatches?
<directhex> woo, m-a 0.4
<Laney> synced?
<ogra> m-a ? who is using that in times of dkms
<Laney> mono-addins not module-assistant
<ogra> haha
<ogra> yay for abbreviations
<cjwatson> slangasek: my guess would be that it needs to be done in kubuntu.jaunty etc.
<seb128> Laney: yes, I did the sync now
<Laney> :D
<Laney> and now we can sync f-spot
<directhex> Laney, which means you can become the proud owner of an f-spot sync if you like
<Laney> later
<seb128> Laney: are you sure?
<Laney> actually it might FTBFS, there was some weird problem
<Laney> yes
<seb128> Laney: http://launchpadlibrarian.net/22054264/debdiff
<Laney> is that the one from chriscoulson?
<seb128> Laney: that's a pending sponsoring request
<Laney> (my internet isn't working)
<seb128> Laney: yes
<Laney> right, well I've put that into Debian SVN
<Laney> so it'll be in -2
<seb128> Laney: there is ar4545_locales-import change listed there
<seb128> ok so we can't sync yet
<seb128> it updates the build-depends too
<Laney> grr
<seb128> Laney: have you looked at the other suggested changes for notebooks, etc?
 * Laney mutters about having been told sooner
<Laney> no
<seb128> Laney: told what? we can sync but that's as cheap to upload this debdiff for now and sync -2 when it will be uploaded to debian
<seb128> being is sync in nice but should not stop bug fixes to be uploaded to ubuntu
<Laney> there could always be the next patch
<Laney> which leaves us constantly chasing the sync but never getting there
<seb128> well, I would sync if the build-depends was correct
<seb128> but if we sync f-spot now it will not got to dep-wait for the new version but ftbfs directly
<seb128> if you can get that fixed in debian we can sync
<Laney> that's in ther etoo ;)
<seb128> there being svn or experimental?
<Laney> svn
<seb128> we can't use that for syncs ...
<seb128> anyway let's upload to debian can be synced
<seb128> thanks for you work there ;-)
<seb128> let's -> nex
<seb128> next
<slangasek> cjwatson: strange; I can't seem to find jtidy anywhere in germinate-output/{ed,k,}ubuntu/all
<slangasek> it's openoffice.org -> lucene2 -> jtidy, but it doesn't show up at all...
<slangasek> ohhh, because lucene2 is an obsolete OOo build-dep
<slangasek> ok, let's fix it that way then :)
<cjwatson> all_edubuntu_jaunty_ia64:classpath-doc                             | classpath                             | libjtidy-java-doc                                | Ubuntu MOTU Developers <ubuntu-motu@lists.ubuntu.com>                         |        30605094 |          313984
<cjwatson> frex
<slangasek> right, which will go away when the ports catch up on OOo
<cjwatson> yeah, it shows up only on ia64/powerpc/sparc
<cjwatson> which explains why you don't see it on people.ubuntu.com's germinate-output, which is i386 only; I looked in cocoplum:/srv/launchpad.net/ubuntu-archive/ubuntu-germinate/
<slangasek> ok
<pitti> mvo: thanks for testing metacity-clutter! *hug*
<mvo> pitti: cheers
<mvo> pitti: having debs would be cool too, its a bit cumbersome though
<mdeslaur> Laney: I can't reproduce your vim upgrade bug
<mdeslaur> Laney: what packages did you have installed before the upgrade?
<Laney> mdeslaur: I think you might need vim-gnome?
<Laney> or maybe vim-full
<mdeslaur> Laney: ok, will try, thanks
<jelmer> slangasek, Am I mistaken to think that I'll lose my position in NEW by uploading a new version of a package?
<slangasek> jelmer: I don't know.  In the past I've understood that it would not change the package's position in the queue, but it's possible the current ftpmaster policy perversely punishes uploaders for fixing bugs in packages that are still in NEW
<cjwatson> or perhaps just that ftpmasters operate on shiniest/easiest first :-)
<pitti> slangasek: just committed the last sleep quirk from acpi-support to hal-info, will do an upload of hal-info; want me to rip out those bits from acpi-support, or want to wait for spec review or something else?
<slangasek> pitti: well, please go ahead and at least commit the change to the acpi-support branch.  Which bits are the sleep quirks? suspend.d?
<pitti> slangasek: *.config (see the spec I just wrote, I answered to Robbie's mail)
<slangasek> ah, the lib/*.config
<slangasek> so all of these quirks are known to hal-info?  Rockin'
<pitti> there wasn't a lot left, just three commits
 * slangasek nods
<pitti> and as explained in the spec, ACPI_SLEEP should just go completely
<jelmer> slangasek, I've uploaded 0.6.1-1 to NEW and uploaded the matching source to http://people.debian.org/~jelmer/new/subvertpy_0.6.1-1_source.changes; will also mention that in the bzr-svn bugreport
<slangasek> jelmer: cheers
<slangasek> pitti: you wrote in the spec that you committed your changes to acpi-support bzr - ENEEDSPUSH?
<pitti> slangasek: still working on it
<slangasek> ok
<pitti> (sorry, pressed Enter too fast)
<slangasek> :-)
<pitti> slangasek: pushed
<pitti> need to stop working on this now, I have a job interview soon
<slangasek> pitti: ta
<slangasek> pitti: as an interviewer or an interviewee? :-)
<pitti> slangasek: the former :)
<slangasek> oh good, so I don't have to worry with you competing with me for this job I'm applying for at Novell ;-)
<jdong> pitti: hope you don't get an answer like "Because ISO/IEC 14882:2003 section 14.1 paragraph 4 said so" from your interviewee....
<jdong> :D
<jdong> that went down in my books as the most impressive answer for why you can't use float or double literal as a template parameter...
<slangasek> pitti: one consequence of rev 109 would appear to be that acpi-support can still be invoked manually for suspend/resume, but will do Wrong Things on the quirked platforms, so we should follow through on nuking the suspend handling completely?
<pitti> slangasek: yes, that's the idea
 * slangasek nods
<pitti> slangasek: but I want to drop it carefully, i. e. for each removal do grep -r's of reverse references
<slangasek> sure
<pitti> IMHO pm-suspend and friends should be the only supported interface
<slangasek> I think we want to take care of the top of the tree before the next upload, at least, to make sure the wrong suspend method doesn't get called
<pitti> slangasek: AFAICS, handling the model specific acpi events should be the only thing which we should keep
<pitti> slangasek: the most crucial bit to remove is now /etc/acpi/events/sleepbtn and friends
<slangasek> ok
<pitti> I guess that's what you mean with "accidentally invoke"
<slangasek> yes
 * pitti reuploads his rejected g-p-m; race condition with apt-get source and another upload
<slangasek> pitti: note the Vcs-Bzr field as well, then :)
<ScottK> slangasek: Could I have a moment of your time with your archive-admin had on?
<slangasek> sure
<slangasek> pitti: btw, when ripping out events/sleepbtn, there are probably a few dozen LP bugs to close ;)
<ScottK> I've prepared the input for syncbugbot for the clamav rdepend backports.
<pitti> slangasek: \o/
<slangasek> ScottK: ok
<ScottK> http://paste.ubuntu.com/116088/ and my LP cookie should be available.
<ScottK> I can go ahead and accept the source backports (which I pre-loaded over the weekend).
<slangasek> ScottK: these are intrepid or hardy?
<ScottK> The target is Hardy.  These are all from Jaunty.
 * slangasek nods
<pitti> slangasek: g-p-m uploaded and bzr-pushed
<slangasek> pitti: oh, also, please hold off on uploading those acpi-support rip-out-the-guts changes until I have a chance to talk further with Bart Samwel (Debian maintainer)
<slangasek> (i.e., until i catch up on my email)
<slangasek> pitti: g-p-m> thanks :)
<pitti> slangasek: noted; right now it's only half-baked anyway (sleep button still active, etc.)
 * slangasek nods
<ScottK> slangasek: Thank you.
<slangasek> ScottK: no prob
<dholbach> slangasek: bug 327209 (for bug 325930)
<ubottu> Launchpad bug 327209 in ubuntu "Please sync subvertpy from Debian NEW" [Undecided,Confirmed] https://launchpad.net/bugs/327209
<ubottu> Launchpad bug 325930 in bzr-svn "Please sync bzr-svn 0.5.0-1 (universe) from Debian experimental (main)." [Undecided,Fix released] https://launchpad.net/bugs/325930
<slangasek> dholbach: right, thanks
 * dholbach hugs slangasek
<dholbach> gracias
<slangasek> (not that we can actually do a sync from NEW, but we'll do something that resembles it :)
<dholbach> slangasek: right... put the link to the .dsc file there
<slangasek> ok, cool
<alex-weej> mvo: hey
<alex-weej> you committed a change of mine to compiz-fusion-plugins-main
<alex-weej> it's the first time i've done a debdiff properly
<alex-weej> i got 4 emails shortly afterwards saying it failed to build! :(
<mvo> alex-weej: no worries
<ScottK> alex-weej: That'll be due to kernel issues in sparc, ia64, powerpc, and hppa
<alex-weej> ok... good :D
<mvo> alex-weej: I adjusted the change slightly to make it into a cdbs patch instead of a inline patch, but otherwise it was fine
<alex-weej> mvo: yeah i realised it was using cdbs soon after uploading
<alex-weej> by the way, do you know much about compiz configuration handling? i opened a bug yesterday about a default value not actually being the default...
<alex-weej> the window resize plugin to be precise
<alex-weej> in gconf, it is set to 0 (normal), but it clearly behaves as rectangle until i change it then change it back on a fresh intrepid installation
<alex-weej> i figured it may also bork for that config file change i submitted
<alex-weej> if there's some weird interplay between compizconfig/gconf
<alex-weej> (yay for unnecessary abstractions)
<seb128> alex-weej: there is different config backend are you sure you are using the gconf one?
<alex-weej> i'm not sure of anything with compiz to be honest
<mvo> alex-weej: for config default changes, best use the metadata/*.xml files
<alex-weej> mvo: that i did for my patch
<mvo> alex-weej: they auto-generate gconf schemas
<alex-weej> right, that's sort of what i suspected
<alex-weej> when does the gconf schema get generated? build time?
<mvo> hm, and that did not work?
<mvo> yes, build time
<alex-weej> i'm not sure i haven't actually tested it -- let me find the bug i reported
<alex-weej> https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/326690
<ubottu> Error: Could not parse data returned by Ubuntu: timed out (https://launchpad.net/bugs/326690/+text)
<alex-weej> mvo: at build time of plugins-main or backend-gconf?
<ogra_> Keybuk, hey ... you had a hack for bootchart to make it possible to measure desktop startup times iirc, can you explain NCommander how to do that (or point him to a doc)
<Keybuk> build the current bootchart from source
<Keybuk> boot with bootchart=nostop
<Keybuk> then run sudo /etc/init.d/stop-bootchart start once the desktop is up
<NCommander> Keybuk, I'm going to guess that requires initramfs support
<NCommander> (or is there a way I could modify bootchart not to require that)
<Keybuk> no, the current bootchart will work without an initramfs too
<Keybuk> but you do have to build it from source, because building java appears to be broken on the builds
<NCommander> Oh, very handy
<mvo> Keybuk: thanks for the hint for the metacity-clutter branch, it does indeed provide sme additional effects over the stock metacity compositor :)
<Keybuk> mvo: did you build it from git?
<mvo> Keybuk: yes
<kirkland> fresh install of alpha4, logging in through gdm loads the desktop background but just kinda hangs there
<kirkland> some noise about pulse-audio in /var/log/messages
<lool> cjwatson: Hmm could you advice on how to pull wireless-crda in main?  I don't quite know about hardware specific packages (in this case wifi): how should these be pulled on some installs and upgrades?  bug #325801
<ubottu> Launchpad bug 325801 in ubuntu "Main inclusion request: wireless-crda" [Undecided,New] https://launchpad.net/bugs/325801
<kirkland> (compiz was to blame for my problem)
<ogra> yeah, thats an easy victim ... as NM is :)
<pitti> slangasek: FYI, uploading a new pm-utils now with the last bit of acpi-support-edness dropped (vbetool counterpart)
<james_w> pitti: I was just about to prepare a debdiff for pm-utils
<james_w> bug 326183
<ubottu> Launchpad bug 326183 in pm-utils "No need to run hwclock on suspend/resume" [Undecided,New] https://launchpad.net/bugs/326183
<slangasek> damn, I was working on fixing the pm-utils side of 59695 - ok, will queue my patch :)
<james_w> any chance you could fold that in?
<pitti> oh, wow
<james_w> heh
<pitti> sorry, I wasn't able that so many people were hammering on it ATM :)
<slangasek> <cough>bzr</cough>
<pitti> slangasek: it's not ATM
<slangasek> I know
<slangasek> :)
<pitti> anyway, package should hit https://edge.launchpad.net/ubuntu/+source/pm-utils in one minute
<slangasek> ack
<pitti> james_w: I'll be happy to sponsor it, or just send it to slangasek if he'll do an upload anyway?
<pitti> james_w: otherwise just subscribe me to the bug afterwards, I can sponsor it
<james_w> sure, thanks
<pitti> ok, before I step on anyone else's toes when doing sponsoring...
<pitti> seb128: ok for me to upload totem{,-pl-parser}?
<pitti> oh, -ENOSEB
<NCommander> Keybuk, I got bootchart setup, but I'm not sure where/if I need to kill the process at the end of the graphical startup (bootchart.org source ball says nothing about killing it, the init.d item for Ubuntu seems to be Ubuntu specifc)
<Keybuk> then run sudo /etc/init.d/stop-bootchart start once the desktop is up
<pitti> Keybuk: incidentally I was playing around with that as well yesterday
<pitti> Keybuk: and I couldn't figure out how to update /etc/bootchart/desktop
<pitti> erm, /etc/readahead/desktop, I mean
<Keybuk> pitti: I was going to say, somebody's confusing bootchart and readahead there ;)
<Keybuk> pitti: you don't have a separate /usr ?
<pitti> Keybuk: when I used profile and disabled stop-readahead, it'd make /boot huge, and not touch desktop
<pitti> Keybuk: no, I don't; do I need to?
<Keybuk> if you don't have a separate /usr, /etc/readahead/desktop is unused
<pitti> ah, ok
<Keybuk> if you do have a separate /usr, it's update automatically
<pitti> that explains why my desktop startup with cold cache is so excrutiatingly slow
<Keybuk> to get it to include desktop, rm /etc/rc2.d/S99stop-readahead and run the init script manually when the desktop is up
<Keybuk> no it doesn't
<Keybuk> the default lists don't include the desktop
<pitti> Keybuk: i. e. this puts everything in /etc/readahead/boot (guess that should work fine)
<Keybuk> right
<seb128> pitti: is your bootchart available somewhere?
<pitti> seb128: still need to do a current one
<seb128> ok
<slangasek> james_w: I have my pm-utils changes merged onto pitti's last upload; feel free to ping me when you have a fix for 326183
<james_w> slangasek: http://pastebin.com/f4d3ec233
<slangasek> james_w: ah, looks good :)
<slangasek> james_w: is there any sort of reference for the 'no longer needed' bit?
<james_w> slangasek: will the tinitus and general numbness I feel following the 3 hour discussion between Scott and Colin on clock handling do?
<slangasek> heh
<Keybuk> it was a complicated topic ;)
<james_w> Keybuk: do you have the wiki page?
<Keybuk> wiki.ubuntu.com/HardwareClock
<slangasek> Keybuk: could you confirm that we don't need to run hwclock on resume for current kernels?  That's what I remember, but my memory is fallible
<james_w> thanks
<Keybuk> your filesystem may be at risk if you fail to keep your system clock in sync with your hardware clock
<Keybuk> slangasek: I can confirm
<calc> Riddell: what is the multimedia framework for KDE?
<james_w> it was an interesting discussion, but I really didn't want to know that much about clocks
<Keybuk> the kernel clearly resets the system clock from the hardware clock on resume, based on the delta it measured on suspend
<slangasek> Keybuk: and that's true for resume from hibernate, as well as resume from suspend?
<superm1> pitti, regarding http://cgit.freedesktop.org/hal-info/commit/?id=d3509c6af4c939d0b52dc4314b364bd4c4c33228 , I suspect you need more granularity to that quirk.  The system probably ships with multiple different graphics cards, and you may be altering the behavior for all of them with such a quirk
<Keybuk> slangasek: as far as the kernel is concerned, they're the same
<slangasek> okie
<Keybuk> it's in the RTC driver _suspend()_resume() code
<james_w> Keybuk: the first section of that page asserts that the system clock is unreliable, and then states that it is reliable two lines later
<calc> Riddell: it doesn't use gstreamer directly does it? iirc i had read at one point it can use it but not by default?
<Keybuk> james_w: I probably got confused between reliable and accurate ;)
<Riddell> calc: currently we use xine via the Phonon API
<Keybuk> james_w: ah, no, I just confused myself - fixed
<Riddell> calc: Phonon does have a gstreamer backend but I believe it's not very good as well as the usual gstreamer lacking DVD menus
<calc> Riddell: ok so if OOo were to somehow grow native multimedia support for KDE it would need to use Phonon?
<Keybuk> system clock = accurate, hardware clock = reliable, network clock = both but slow
<Riddell> calc: that would be the best way yes, although it could just use gstreamer or whatever directly
<calc> Riddell: ok, yea it currently uses gstreamer, just wondering if is is good enough like that or if it would be wishlist to get phonon support
<stgraber> ogra: for that ltsp install failure, /cdrom is already mounted in /target, what's the best ? Drop --mount-cdrom ?
<ogra> stgraber, yes, that was a temp. workaround anyway
<Riddell> calc: it should work fine, just means a second multimedia library on the CDs, not the end of the world
<NCommander> Keybuk, I have bootchartd setup, but it seems to immediately return when loaded as init=/sbin/bootchartd
<stgraber> ogra: ok, will do in the next upload
<calc> Riddell: ok
 * calc bbl, finding dinner
<Keybuk> NCommander: where did I tell you to load it like that?
<Keybuk> NCommander: just boot normally
<ogra> NCommander, i'm pretty sure the package works as advertised if Keybuk tells you so ;)
<ogra> he's its biggest user
 * NCommander has no doubt of the packaging working, it just happens the user in this case should probably not read the upstream docs in favor of asking questions to Keybuk 
<Keybuk> well, yes ;)
<Keybuk> the only bit of the upstream package we use is the java code to draw the pretty chart
<Keybuk> everything else is custom to Ubuntu
<NCommander> Ah, I wasn't aware of that
<slangasek> james_w: curious how suspend/resume seems faster with this patch applied ;)
<Keybuk> slangasek: the hwclock patch?
<Keybuk> because you're not sleeping for >1s on suspend to sync the two, and >1s on resume to sync them the other way
<pitti> superm1: possibly; but the previous change was a regression, so I wanted to fix the regression first
<pitti> superm1: if someone has a similar system, and different graphics card, we can still fix it for that
<slangasek> Keybuk: er, yes, I was there all last week, I know why it's faster... :)
<superm1> pitti, okay
<Keybuk> slangasek: but you're still curious?
<slangasek> Keybuk: no, I'm "curious ;)"
<Keybuk> ahh
<Keybuk> I'm tired
<bryce> W: Bizarre Error - File size is not what the server reported 55233 27617
<bryce> heh
<bryce> (reran apt-get update and it went away, but funny, haven't seen "Bizarre Error" before from apt)
<shankhs> hi guys I am learning shell programming and GUI development in Linux , I just made a small program of stopwatch which GUI program you prefer Qt or GTK?Why?
<shankhs> The shell program will be the back end for the front end GUI
<shankhs> Please help I am really confused ...
<shankhs> I know here only ubuntu development related stuff is discussed but isnt Qt and gTK part of ubuntu?
<Keybuk> Ubuntu uses GTK+, Kubuntu uses Qt
<shankhs> Keybuk: what a beginner should prefer?Do you know any good tutorial for both of them?Thanx
<cjwatson> lool: the ship or server-ship seed or something like that would be the usual place, but getting it installed on upgrades is sort of tricky
<cjwatson> lool: I don't suppose it would be appropriate for the kernel image package to recommend it?
<Keybuk> shankhs: are you more familar with C or C++ ?
<shankhs> Keybuk: ya i have been programming in C/C++ for 3 years now
<Keybuk> shankhs: which?  they're quite different languages
<shankhs> Keybuk: I first learned C and then C++
<Keybuk> shankhs: well, GTK+ is pure C; Qt is pure C++
<shankhs> Keybuk: hmmm...
<shankhs> Keybuk: so I think I will go for GTK+
<shankhs> Keybuk: thanx for your help
<shankhs> Keybuk: Do you know a good tutorial for GTK+?
<ogra> shankhs, http://library.gnome.org/devel/gtk-tutorial/stable/ ... first hit on google for "gtk tutorial"
<calc> wow gnome locked up on me again, for the second day in a row
<calc> i clicked on the clock applet and it hung hard
<calc> the apps i am running still work but it appears the panel at minimum is dead
<ogra> dont click on the clock applet then :)
<calc> ogra: :-P
<jdong> lol
<jdong> remember that one bug about clicking panel applets in a certain sequence triggers a mouse-lockup?
<calc> jdong: no that sounds fun too
<jdong> it always amuses me how people find bugs like that and reproduce it :)
<jdong> I believe it's some combination of right and middle clicking
<jdong> it locks the cursor into the draggy-hand-thingie
<calc> Riddell: mandriva does not have qt support, they just totally turned off qt/kde support entirely
<calc> ok well i hope i can brb, need to kill gnome
<calc> hmm kill -HUP fixed it
 * ogra hands calc a KDE shotgun
<slangasek> pitti, cjwatson: hrm, very strange; trying to test the pm-utils fix for bug #59695, and I'm finding that in jaunty, something is overriding the disk pm setting that I'm applying when disconnecting AC... I see only one call to hdparm with the right setting, but when I check afterwards, -B254 is set instead of -B128
<slangasek> pitti, cjwatson: and if I call hdparm directly, this isn't the case
<ubottu> Error: Could not parse data returned by Launchpad: timed out (https://launchpad.net/bugs/59695/+text)
<slangasek> killing hal and g-p-m appears to make no difference
<shankhs> ogra : thanx
<slangasek> pitti, cjwatson: ok, no, ignore me; hdparm is being difficult generally
<ogra> lets just drop it from the archive ...
<ogra> solves all probs with it
<CarlFK> anyone know a phone number for Canopus (want to ask some questions about the twinpact)
<CarlFK> whops, wrong #chan - sorry
<cjwatson> Keybuk: HardwareClock> generally excellent, but --stepsys => --hctosys?
<cjwatson> Keybuk: presumably with --hctosys in udev, udevadm trigger becomes especially obvious since your clock changes :)
<cjwatson> Keybuk: or is --stepsys new?
<cjwatson> yeah, I can't read
<cjwatson> I love the phrase "legacy APIs such as stat()" - it clarifies what a useless word "legacy" is
<cjwatson> it can mean anything from "will be removed next week" to "your entire system depends on it"
<kees> why would stat() be considered legacy??
<lool> cjwatson: I guess a recommends on the kernel image package is what we will use then; thanks
<cjwatson> kees: time_t rather than struct timespec
<slangasek> kees: meet Keybuk
<lool> cjwatson: I have no problem with that, just not enough good judgment to take the best decision
<slangasek> kees: anything that wasn't invented next week is legacy :P
<Keybuk> cjwatson: --hctosys is an existing call that copies the hardware clock to the system clock adding a delta for timezone if necessary
<cjwatson> Keybuk: s'ok, I worked it out
<Keybuk> since the system clock has already been copied from the hardware clock by the kernel, there's no reason to do that -- all we need to is step the system clock by the timezone delta
<Keybuk> slangasek suggesting doing that in hwclock to keep it all in the same place
<cjwatson> the only thing I'd say there is that it would be nice, as a sanity check, to read the hardware clock and compare it (roughly!) with the system clock so that we can avoid accidentally stepping twice
<cjwatson> we don't need subsecond accuracy for that
<Keybuk> by "legacy stat() call" I meant just that
<Keybuk> the legacy stat() syscall
<kees> ah!
<cjwatson> except that POSIX stat() has the same property
<Keybuk> POSIX can be legacy ;)
<cjwatson> hence my "useless word" comment :-)
<kees> *whew*  stat(2) has been time_t for as long as I could find.  okay, syscall.  /me tunes back out
<calc> gah, not this vile unforgiven cover again :\
 * calc wonders if anyone else from the sprint got exposed to it
<Keybuk> yeah, glibc fills in those values for you ;)  the kernel uses struct timespec internally
<Keybuk> (of course, then if you read the kernel source you'll find out that time_t isn't compatible with one returned by time() and you'll want to hide in a small hole somewhere and forget about the whole thing)
<ogra> Keybuk, oh, you are poking at hwclock ... could you fix it for all arm arches while you're at it ? :P
<Keybuk> no, you can do that ;)
<ogra> bah :)
<Keybuk> what's broken about it?
<ogra> times out waiting for the clock ticks ... not sure yet
<Keybuk> in which direction?
<ogra> i honestly havent had time to look closely yet, NCommander has it on his todo though
<ogra> both
<Keybuk> pun intended?
<ogra> not really, no :)
<Keybuk> which /dev/rtcN appear on an ARM? what are their drivers?
<ogra> its a sad issue ... since it blocks the system from powering donw on some SoCs
<ogra> the devices appear fine
<Keybuk> deviceS
<Keybuk> ?
<ogra> well, on the beagle it uses whatever the defconfig defines ... which i assume is the correct one ... let me check
<ogra> grmbl, i dont have the config handy
<Keybuk> do you have the system handy?
<ogra> CONFIG_RTC_DRV_TWL4030=y
<ogra> not set up after the sprint yet
<ogra> so its integrated in the TWL4030 chip
<NCommander> Keybuk, if you want access to my board to debug, your welcome to it; I traced it to the ioctl call which hangs
<Keybuk> I have other things to do
<Keybuk> and know about as much as you - so you're already in a better place to fix it ;)
<jdong> anyone know what kind of "offensive words" pwgen refers to with regard to the --no-vowels option?
<jdong> I've tried reading 5 screenfuls of pwgen with a dirty mind and am wondering whether or not it's a real risk?
<directhex> jdong, wndws
<jdong> lol
<ogra> boobs4u
<Mithrandir> fck, possibly?
<Keybuk> jdong: you're basically asking us to say very offensive things to you, you know that? :p
<jdong> lol
<ogra> hehe
<Mithrandir> Keybuk: he probably likes it
<Keybuk> Mithrandir: it's the opposite way round
<jdong> well I am just wondering if using pwgen passwords in password resets will have a bad effect.
<jdong> but as Mithrandir points out, seems like there's problems either way :)
<Keybuk> for example, it's perfectly possible for pwgen to generate the password "fuckyou"
<ogra> that requires some switches though ...
<jdong> well considering you're randomly generating "pronouncable" words, the chances that eventually you'll hit an offense-sounding one is probably high.
<ogra> no number and no capital letter ...
<Keybuk> no it doesn't?
<Keybuk> well
<Keybuk> FuckY0u then
<ogra> yeah, that would work
<jdong> I guess debian bug 387461...
<ubottu> Debian bug 387461 in pwgen "pwgen lacks option to generate passwords without vowels" [Minor,Closed] http://bugs.debian.org/387461
 * jpds just walked and saw Keybuk's last message and wondered what hit the fan before reading up.
<jdong> I guess the given example is not english?
<Keybuk> jpds: my phrasing was deliberate ;)
<jdong> lol screw it I'm going to use regular pwgen for this
<jdong> I don't see anything that bad after a good 20 minutes (famous last words)
<jdong> the worst I've seen so far is "Mah8ineU" and you have to read that with a really really really questionable mindset to see anything.
 * Keybuk changes his root password
<jdong> LOL
<Keybuk> we used to have a password generator that simply took two words from /usr/share/dict/words and join them together
<Keybuk> that changed when a director got the password boysenberrybuttocks and objected
<jdong> LOL
<cjwatson> jdong: the given example in the bug is a racist term in English
<Keybuk> needless to say, a variation on that became the root password for a while ;)
<cjwatson> the last four letters anyway
<jdong> cjwatson: well I guess I learned something new today.
<jdong> not something useful, but new :)
<Keybuk> cjwatson: I've just noticed who _filed_ that bug ;)
<Keybuk> elmo: do we run pwgen with --no-vowels? :p
<elmo> Keybuk: spads does ;-)
<Keybuk> :D
<ogra> apparently :)
<IntuitiveNipple> cjwatson: I tested and confirmed your patch for Ubiquity/partman_commit silent failure generates an error dialog, and I've added instructions to the other bug (lost partitions) to easily recreate the problem environment in a VM.
<cjwatson> IntuitiveNipple: yay, thanks. did the update-dev change help?
<IntuitiveNipple> cjwatson: umm... define "update-dev" ? I may be missing something here :)
<cjwatson> 17:37 <@cjwatson> IntuitiveNipple: if you fancy doing another test after the partman_commit one, try deleting the "udevadm trigger" line from /bin/update-dev
<cjwatson> 17:38 <IntuitiveNipple> okay, will try that... with VMs its easy and quick.
<IntuitiveNipple> cjwatson, oh... ok *now* I recall. I'm currently in the first run of the install on a brand new 400G drive... the 200G drive with all my 'stuff' on is cold on the desk so I'm making-do right now
<IntuitiveNipple> cjwatson: I'll do that update-dev test once I've got all the VM images copied over.
<cjwatson> great, thanks - and thanks for the reproduction recipe, I'll try to get to that
<IntuitiveNipple> cjwatson: If you do use the recipe, after doing the partition-table create with fdisk, the interesting bit (which I forgot to list) is to show the partition table using fdisk in 'cylinder' mode - makes the cause more obvious
<IntuitiveNipple> iwl3945/NetworkManager - is it known that WPA2 AES+TKIP fails for a (hidden) SSID and then only offers WEP methods for the 2nd attempt?
<LaserJock> are MIRs for packages that Main packagers were using an embedded copy generally easier?
<cjwatson> LaserJock: yes, if it's just a split-out then it doesn't require explicit approval
<LaserJock> it's not a split out exactly
<LaserJock> for some reason moodle was using it's own copy of smarty and yui
<LaserJock> Debian has removed those and added the deps
<LaserJock> so for me to merge I've got to get smarty and yui into Main
<ogra> LaserJock, there is an ancient proposal from kees to split the modules out and use their deps instead ... i think you can refer to that
<LaserJock> ok
<LaserJock> I just wasn't sure how eager people would be to add a couple more php packages to the Main pot
<LaserJock> although if moodle already had a copy of the code one would presume it'd be ok
<ogra> https://wiki.ubuntu.com/EdubuntuContentServer see the bottom
<ogra> effectively these modules were in main already since they enetered with moodle
<LaserJock> right
<ogra> yui is new though
<ogra> (as in: not in the list on the spec)
 * ogra needs to go cooking ... back later
<mathiaz> james_w: hi - I'm using bzr and bzr-builddeb to merge mysql-dfsg-5.1 from experimental
<mathiaz> james_w: is there a way to make bzr bd -S generate a .changes file that includes all the relevant changelog entries?
<slangasek> mathiaz: bzr bd -S --builder 'spell out the full command' :(
<slangasek> mathiaz: known limitation, has to do with the way bzr plugins parse arguments
<mathiaz> slangasek: thanks!
<cjwatson> kees: bug 57091 didn't get automatically closed by your procps upload since it wasn't filed on procps; you might want to close it by hand
<ubottu> Launchpad bug 57091 in ubuntu "proc/sys/net/ipv4/tcp_syncookies=1 should be seriously considered to permit SYN flood defense..." [Undecided,Incomplete] https://launchpad.net/bugs/57091
<kees> cjwatson: erk, d'oh, thanks for the catch.
<LaserJock> ogra: darn, Jaunty's yui wants to pull in javascript-common, which pulls in wwwconfig-common :(
<seb128> soren: could you look at bug #227837 it's on the sponsoring list for some months now
<ubottu> Launchpad bug 227837 in libvirt "[Hardy] overzealous masquerading affects vm to vm traffic" [High,Triaged] https://launchpad.net/bugs/227837
<soren> slangasek: Do we respin DVD's for point releases?
<slangasek> soren: no
<soren> seb128: It's on my list. Somewhere :(
<soren> slangasek: How come?
<kees> superm1: can you take a look at 323327?
<superm1> BUG 323327
<ubottu> Bug 323327 on http://launchpad.net/bugs/323327 is private
<slangasek> soren: it's not justifiable in terms of the relative volume of DVD vs CD use, and DVDs take a lot longer to QA.  This is no different than what was done for dapper point releases.
<superm1> kees, oh fun fun
<superm1> kees, should be an easy enough fix at least
<soren> slangasek: Alright. Thanks.
<kees> superm1: yeah, ran out of time to test it while sprinting last week
<superm1> kees, did you have a diff to test with already then?
<soren> slangasek: Is this written down in a policy somewhere?
<kees> superm1: nope, wanted to reproduce for sure
<superm1> kees, ah.  well i've  got an AMD box at home, i'll try'n double check it with later on then
<kees> superm1: cool, thx
<slangasek> soren: I don't believe so
<soren> slangasek: Alrighty. No worries.
 * soren calls it a day
<lamont> where did dev-mapper go in hardy, I wonder?
<lamont> more to the point, how do I get lvm to just shut up and build the lv?
<IntuitiveNipple> lvm2 ?
<lamont> ya
<IntuitiveNipple> I use lvm2/crypsetup on Hardy... it ain't gone anywhere I know about!
<IntuitiveNipple> dm-mod loaded?
<andersk> I have been waiting for over two months for a MOTU sponsor in bug 303112, which would be a regression in Jaunty.  Is anyone willing to look at this?
<ubottu> Launchpad bug 303112 in openafs "Please upgrade to 1.4.8 for Jaunty kernel 2.6.28 support" [Wishlist,Confirmed] https://launchpad.net/bugs/303112
<lamont> IntuitiveNipple: that'd be the spelling I hadn't thought of.  thanks
<IntuitiveNipple> hehehe
<IntuitiveNipple> It confused me in Jaunty... now it is built-in!
<james_w> mathiaz: you'll have to add "--builder 'debuild -S -vwhatever'" I'm afraid
<mathiaz> james_w: yeah - slangasek gave me the same tip and it works well! :)
#ubuntu-devel 2009-02-10
<btQuark> hello :D
<btQuark> any idea in what ubuntu the a dri2-enabled radeon driver might appear?
<RAOF> btQuark: You'd probably be better off in #ubuntu-x, but the answer is "9.10, most likely"
<btQuark> w00, there is a channel only for the x nice :D
<btQuark> the fglrx is horribly cruel
<btQuark> big fail
<Dante_J> Greetings room.
 * Dante_J waves
<RAOF> Dante_J: Incidentally, have you looked for/filed launchpad bugs on these issues?  That'd be the normal way to raise such things.
<Dante_J> Hi RAOF, I did scan through launchpad, but these Vuls are rather large one's that are cross distro and in some cases cross platform (Firefox). I took for granted that there would be a Ubuntu security team that would keen on top of vulnerabilities with mitigating patches available.
<Dante_J> and when I look at https://lists.ubuntu.com/archives/ubuntu-security-announce/ there are no patches mentioned for All of February, this seemed to be to be highly unusual, as though some kind of infrastructure or process was broken. The patches for Vulns are out there being applied by others.
<Dante_J> And as I mentioned in #ubuntu-motu, Hardy is used by corporates and lab maintainers specifically because it's LTS. When you're primary browser is not patched now for about a week after the upstream patch was made available, it seems unusual to me. http://secunia.com/advisories/33799/
<ScottK> Dante_J: I think an update is coming soon.
<ScottK> LaserJock: I thought Bug #323447 was one you might want to have a look at.
<ubottu> Launchpad bug 323447 in kdeedu "Klatin not available in intrepid" [Undecided,Won't fix] https://launchpad.net/bugs/323447
<Dante_J> ScottK: for Firefox? thank you. what about sudo, and NSS and others?
<ScottK> Yes, for Firefox.  I know our security team keeps track of such things and generally prioritizes them for resolution.  It does take time to integrate the upstream fixes and get them tested.
<Dante_J> Regarding sudo: http://www.auscert.org.au/render.html?it=10462
<dtchen> (accounting for travel to/from recent sprints)
<Amaranth> I wish the sudo one gave more details so you could see how serious the bug actually was
 * Amaranth doesn't feel like looking into diffs
<Dante_J> In #ubuntu-motu I mooted a comparison of https://lists.ubuntu.com/archives/ubuntu-security-announce/ with https://www.redhat.com/archives/fedora-package-announce/ and that there were a number of packages patched by fedora that have not been in Ubuntu. Firefox & sudo prominent among them.
<ScottK> Dante_J: Hardy doesn't have a vulnerable version.
<Dante_J> ScottK: of Firefox or sudo?
<ScottK> Sudo
<ScottK> http://web.nvd.nist.gov/view/vuln/search?execution=e2s2
<Amaranth> and firefox updates take some time
<ScottK>       sudo | 1.6.9p10-1ubuntu3.3 | hardy-updates | source, amd64, i386
<Amaranth> Since we don't just update to the latest version of firefox because they always include non-security changes as well
<ScottK> Amaranth: Actually we do.
<Amaranth> ScottK: When did that change?
 * Amaranth has been gone for a bit
<ScottK> We stay within the major version, but Hardy has 3.0, so it'll get the 3.0.whatever.
<Amaranth> huh
<ScottK> About the time Mozilla corp said you can't ship anything other than what we say you can ship if you want to call it firefox.
<Amaranth> So intrepid?
<Amaranth> Because I know at least pre-hardy that wasn't how it worked and I thought that was only done once in hardy but I know they got a lot more strict about such things recently
<Amaranth> Either way, firefox updates take time, lots of testing needed there
<ScottK> Yes.
<ScottK> Rmadison says 3.06 is in Jaunty already.
<Amaranth> jaunty can break, no one cares that much
<ScottK> So I imagine its coming soonish.
<Amaranth> sure
<Amaranth> Just saying it needs some time
<ScottK> Agreed.
<ScottK> Also we ended up getting stuck on LTS support for Firefox in Dapper.  Asac is lead of a distro based 'upstrea' project for mozilla 1.8/Firefox 1.5.
<ScottK> Add an 'm' in there somewhere.
<Dante_J> Amaranth: ScottK: Thanks for the information, I certainly appreciate it.
<ScottK> Dante_J: In the future though it'd probably be decent of you to spend a couple of minutes searching the web before getting too excited.
<Dante_J> I did, that's why I'm here. Other distros, and not just Fedora have been patching more aggressively than Ubuntu.
<ScottK> The CVE that gave the versions affected for sudo was referenced in the web page you gave me.
<Dante_J> and the dearth of patches in Ubuntu of _anything_ for February seemed unusual to me. That's all. So I'm here to check nothing is broken and all is ok.
<Dante_J> slow is better than broken.
<Dante_J> but when things get too laggy, then the difference narrows.
<kees> Dante_J: the sudo update is coming, as is firefox.  there was a week-long meeting that ate the first week of Feb with regard to security updates.
<ScottK> Reading some of the bugs, I'm not immediately convinced our default configuration in Intrepid would expose this bug.
 * ScottK is certain kees knows though.
<kees> Dante_J: and, as ScottK just mentioned, the sudo issue isn't very high priority, but certainly will be fixed.
<ScottK> That would be another reason it might be delayed.
<Dante_J> kees: Thank you kindly for the info. It's appreciated.
<kees> Dante_J: the full list for main is here: http://people.ubuntu.com/~ubuntu-security/cve/open.html
<kees> each CVE links back to the Ubuntu CVE entry with priorities, notes, patches, bug links, etc.
<Dante_J> Wow, I've been looking for the Ubuntu CVE tracker before! Great link, thanks!
<Dante_J> A brilliant help!
<kees> no problemo.  :)
<Dante_J> I'll pass this on to the AusCERT chaps in case they're not aware. Very nice. :)
<Dante_J> Do you mind if I pass it on kees ?
<kees> Dante_J: sure, doesn't bother me; it's the reality of our tracker.  :)
<Dante_J> It's a useful resource, especially for a security group keeping tabs on who has patched what. eg. http://www.auscert.org.au/render.html?cid=1
 * kees nods.  The raw data might be interesting too (that's linked from the bzr tree at the top of the url I gave)
<Dante_J> and lets face it, Ubuntu is now important infrastructure for a growing number of people, so this information is valuable.
<kees> I don't envy cross-distro CVE fix tracking -- it's hard enough just tracking one distro.  :)
<kees> indeed
<Dante_J> amen brother !
 * Dante_J Dips his hat in respect for the good work done here.
<Dante_J> Cheers people, thanks for your help.
<Dante_J> kees: Thanks to you especially.
<LaserJock> ScottK: sorry, was afk, thanks for taking care of it
<ScottK> LaserJock: No trouble.  I only hit it because I was intrigued by the tad 'needs kde3'
<ScottK> LaserJock: It does seem that someone might want to write up a "If you used to use Klatin ..." wiki page or seomthing.
<ScottK> something even.
<LaserJock> ScottK: I think I'm going to do that in the Release Notes
<ScottK> OK.  Well we'd want it for the Intrepid release notes ....
<ScottK> ;-)
<LaserJock> ScottK: yeah, well ...
<LaserJock> man, I really wish there was a way to extract out separate patches for debian/
<dholbach> good morning
<ion_> ing
<LaserJock> kees: you still up?
<nixternal> go to bed LaserJock !!!
<LaserJock> pfft
<pitti> Good morning
<directhex> is it? looks pretty crappy out
<pitti> yeah, just starts raining
 * lool waves
<pitti> hey lool
<asac> ScottK: fwiw, the main reason for ffox updates being late this time was us being at a sprint when they released. usually we release the day after upstream releases :)
<asac> Amaranth: ^^ ;)
<seb128> superm1: hi, why did you open a g-c-c task on bug #319725?
<ubottu> Launchpad bug 319725 in dell "[Studio XPS 13, Inspiron 531, Studio 16] gnome-settings-daemon crash" [Undecided,Confirmed] https://launchpad.net/bugs/319725
<lool> Keybuk: configure.ac:23: error: Autoconf version 2.63 or higher is required
<lool> Keybuk: We're lagging!!
<lool> :-P
<lool> (pulseaudio)
<seb128> Keybuk: there is a libtool sponsoring request waiting for you for a while btw
<apw> anyone know why we have no alternate installer cd's today?
<apw> cjwatson, who 'owns' the iso build process?
<amitk> I wish there were jigido images for amd64 desktops too
<apw> there are alternate installer jigdo's by the looks fo things for amd64
<apw> amitk, though i have found once you have one cd image, they rsync pretty well
<maxb> I assume there's no desktop jigdos because so much of the desktop cd is the non-jigdo-able livefs
<StevenK> maxb: Right.
<StevenK> apw: The 'ubuntu-cdimage' team owns the CD builds
<apw> and where does one find them?
<maxb> though I'd still find a desktop jigdo convenient for saving the few hundred MB of packages which aren't in the livefs
<StevenK> apw: launchpad.net/~ubuntu-cdimage lists the members
<StevenK> apw: But I'm checking
<cjwatson> sometimes CD builds fail for one reason or another
<apw> heh steve and colin ... is there anything they don't do
<cjwatson> maxb: it's a few tens of MB, not a few hundred
<StevenK> And what cjwatson said
<cjwatson> maxb: if it were a few hundred, it'd be worth it
<apw> StevenK, apparently you are on the hook too :)
<StevenK> apw: Which Steve, there are at least in that team :-P
<StevenK> *at least two
<apw> indeed.  i was thinking on slangasek
<cjwatson> http://people.ubuntu.com/~ubuntu-archive/cd-build-logs/ubuntu/jaunty/daily-20090210.log <- today's build log
<cjwatson> I expect I broke it in some silly way
 * StevenK waits for it to download, fully expecting that cjwatson has fixed the problem before it loads fully
<apw> thats like massive
<cjwatson> did somebody change the kernel ABI again?
<StevenK> Yeah, -7 was ACCEPTed on Friday, I think
<cjwatson> yes - and SOMEBODY NBSed the old packages before we updated d-i
<cjwatson> please don't do that
<slangasek> apw: "is there anything they don't do" - I don't touch the kernel ;)
<cjwatson> I'll update d-i now, which will fix it
<StevenK> cjwatson: Shall I update the platform seed?
<apw> slangasek, cirtainly doesn't include sleeping
<cjwatson> StevenK: let me do it together with d-i
<slangasek> mumble
<StevenK> cjwatson: Sure
<cjwatson> StevenK: were you the NBS-remover in this case?
<slangasek> cjwatson: no, that was me
<StevenK> cjwatson: I've not logged into cocoplum for two days due to flying and such
<cjwatson> ok, please be less trigger-happy :)
<slangasek> cjwatson: or should I make it a policy to upload d-i at the same time, instead?
<StevenK> Why does everyone think NBS is always me? :-)
<slangasek> I nuked them because I knew the new kernel was accepted, and having them there makes the NBS list unreadable
<slangasek> fwiw, we should probably document the kernel NBS specialness in ArchiveAdministration
<cjwatson> slangasek: if you take care of d-i at the same time, certainly - but the old kernel definitely shouldn't be removed until d-i is updated to the new one, otherwise we lose out on daily-build testing time
<cjwatson> StevenK: it usually is ;-)
<slangasek> cjwatson: well, ok
<cjwatson> I'll document that
<apw> cjwatson, how come we have live and not alternate cd's i'd expect both to be affected
<apw> given that ironically the latter is useful without being bootable and the former not
<cjwatson> apw: 'cos the alternate CD requires a package upload to change kernel versions, and the live CD doesn't
<StevenK> apw: Since the alternate is locked to the kernel ABI, the live isn't
<apw> hmmm ... sounds liek the alternate needs to learn something from the live to me
<apw> anyhow, glad its fixed.  i can see why you love it when we bump the abi
<cjwatson> it's a radically different build process, not easily changed to take account of this
<cjwatson> fact is that the installer ships objects which are on archive.ubuntu.com, and any such object requires an upload to change
<cjwatson> we used to have automatic daily builds of the installer, although even those didn't take account of ABI changes so when that broke with the switch to Soyuz we stopped bothering
<cjwatson> apw: thanks for the note
<apw> is there something the kernel team should be doing there?  as a step after linux-meta or something?
<cjwatson> apw: you guys already mail ubuntu-installer - I just hadn't caught up on mail
<apw> good enough, as long as we are not failing process
<cjwatson> I might do a quick CD rebuild later - I was waiting for today's CDs myself to test some things
<cjwatson> slangasek: (in general I have no objection to the set of people who upload d-i all the time not being just me ;-) )
<slangasek> right :)
 * directhex uploads d-i
<cjwatson> ... for a good reason
<Keybuk> lool: we could sync that from experimental
<lool> Keybuk: I'm happy if you think that's ok
<lool> I certainly am not confident to ask that myself
<Keybuk> lool: let me look at the changelog, if I'm happy, I'll do it
<ogra> cjwatson, is there a reciepe online to properly do a testbuild of d-i locally ? dpkg-buildpackage -b seems to not work for me
<ogra> (i just want to have the netboot binary blob for nslu2 in the end)
<cjwatson> ogra: how does it fail?
<ogra> it cant find anna
<cjwatson> do you use a local mirror?
<ogra> hmm, and it apparently uses my local sources.list
<ogra> heh, yeah
<ogra> how did you guess :)
 * ogra switches that to ports.u.c
<cjwatson> either fix your local mirror to include main/debian-installer, or create a file build/sources.list.udeb.local in the unpacked d-i tree and put 'deb http://archive.ubuntu.com/ubuntu jaunty main/debian-installer' in it
<cjwatson> oh, or ports
<cjwatson> or perhaps better, copy build/sources.list.udeb to build/sources.list.udeb.local and edit to taste
<ogra> i'm fine switching over ... i just reinstall things to often here to not use a local mirror in general
<cjwatson> likewise, but my local mirror includes d-i :)
<cjwatson> (funny that)
<ogra> heh
<Keybuk> lool: looks ok, will upload when make check passes
<ogra> pfft ... now it fails with bootchart-udeb ...
<ogra> but seems to pull properly from http://ports.ubuntu.com jaunty/main/debian-installer
<Keybuk> we dropped that
<cjwatson> ogra: pull newer source; I removed bootchart-udeb in the most recent upload
<ogra> ah
<StevenK> I seem to recall bootchart-udeb in NBS
 * cjwatson looks at /usr/lib/pkgconfig/gdk* in confusion
<cjwatson> /usr/lib/pkgconfig/gdk-directfb-2.0.pc includes cairo-xlib in Requires; /usr/lib/pkgconfig/gdk-x11-2.0.pc doesn't
<ogra> OH ! .... i just noticed for the first time that the jaunty-changes mail contains a direct link to the source packages ... how convenient ...
<cjwatson> or d-i is in bzr
<cjwatson> if you're going to hack on it anyway you might as well just have a checkout
<ogra> indeed
<ogra> currently i'm blindly poking around anyway testing out some theories
<ogra> i'll surely do use bzr for a fix in the end
<ogra> ogra@beagle:~$ ls /bin/
<ogra> -bash: /bin/ls: No such file or directory
<ogra> hmm, i wonder if i should get worried
<StevenK> ogra: echo /bin/*
<ogra> all there ...
<ogra> looks like libc broke during a dist-upgarde
<StevenK> Okay, then something /bin/ls links against is missing/broken
<ogra> yeah
<ogra> it properly unpacked libc6 2.9-0ubuntu7
<ogra> in the next line i get: dpkg (Unterprozess): Konnte rm nicht zum AufrÃ¤umen ausfÃ¼hren: No such file or directory
<ogra> so it cant exec rm directly after unpacking ...
<StevenK> Does /lib/ld-linux-*.so exist?
<ogra> ogra@beagle:~$ echo /lib/ld-linux-*
<ogra> /lib/ld-linux-*
<ogra> hmm
<StevenK> ogra: That means no. :-)
<ogra> i dont really care about the system ... takes me 5 min to uncompress the rootfs tarball on the disk ...
<StevenK> ogra: Sure, but I'm curious how it got to that state ...
<ogra> but i suspect that shouldnt happen during a dist-upgrade :)
<StevenK> ogra: It's recoverable, if you don't mind using echo or a statically compiled cat ...
<ogra> http://paste.ubuntu.com/116422/
<ogra> sorry, its german ...
<ogra> looks like ldconfig is barking at me earlier
<ogra> if anybody is interested in gathering more info from that system, i'll keep it around (not needed anyway atm)
<cjwatson> seb128: there's something wrong with our gtk+ patches, that isn't broken in Debian unstable/experimental. /usr/lib/pkgconfig/gdk-directfb-2.0.pc includes cairo-xlib in Requires; /usr/lib/pkgconfig/gdk-x11-2.0.pc doesn't
<cjwatson> seb128: it looks like this is a bug in debian/patches/003_gdk.pc_privates.patch, which adds cairo-xlib in the non-explicit-deps case (only used by the directfb build at the moment)
<cjwatson> seb128: do you know anything about this?
<seb128> cjwatson: upstream did add this requirement recently, let me look at how I updated the patch
<cjwatson> seb128: I think I might have an idea
<seb128> cjwatson: what else would you expect?
 * cjwatson waits for dpkg-source to get a move on
<cjwatson> seb128: I'm thinking of http://paste.ubuntu.com/116434/
<dholbach> kees: tjaalton just told me that you made my laptop give me only black screens if it boots with "splash" - no idea what he exactly means by that... something with initramfs/usplash?
<cjwatson> which would result in cairo-xlib ending up in Requires.private of the x11 backend, and not at all in Requires/Requires.private of the directfb backend, which I think is correct?
<tjaalton> kees: you updated usplash
<Keybuk> doko: so, about the java compiler failure on the buildds
<Keybuk> doko: https://launchpad.net/ubuntu/+source/bootchart/0.9-0ubuntu8keybuk3/+build/858530/+files/buildlog_ubuntu-jaunty-i386.bootchart_0.9-0ubuntu8keybuk3_FAILEDTOBUILD.txt.gz
<tjaalton> dholbach: the new kernel initramfs got the new usplash first, so the old kernel worked until you regenerated the image
<dholbach> tjaalton: ah ok
<seb128> cjwatson: yes, that looks good to me
<cjwatson> seb128: ok, I'll do a test build to make sure - shall I upload if it DTRT?
<seb128> cjwatson: yes
<seb128> thanks for spotting the error!
<cjwatson> no problem, the d-i buildd spotted it really ;-)
<doko> Keybuk: buildd only, or local build?
<Keybuk> doko: buildd only
<Keybuk> builds just fine locally in a chroot
<Keybuk> Unable to locate tools.jar. Expected to find it in /usr/lib/jvm/java-6-openjdk/lib/tools.jar
<Keybuk> and
<dholbach> kees: mjg59 says usplash should do the same thing as "vbetool vgamode 3" *shrug*
<Keybuk> /build/buildd/bootchart-0.9/build.xml:41: Unable to find a javac compiler;
<Keybuk> com.sun.tools.javac.Main is not on the classpath.
<Keybuk> seem to be the key bits
<Keybuk> yet it build-depends on java-gcj-compat-dev | java-compiler
<cjwatson> isn't that the wrong build-dep now?
<cjwatson> https://lists.ubuntu.com/archives/ubuntu-devel-announce/2008-July/000460.html
<cjwatson> should use default-jdk-buildddep
<cjwatson> default-jdk-builddep
<Keybuk> why jdk?
<Keybuk> oh, I see
<doko> Keybuk: I'll upload a new version using default-jdk/default-jre, and setting JAVA_HOME
<Keybuk> ok, thanks
<ogra> wow the /usr/share/doc/debian-installer/armbooting.txt really targets ancient stuff :)
<lool> ogra: You might be more interested in doc/devel/hardware/arm/nslu2/README
<doko> Keybuk: bootchart built
<Keybuk> \o/
<asac> james_w: hmm. debcommit doesnt do the --fixes lp:xxxx magic for me anymore
<pitti> meh, latest X.org updates break X on GM945 (black screen, nothing in log)
<pitti> bryce, tjaalton: ^ did you hear similar reports already?
<beuno> pitti, same here
<beuno> since yesterday or the day before
<pitti> vesa works for now
<beuno> pitti, BUT, if you login with the older kernel (2.6.24-21), it works
<pitti> interesting
<pitti> I didn't try 2.6.27-6 yet
<beuno> I tried it, and it looks less broken, but still doesn't work
<beuno> I've also been having the wierdest problem with the wireless. It intermintently stops working (transmiting) for 4-5 seconds, and then works again
<beuno> it does the same thing on different APs/internet connections
<tjaalton> pitti: usplash is broken
<pitti> tjaalton: happens without usplash, too
<ogra> for me it worked after dropping the flash
<ogra> *splash
<tjaalton> dunno then
 * ogra does definately to much ARM work
<tjaalton> siretart: you are probably aware of the annoyance in emacs that you cannot turn off the splash screen in site-start.el.. any way to allow that in the ubuntu package?
<Mithrandir> tjaalton: you can't?  That's silly.
<tjaalton> Mithrandir: it's infuriating..
<tjaalton> http://www.gnu.org/software/emacs/manual/html_node/emacs/Initial-Options.html
<Mithrandir> I have (setq inhibit-splash-screen t) in my personal .emacs, though
<tjaalton> that works
<tjaalton> but there are thousands of users here..
<bryce> pitti: yes I'm getting the same thing, on -intel
<Mithrandir> make /usr/bin/emacs a shell script that calls the real binary with `--no-splash'
<bryce> pitti: is there a bug id already?
<pitti> bryce: I didn't file one yet; there might be
<bryce> I looked yesterday but didn't see one
<tjaalton> bryce: there are a couple of issues.. one is that usplash is broken and then the one that pitti is seeing
<pitti> tjaalton: in what way? usplash WFM
<bryce> the problem I'm seeing is definitely not usplash; also it goes away if vesa is specified
<tjaalton> pitti: yes, but it fails to give back the display
<tjaalton> Mithrandir: that's a possibility, but a bit ugly :)
<bryce> I suspect it must be an update between thursday and yesterday
<tjaalton> bryce: have you tried booting without splash?
<bryce> tjaalton: not yet
 * bryce tries
<bryce> tjaalton: huh, came up fine
<bryce> pitti: have you tried booting without usplash?
<pitti> bryce: yes
<tjaalton> bryce: like I said :)
<pitti> bryce: same problem
<bryce> tjaalton: is there a bug id on the usplash bug?
<tjaalton> bryce: not sure
<bryce> tjaalton: who all is seeing the usplash issue?
<kirkland> pitti: do you happen to know if there's a wake-on-lan package in main?  etherwake and wakeonlan both are in universe
<bryce> https://bugs.edge.launchpad.net/ubuntu/+source/usplash/+bug/327230
<ubottu> Ubuntu bug 327230 in usplash "Lost all graphics on "Jaunty" after last update." [Undecided,Confirmed]
<tjaalton> bryce: dholbach did
<bryce> let's see what happens booting an earlier kernel
<dholbach> bryce: it will work until you update the initramfs for that kernel
<tjaalton> bryce: usplash is included in the initramfs, so an earlier kernel with an earlier usplash works
<bryce> ah
 * surfaz is away: Estoy comiendo, escribir mi nombre para que el Xchat me avise
<dholbach> surfaz: do you think you could turn off auto-away in your irc client please?
<bryce> dholbach, tjaalton: you're right; earlier kernel boots fine
<bryce> dupes:  #327610 #327505 #327498 #327444 #327286
<tjaalton> yay for having no assigned maintainer ;)
<bryce> :-/
<bryce> is there a usplash change we can revert?
<Keybuk> lool: new autoconf in
<lool> Keybuk: thanksely
<Keybuk> bryce: I think usplash last changed in 1842
<bryce> Keybuk: also on Feb 4th
<bryce> kees probably isn't awake yet though
<Keybuk> hmm, interesting
<bryce>   * libusplash.{c,h}, usplash.c:
<bryce>     - Move pulsate and animation pipes into libusplash to unblock animations
<bryce>       while waiting for stdin (LP: #326709).
<bryce>     - Process animations between commands to avoid falling behind when
<bryce>       running in verbose mode.
<bryce>     - Drop unneeded signal-blocking code.
<Keybuk> it could be unrelated to the patch, but a rebuild that caused it
 * bryce nods
<bryce> however, there was also a change Jan 21st
<bryce> so it would have been rebuilt at that point, right?
<bryce> I still have the previous deb, let me test that
<bryce> interesting that for many, this is indistinguishable from an X blank screen
<bryce> yep, earlier .deb boots fine
<Fenario> freeflying, ping
<cjwatson> seb128: I happened to notice that your Maintainer address in gtk+2.0 is @ubuntu.org rather than @ubuntu.com
<pitti> slangasek: oh, just stumbled over https://wiki.ubuntu.com/LaptopTestingTeam/HotkeyResearch ..
<pitti> kirkland: WOL> not that I know of
<pitti> kirkland: if we need one, there's always the MIR route :)
<seb128> cjwatson: ups, I changed the debian to ubuntu too quickly ;-)
<lamont> I need a tool to dump a palm-pilot addressbook etc that doesn't blow its brains out when it hits the corruption that is present in my DB...
<lool> seb128: Better than debian.com   :-P
<seb128> ;-)
<seb128> lool: btw since you are there, how busy are you this week? ;-)
<lool> seb128: What's the highest level of business you know?
<seb128> lool: would be nice to get pygobject and pygtk updated to their current version, since we are mostly in sync with debian experimental and like working on those ;-)
<lool> seb128: Ok; I'm noting that down
<seb128> lool: thanks ;-)
<lool> seb128: I have insurance, trip report, activity report, and 4 interviews to do this week
<lool> And I'm on IRC!
<seb128> lool: theorically those updates should not be too hard
 * lool /quits
<lool> Ok
<seb128> I say theorically because you had issues on previous rounds ;-)
<seb128> thanks!
<lool> Yeah, I wasn't really lucky with pygobject/pygtk so far
<lool> seb128: I had a conversation at FOSDEM that these will likely be superseded
<seb128> lool: what, pyg* using gobject introspection?
<lool> Yes
<seb128> lool: that will require code changes in applications though I guess, no?
<seb128> ie the api will be different
<lool> I don't know
<pitti> tseliot: bug 287470 is still open for -173 in jaunty; should that be closed, or does it really need an upload?
<ubottu> Launchpad bug 287470 in nvidia-graphics-drivers-177 "package libgl1-mesa-glx 7.2-1ubuntu1 failed to install/upgrade: poging tot overschrijven van `/usr/lib/libGL.so.1', wat ook in pakket nvidia-glx-177 zit" [High,Fix released] https://launchpad.net/bugs/287470
<kirkland> pitti: cool, i'll put one together, thanks ;-)
<racarr> lool, seb128: It's not really clear. pybank isn't really actively developed. The API right now is different though
<racarr> But very similar, and probably could be the same
<lool> I guess we could replace pygtk/pygobject with a thin impedance matching layer and ask people to move to the new API
<lool> Anyway, future stuff I'm not working on and wont work on :)
<EagleScreen> I have a dude. I am going to do a change in package qtparted, it uses dpatch patches in debian/patches, so I fisrtly will make a dpatch patch with my changes, and later a debdiff with the difference between old and new package, my question is if the changes in the changelog file must go in the dpatch patch, or only in the debdiff patch
<bardyr> nden
<tseliot> pitti: the bug report can be marked as "fix released" now
<lool> EagleScreen: In the debdiff
<pitti> tseliot: great, thanks
<seb128> tseliot: hey
<lool> EagleScreen: The dpatch is to hold upstream changes; anything below debian/ shouldn't be in a dpatch and will appear in the debdiff
<tseliot> seb128: hey
<EagleScreen> thanks
<seb128> tseliot: how is the gnome-desktop update going? need any help on that one?
<tseliot> seb128: I'm still fighting with a few patches, I'm trying to solve the problems with the display capplet and I will let you know about the rest
<seb128> ok
<seb128> tseliot: what problems with the capplet?
<tseliot> seb128: the aspect dropdown patch doesn't apply any longer
<seb128> tseliot: can you try to get the update done first and then look at the other issues (if that's xrandr 1.2 drivers, etc)? so that would unblock the soname transition and the gnome-settings-daemon and gnome-control-center updates
<seb128> tseliot: ok, let me know when the update is ready then, I will do some bug triage until then ;-)
<tseliot> seb128: the g-c-c has the highest priority and I can already give you my patches for gnome-desktop but I would really like to get g-c-c to build first
<tseliot> also patches for the network capplet fail to apply, etc.
<seb128> tseliot: I'm not that much in a hurry, ping me when you will have g-c-c ready and tested
<tseliot> seb128: ok
<pitti> tkamppeter: interested in joining the desktop team meeting in #u-desktop?
<pitti> tkamppeter: (... at 16:30 UTC)
<EagleScreen> then ANY change under debian/ in debdiff?
<EagleScreen> what about updating debian/patches/00list? also in debdiff?
<cjwatson> updating debian/patches/00list in a dpatch would be ... exceptionally twisted
<cjwatson> (and generally wouldn't work)
<EagleScreen> thanks Colin
<EagleScreen> cjwatson dod you remember
<EagleScreen> Bug #133072:
<ubottu> Launchpad bug 133072 in console-setup "tty console doen't show characters with accent" [Undecided,Confirmed] https://launchpad.net/bugs/133072
<EagleScreen> This report is public
<cjwatson> EagleScreen: yes - have you tried the update to console-setup that's available in intrepid-updates now?
<cjwatson> as of December or so
<EagleScreen> surely yes
<EagleScreen> console-setup 1.25ubuntu4 (intrepid-updates)
<EagleScreen> it fixes the problem, but it is necessary to run it each time I start Ubuntu
<EagleScreen> I mean running sudo setupcon each time
<EagleScreen> may be some script during boot shuld run it
<superm1> seb128, that's the app that is crashing in the current development version, gnome-display-properties in jaunty which is part of gnome-control-center
<seb128> superm1: ok, I figured that after pinged, that was confusing to have one gnome-settings-daemon and one gnome-control-center task there
<cjwatson> EagleScreen: setupcon's already run at boot, actually
<cjwatson> EagleScreen: so yet another thing is going wrong. sigh
<cjwatson> EagleScreen: I'm not sure what you mean by "it fixes the problem", then, since you go on to say that it doesn't fix the problem
<cjwatson> EagleScreen: and yet we have already confirmed separately that it does fix a very similar problem for other users
<superm1> seb128, yeah those other tasks might want to be adjusted as it was found in intrepid initially
<EagleScreen> when I boot Kubuntu 8.10, tty console cannot change Ã±, vocals with accent and other charactes such as â¬
<lool> doko:   * Use dpkg-architecture -f instead of -a for cross builds.
<cjwatson> upgrading to the console-setup in intrepid-updates, and if necessary running update-initramfs -u, should arrange for the console to be set up before usplash starts
<cjwatson> EagleScreen: are you using any other unusual customisations, such as splashy?
<lool> doko: Are you sure you want to drop -a?  How is the architecture going to be set?
<EagleScreen> i am not using splashy
<EagleScreen> after I run sudo setupcon tty result fixed, all that characters can be typed and showed
<cjwatson> in any case, that bug is only barely comprehensible since several people have added essentially unrelated issues to it
<lool> doko: The problem was that in the old code "DEB_HOST_GNU_TYPE=i486-linux-gnu dpkg-architecture -aarmel -qDEB_HOST_GNU_TYPE" would return i486-linux-gnu
<cjwatson> (lesson for the future: don't do that)
<lool> doko: If you add -f and ignore the env, "DEB_HOST_GNU_TYPE=i486-linux-gnu dpkg-architecture -aarmel -qDEB_HOST_GNU_TYPE -f" returns arm-linux-gnueabi
<lool> (which is the fix I proposed)
<cjwatson> EagleScreen: I could do with a copy of your initramfs to investigate
<doko> lool: please feel free to fix it. I think I misunderstood you.
<lool> If you remove -f and -a, then it becomes "DEB_HOST_GNU_TYPE=i486-linux-gnu dpkg-architecture -qDEB_HOST_GNU_TYPE -f" => i486-linux-gnu, where -f is useless and you're not cross-architecturing
<EagleScreen> yes I will give you as you want
<lool> doko: Sure will do
<freeflying> Fenario: pong
 * lool sighs at pushing binutils
<EagleScreen> cjwatson I have discovered one new thing. I log into tty console, I run sudo setupcon and characters are fixed, but if I log out and I log in again, characters are broken again.
<lool> doko: Do you keep binutils in a VCS?  thanks for the other fixes BTW!
<lool> doko: pushing
<doko> lool: no. I should do that ... started a repo locally, but it's out of date
<lool> Ok, just wanted to make sure the Debian tree will get the fix as well
<pitti> thekorn: seems bug.subscribers.add() now started giving "Wrong XPath-Expr while parsing Subscribers.__xml.edge.stable" on all bugs?
<pitti> thekorn: do you want a bug report for that, or already know it?
<cjwatson> pitti: I filed a bug
<cjwatson> bug 327620
<ubottu> Launchpad bug 327620 in python-launchpad-bugs "fails to parse subscribers on edge" [Undecided,New] https://launchpad.net/bugs/327620
<pitti> ah, thanks
<thekorn> pitti, cjwatson, oh, will try to fix it today, thanks for reporting this
<cjwatson> I also started writing a launchpadlib version of the same program
 * pitti was just going to propose that, too
<thekorn> yes, using launchpadlib is a good idea, because the more javascript snippets will be added to launchpad the more likely py-lp-bugs will fail to parse the pages
<cjwatson> indeed
<kees> bryce, Keybuk: hrm, I can't reproduce the usplash glitch. is it intel only?
<Keybuk> kees: I've not reproduced it either
<kees> bryce: if you revert my usplash change and rebuild usplash, does it still hang?
<tseliot> seb128: some patches: http://albertomilone.com/ubuntu/gnome/jaunty/sebfiles.txt
 * kees will be back after breakfast and exercise...
<tseliot> seb128: unfortunately I couldn't make g-c-c build because (as you will see) other patches failed
<seb128> tseliot: did you work on the gnome-desktop update too (ie packaging changes for the soname update)? or just on the patches update?
<seb128> tseliot: you can probably comment the patches which don't apply if you want to test locally
<tseliot> seb128: you will find the patches for gnome-desktop there. It builds
<seb128> tseliot: I will get mvo to update his proxy changes if those don't apply to the new version
<tseliot> seb128: ok
<seb128> tseliot: ok, are you interested to do the packaging changes for the gnome-desktop update too or should I pick you patch update and do that now? I'm fine doing it, I just want to get that uploaded to unblock other things ;-)
<tseliot> seb128: sure, I can do it myself and ask you to merge from my branch
<bryce> kees: if I revert your change and rebuild usplash, it works fine
<seb128> tseliot: you want to do it or prefer to work on other thing? I'm fine either way, the annoying part was the patch update ;-)
<bryce> kees, good morning
<tseliot> seb128: I doubt I'll do anything else today, therefore it's not a problem at all
<seb128> tseliot: ok, so feel free to do it and ping me when it's ready I will sponsor the upload
<tseliot> seb128: ok
<bryce> kees: I've also tried rebuilding debs of your .28 locally and installed and booted them
<bryce> kees: which then reproduces the black screen issue on boot.
<bryce> brb
<LaserJock> mvo: edubuntu ping
<mvo> LaserJock: oh, right
<LaserJock> kees: what does the "needs triage" bit on the CVE tracker mean exactly?
<apw> superm1, this bug #319725 ... got a reference to the bzr branch anywhere
<ubottu> Launchpad bug 319725 in dell "[Studio XPS 13, Inspiron 531, Studio 16] gnome-settings-daemon crash" [Undecided,Confirmed] https://launchpad.net/bugs/319725
<verwilst> info database35
<verwilst> oops :D
<EagleScreen> how can I apply a debdiff patch?
<LaserJock> patch -p1 < <debdiff> I think works
<LaserJock> it might be -p0 though, I can never remember
<EagleScreen> i am trying that
<LaserJock> EagleScreen: so what's it having an issue with then?
<EagleScreen> yes, just patch is not being applied
<LaserJock> EagleScreen: do you have the right version of the source package you're trying to apply it to
<EagleScreen> I think yes
<LaserJock> EagleScreen: what kind of errors is it giving? is it unable to find the files or is it missing hunks?
<EagleScreen> any output error
<EagleScreen> i am in the decompressed folder of the package
<LaserJock> oh
<LaserJock> do it one level up
<EagleScreen> i was running this: patch -p1 < ../qtparted_0.4.5-4ubuntu2_to_0.4.5-4ubuntu2.1.debdiff
<LaserJock> so cd ..
<EagleScreen> is it always necessary doing it one level up? i also tried -p0
<LaserJock> yes
<LaserJock> well, I guess it wouldn't *have* to be one dir up
<LaserJock> but you might need -p2 or further
<EagleScreen> now i am one level up
<EagleScreen> i have run patch -p1 < qtparted_0.4.5-4ubuntu2_to_0.4.5-4ubuntu2.1.debdiff
<EagleScreen> is it ok?
<LaserJock> sure
<LaserJock> just play around with the -p until it works ;-)
<EagleScreen> but i am reading the sources and they dont seem to be changed
<EagleScreen> i will have to play..
<LaserJock> you will know when it worked
<EagleScreen> i have tested from p0 to p4
<LaserJock> and it still gives you errors?
<EagleScreen> it doesn't give me any error, just does not change nothing in the sources
<LaserJock> if it doesn't give you any errors then it should have applied
<LaserJock> EagleScreen: so perhaps the changes aren't where you think they are?
<LaserJock> when you apply the patch it should tell you which files it modified
<EagleScreen> it tell me nothing
<LaserJock> EagleScreen: you're sure you're running it on 0.4.5-4ubuntu2 and not 0.4.5-4ubuntu2.1?
<EagleScreen> yes, sure, i tell you that the sources are not changed
<EagleScreen> can I make a diff patch against a .dsc file in place of a debdiff patch?
<EagleScreen> the decompressed folder is in ~/devel/qtparted-0.4.5
<EagleScreen> and the patch is in ~/devel/qtparted_0.4.5-4ubuntu2_to_0.4.5-4ubuntu2.1.debdiff
<LaserJock> you can make a debdiff by doing: debdiff <first .dsc file> <second .dsc file
<EagleScreen> yes that is the way I made the debdiff
<LaserJock> ok, but running patch doesn't give you anything my guess is that you got the wrong version
<EagleScreen> lets see..
<LaserJock> or perhaps you didn't actually make any changes in the ubuntu2.1 source package
<EagleScreen> qtparted has seven patches yet, in debian/patches
<EagleScreen> they are in dpatch format
<EagleScreen> i have added one more, using dpatch-edit-patch
<EagleScreen> and changing with ti the .dektop file
<LaserJock> ok, and if you look at the debdiff that shows up?
<EagleScreen> yes it is, wait a moment..
<EagleScreen> oh no! the patch file is empty!
<EagleScreen> I dont undestand why
<EagleScreen> a debdiff file is just a plain text file isn't it?
<LaserJock> yep
<EagleScreen> ok now I have the right patch
<EagleScreen> now it is well applied with: $ patch -p1 < ../qtparted_0.4.5-4ubuntu2_to_0.4.5-4ubuntu2.1.debdiff
<LaserJock> EagleScreen: great
<EagleScreen> thanks
<kees> bryce: well, crap.  I did try to split up my changes into logical commits to bzr.  I'll try to reproduce on my intel hw, and if I still don't see it, I'll build some versions of usplash for you with progressively more commits in it.
<kees> LaserJock: it means that the given release of a package hasn't been checked for the vulnerability.
<LaserJock> kees: and who generally checks? can anybody do that?
<kees> LaserJock: absolutely anyone can check.  the whole repository is in public bzr.  There's even an extensive README on how it all works.  https://launchpad.net/ubuntu-cve-tracker
<LaserJock> kees: awesome, thanks. I was looking at moodle :/
<kees> LaserJock: yeah, moodle is a mess.
<LaserJock> kees: I think CVE-2008-5619 should be resolved in jaunty when I merge
 * kees nods
<LaserJock> kees: but I'll look at the previous releases to see if it's vulnerable
<kees> it's the back-porting and testing that's going to be a pain.
 * kees nods
<LaserJock> kees: luckily Debian has fixed a *ton* of moodle bugs and security issues
<LaserJock> kees: I filed a MIR on smarty as Debian has removed the moodle copy and replaced it with a dep
<LaserJock> they did the same for yui but I don't see it going into main for Jaunty as it requires javascript-common and wwwconfig-common
<LaserJock> for Jaunty+1 maybe we can work with the new Debian maintainers to get rid of more of the embedded libs
<bryce> kees: mdz mentioned you also have seen the crash for bug 324368 -- do you have steps to reproduce it?  (just checking for the null ptr doesn't seem to be a sufficient fix)
<ubottu> Launchpad bug 324368 in xorg-server "Xorg crashed with SIGSEGV in XisbRead()" [Unknown,Confirmed] https://launchpad.net/bugs/324368
<kees> LaserJock: excellent
<kees> bryce: I haven't been able to reproduce it yet.  it only happened once.
<kees> bryce: I suspect it was related to me yanking out a projector before/during/after a resume.
<bryce> kees: ah
<kees> bryce: but, I'm not really sure what the sequence was.  :(
<superm1> apw, it's on the bug
<superm1> apw, https://code.edge.launchpad.net/~superm1/gnome-control-center/vendor-fallback/+merge/3508
<apw> superm1, thanks. being dense clearly
<superm1> apw, no, i agree that it's quite easy to overlook the bzr link on bugs.  i've done it myself too :)
<apw> so basically its, "yeah ok, but i have some conflicting changes already in the pipe, lets redo it on top"
<apw> so i don't need to keep this laptop with the bug, it can come back to you
<superm1> apw, if you see anything else on it that you'd like to address in using it you can hang onto it for a little longer, otherwise sure send it back
<kees> bryce: hrm, no luck reproducing usplash weirdness
<hwilde> anybody have a good tool to view cpu load per thread for multithreaded apps ?
<ogra> cjwatson, still around ?
<cjwatson> ogra: yes
<ogra> cjwatson, i'm trying to find out why our nslug image doesnt work ...
 * ogra does a c&p from -arm
<ogra> <ogra> til/pad $(TEMP)/initrd.gz.nslu2 6291440 # size of partition - 16 for header .... thats debian ...
<ogra> <ogra> util/pad $(TEMP)/initrd.gz.nslu2 5636080 # size of partition - 21 for header .... thats ours
<ogra> cjwatson, where does that 21 come from ?
<ogra> the partition changes seem all ok, but i dont understand why our header is 21 bytes instead of 16
<cjwatson> ogra: bzr up
<ogra> (thats from build/config/armel/ixp4xx/netboot.cfg btw)
<mnabil> guys , i'm creating custom ubuntu live cd , how can i add a script to be run in the startup ?
<cjwatson> ogra: lool pointed that out earlier on #ubuntu-installer; I had understood the 16 to be blocks rather than bytes and so miscorrected it. It's fixed in bzr
<cjwatson> mnabil: where in the startup sequence?
<ion_> Aah, S:Startup-Sequence
<ogra> cjwatson, ah, k, well, i'm not sure yet its the fix we need, i just wanted to know where the 21 comes from :)
<ogra> i think the headers are hadcoded in slugimage so the size shouldnt vary
 * ogra goes and rolls another testimage
<cjwatson> ogra: I set it back to 16, it was just my mistake
<ogra> ah
<ogra> well, lets see :)
<ogra> that whole setup is weird and scary
<ogra> as it comes from debian
 * ogra wishes LP would actually work :/
<mnabil> cjwatson, sorry for late, i mean startup of the shell
<mnabil> cjwatson, like clonezilla if you know it
<cjwatson> "startup of the shell"?
<cjwatson> you mean a rescue shell?
<cjwatson> you need to be very very clear on exactly where you want to put it in the startup sequence
 * ogra curses ... damned i just deleted my kernel image and inbetween a new d-i built
<mnabil> cjwatson, the live cd is without autologin , i need it to login to for example 'ubuntu' and the run the script
<cjwatson> mnabil: so you want to put it into the GNOME session?
<cjwatson> mnabil: the live CD that *we* ship does autologin; if yours doesn't, then you must have broken something
<mnabil> cjwatson, i dun have any GUI installed in the live cd , it gives only a console login
<cjwatson> mnabil: we set up autologin on the console too
<mnabil> cjwatson, cool, it has already autologin , but i  just wanna script after autologin
<mnabil> *wanna run
<cjwatson> "want to"
<cjwatson> mnabil: perhaps you should create an init script with a symlink to it somewhere in /etc/rc2.d/ that runs whatever you want to run
<mnabil> cjwatson, k, "wanna run " :)
<cjwatson> mnabil: you don't have to log in for that; init scripts run as root, and if you want to you can drop privileges
<allquixotic> Anyone know if UXA will be enabled by default for Intel cards in Jaunty GM? The 2D performance difference is night and day between EXA and UXA with the Xorg/Mesa/DRI stack used in Jaunty.
<cjwatson> allquixotic: Bryce has been investigating it, but at the moment it's very unreliable on all but a few cards
<mnabil> cjwatson, thanks alot :)
<cjwatson> allquixotic: https://wiki.ubuntu.com/X/UxaTesting
<allquixotic> cjwatson: Cool. I haven't had a single graphics system related crash and I've been running it for days on a GM965. If it can't be stabilized on all Intel chips, I would want to advocate either a whitelist, a blacklist, or at _least_ a Release Note documenting how to enable it for people who've got the right card(s).
<bryce> allquixotic: at this stage it's simply too unstable.  I've emailed keithp and jesse for advice on either improving performance on EXA or improving stability on UXA, but no reply so far.
<bryce> allquixotic: look at the url cjwatson posted; there isn't a strong enough correlation to stability and chipset to warrant black/white listing.
<bryce> allquixotic: I'm not comfortable listing it in release notes at the current level of (in)stability
<bryce> allquixotic: if you would like to help bring UXA up to a point where we can consider it more strongly, I would love having your help in upstreaming the UXA bugs filed against xserver-xorg-video-intel
<allquixotic> bryce: Interesting reports in the wiki. The only complaints on any 965 (Crestline) based hardware are that it crashes after resume (and I can't reproduce that), and that it has font issues
<bryce> that is currently the gating issue
<allquixotic> but the font issues is something like: you minimize Firefox, and for a split-second you see partially rendered window contents as it's coming up
<allquixotic> that's minor, I wouldn't even call that a defect, really
<bryce> allquixotic: I've seen freezes on 965 as well
<allquixotic> Have you? Under what situations?
<allquixotic> I've been running it fully loaded on a ThinkPad X61T, uptime 3 days, suspend/resume every few hours, OpenGL 2.1 games, tons of Firefox tabs,...
<allquixotic> only crash I had (3 days ago) was Cisco VPN related, not graphics
<bryce> allquixotic: also there are only *4* test cases listed there for 965; hardly what I'd call a definitive sampling.  I'd like to see more 965 cases first.
<allquixotic> bryce: I will add an entry to the wiki with my findings (very very positive performance-wise, and no stability issues whatsoever) and I might try to reproduce others' problems for the sake of either resolving the bugs if they're valid, or figuring out a different root cause (user could be mistaken about what's causing their woes)
<bryce> allquixotic: of the 4 cases, 1 reports freezing, 2 report crashes.  I think you're crazy concluding that there are hardly any stability problems there!
<bryce> ;-)
<allquixotic> I'm just worried that user testing and reporting problems is a bit slippery because some of their claims of graphics-related issues could be related to other subsystems. My intent would be to get more info from the reporters and try to determine _whether_ their concerns are indeed graphics related.
<cjwatson> allquixotic: well, on this 965 system (exact same PCI ID as others that claim to work to a greater or lesser extent), I get a startup sound but a black screen on boot; the system is fine with whatever the default acceleration method is, AccelMethod is precisely the only change
<cjwatson> so I can't say I'm terribly impressed so far
<allquixotic> cjwatson: Is it a desktop, or a laptop?
<cjwatson> laptop
<allquixotic> What architecture and how much RAM?
<hwilde> so anybody have a good tool to view cpu load per thread for multithreaded apps ?
<cjwatson> allquixotic: FWIW, the testing on that page is mostly from developers (albeit not X developers), so they should generally be well-practised at distinguishing issues
<cjwatson> allquixotic: i386, 1GB
<allquixotic> cjwatson: So you're using the -generic flavored kernel and not server?
<cjwatson> allquixotic: yes
<allquixotic> Ok. I was just checking -- currently the DRI2/UXA stuff is very broken with PAE
<directhex> hwilde, htop i think
<directhex> wait, per THREAD? no idea
<hwilde> yaeh exactly :/
<allquixotic> So even if we did have a whitelist, it would have to be for either i386/4GB, or x86_64
<hwilde> directhex, there has to be some way to figure out which thread is cpuing tho ...  i can't be the only one to ever need to debug this
<allquixotic> cjwatson: I'm on a GM965 laptop myself, but I'm using x86_64... Much of the code involved _is_ architecture dependent, so maybe that is part of your issue
<cjwatson> I'm sure it may be, but I'm on a very common configuration here so I think that is relevant input
<cjwatson> code that only works on amd64 is slightly more use than a chocolate teapot, but not really enough to get enthusiastic about :-)
<directhex> who uses fringe arches like m68k and i386? o_o
<kees> cjwatson, Keybuk: it seems this patch broke usplash for some people: http://people.ubuntu.com/~kees/usplash-testing/sig.patch
<kees> cjwatson, Keybuk: any idea why?
<allquixotic> cjwatson: Of the entries for PCI ID 8086:2a02 (GM965 Crestline), there is one mixed (bryce), two negative, and two positive. I think I'd like to start with reaching seb128 to debug why it crashed for him on resume, as that's definitely not the case here
<kees> drawing is external to the alarm handler now, so it didn't look like those were needed any more
<cjwatson> allquixotic: count me as negative for the same ID
<allquixotic> seb128 and portis25 didn't file launchpad bugs associated with their negative reports...
<allquixotic> or they didn't link them
<cjwatson> kees: I'm not sure, but what's the cost of just reverting it?
<bryce> allquixotic: thanks for your look at investigating these problems.  Getting seb128's issue captured in a bug report and forwarded upstream would be a good step
<cjwatson> I'll file one later, but had better upgrade first
<kees> cjwatson: none, it's already going into the archive.
<bryce> (cjwatson: your blank screen issue might be the usplash issue kees is presently uploading a fix for)
<kees> cjwatson: I just wanted to see if there was some general knowledge in this area I was missing.
<cjwatson> bryce: could be, but it doesn't happen with EXA
<cjwatson> and usplash itself displays fine
<allquixotic> bryce: I was a GM945 laptop owner for 2 years, and almost a full year of GM965 torture... I regularly grab git master from upstream and test things out when Ubuntu isn't on the forefront; I was testing GEM and nagging upstream on crashes when we were still using the grand old aperture rendering mode
<allquixotic> So this is very familiar territory to me
<bryce> cjwatson: yeah usplash was displaying fine for me, but I could confirm that removing it from the kernel boot line made the issue go away
<cjwatson> I see, OK
<bryce> cjwatson: OTOH pitti is seeing a similar blank screen issue for which usplash has been ruled out
<cjwatson> look, EXA's performance is certainly dreadful at the moment; I just think we should be ironing out a few more problems and *then* talking about making it the default
<bryce> allquixotic: excellent, thanks for your help!
<cjwatson> just seems like we're putting the cart before the horse a little bit
<bryce> allquixotic: fwiw, I too have been very impressed at the performance improvement for UXA, but as X maintainer would like to see the overall stability significantly improved before I'm really comfortable supporting it (even for limited numbers of chips)
<allquixotic> my experience is that Zhenyu Wang at Intel is one of the guys assigned to hack on stable, whereas the others are variously working on master, one of the in-development feature branches, or occasionally, stable
<allquixotic> so maybe we could also bug him for help
<bryce> I am also uncertain I want to support EXA on some chips, and UXA in some others, since that makes twice as much work to manage :-)  (and we already have plenty of bugs against -intel as it is)
<allquixotic> going on sheer frequency and content of commits, Zhenyu puts a lot of work into the stable branches of xf86-video-intel
<bryce> yep
<allquixotic> oh, another relevant data point we need to collect about _any_ -intel problems
<allquixotic> is a compositing window manager enabled or no?
<bryce> I really wish they had more engineers supporting the stable release.  they seem to pump out releases with what seems like limited amounts of testing (esp. against 8xx chips)
<allquixotic> some problems manifest only with, or only without compositing... helps narrow the hunt for upstream, if nothing else
<cjwatson> (no, in my case, but not really relevant since the black-screen is at gdm)
<bryce> hmm
<allquixotic> I think Intel is trying to unofficially deprecate the 8xx chips. I mean, they're old, and using all this transparency and compositing "with" those cards basically throws a large amount of work at the CPU instead... and the associated CPU with an 8xx chip is not going to be stellar either
<allquixotic> they support them in spirit, but in practice, their work is gonna go at the latest cards
<allquixotic> Nvidia does the same
<bryce> that's fine, but it doesn't help us
<bryce> a huge chunk of our bugs in -intel launchpad are 8xx stuff
<allquixotic> has there been consideration of dropping "official support" for 8xx according to Ubuntu's hardware compatibility list?
<bryce> allquixotic: but you're right at Intel's focus; it seems almost not worthwhile to bother forwarding the 8xx bugs.
<allquixotic> if not now, definitely in the future that will be something to consider
<bryce> allquixotic: I think many people would be upset by that
<allquixotic> but unless we want to have 8xx cards load xf86-video-vesa and use DRI's swrast....
<bryce> allquixotic: Ubuntu targets educational use cases which have old hardware, as well as server use cases where on-board graphics is not unusual to be 8xx based
<allquixotic> if upstream won't fix it, and Canonical doesn't have Intel hardware gurus...
<allquixotic> what's to be done?
<bryce> yeah I know
<bryce> we need community people to step up to the plate, as happens with -ati, -nv, -nouveau, -radeonhd, etc.
<allquixotic> -vesa and swrast will always be an "option" to get them a display, but losing 3d rendering because upstream is offering features that are too new for old hardware to support -- where the hardware could do basic 3d just fine in previous releases - is a serious regression
<bryce> -fglrx drops support for old chips, but -ati still supports them going all the way back
<allquixotic> and I've always been an advocate of software NOT standing in the way of functional hardware for any reason
<bryce> true, although a number of the 8xx bugs are even more basic than 3d... like just booting X
<bryce> allquixotic: I told Intel (well, jesse) that as a minimum if they do proceed with dropping support for more 8xx chips, that they need to first release docs for the chips, so the community has all they need to do support
<allquixotic> well, for now, the best I can do is bring bugs to the attention of upstream, and try to provide focused, verified bug reports... unless the bug is very basic and easy to spot in code... I'm a systems programmer, but I haven't done hardware interface hacking before, either in userspace or kernel
<bryce> dropping official support without releasing register documentation ----> FAIL
<allquixotic> and I'm sorry to say I can't help at all with the 8xx stuff because I don't own an 8xx
 * bryce nods
<bryce> yeah same here, just ranting...
<allquixotic> they haven't released register docs on 8xx?!
<allquixotic> wow.
<allquixotic> have they done it for the 915+ chips?
<allquixotic> bryce: If upstream were to make a new release, when would be the cutoff for pulling it into Jaunty?
<allquixotic> Would be nice to see if Intel pushes 2.6.2 or so to help with these issues
<bryce> I would be willing to pull a 2.6.2 even up to beta
<bryce> although alpha-6 would probably be the latest I'd be willing to consider defaulting on UXA
<bryce> but even that is pushing it pretty late to get adequate testing
<allquixotic> bryce: Can we do something similar to what Fedora does with "preview" features, if we can't enable by default? They include it, and mention it, but disavow support etc for those who enable it...
<bryce> I guess, what specifically do you have in mind?
<bryce> allquixotic: what I want to avoid is that it seems Intel frequently puts out a new tech that is advertised as solving a whole mess of issues, but has lots and lots of regressions, and then they stop giving support for the older tech
<bryce> so we get left between the choice of two buggy options, and -intel users find themselves hating the world
<allquixotic> bryce: IIRC, Fedora basically discussed Kernel Mode Setting (a different feature, but the same process applies) in Fedora 9 - for ATI - and they told people how to enable it, but turned it off by default
<bryce> often we move to the newer tech with the hope that soon upstream will fix all the remaining issues soon enough, but often that doesn't quite happen
<allquixotic> bryce: OTOH, I really like the Intel performance on 8.10 :) The -intel desktop experience isn't bad on my mom's GM945 with metacity compositing
<bryce> indeed we're still waiting on some issues from the XAA -> EXA issue, and already upstream is moving EXA -> UXA ;-)
<allquixotic> I think whatever you went with for 8.10's stack was a win in terms of performance
<allquixotic> features, maybe not, but it's silken smooth for Firefox surfing
 * ScottK tosses in a grumble about compiz hacks that break other WM.
<allquixotic> I see your point about Intel's ever-evolving stream of unstable innovations, and at some point the innovation itself needs to turn toward stability and performance
<allquixotic> I have a gut feeling that the GEM/DRI2/KMS plateau will be a point of significant stabilization and performance
<allquixotic> but if I were an Intel developer and I have a schedule to (for example) get KMS "ready" by Q1 2009, I would be focusing on dealing with issues related to having the entire feature set enabled
<allquixotic> which means that 9.04's feature set becomes the ugly duckling that lacks KMS, and half the Intel guys haven't touched that path for weeks
<bryce> here's one UXA bug - 322356
<ogra> cjwatson, are there chances that the nslu2 d-i initrd.gz could grow over 4M (its 3.3 currently) i think i found our issue in debian bug 451882
<ubottu> Debian bug 451882 in apex-nslu2 "Increase CONFIG_RAMDISK_SIZE" [Normal,Closed] http://bugs.debian.org/451882
<ogra> seems they raised the ramdisk size to 6.2M ... that cuts down the available kernel space to less than 2M
<allquixotic> bryce: CONFIG_HIGHMEM64G implies PAE. Intel has been "loudly" proclaiming that users should not try to use UXA with that configuration
<allquixotic> So that bug is a "known; being worked high priority" as far as I am aware. Could be ready for 2.6.2, who knows
<bryce> allquixotic: ok, can you update the bug to that effect?  If you can include a url to the official statement from them on that, it would help.
<allquixotic> it was on the ML, let me dig
<bryce> or a link to an upstream bug report would be nice
<allquixotic> bryce: Updated
<allquixotic> https://bugs.launchpad.net/xserver-xorg-video-intel/+bug/322356
<ubottu> Ubuntu bug 322356 in xserver-xorg-video-intel "[i965] xorg on intel freezes on startup when using a kernel with CONFIG_HIGHMEM64G and AccelMethod is set to UXA " [Undecided,Confirmed]
<bryce> allquixotic: thanks
<ryu> hi
<LaserJock> slangasek: you around?
<slangasek> LaserJock: hi
<cjwatson> ogra: hard to say for sure, but I'm sure you could take it back down a bit
<cjwatson> hmm, now I get the black screen with EXA too. blast. I'll try with new usplash tomorrow
<ebroder> Does anyone know if I can find the git repo for Ubuntu's xserver-xorg-video-ati changes? (I'm trying to track down LP bug #289026)
<ubottu> Error: Could not parse data returned by Launchpad: timed out (https://launchpad.net/bugs/289026/+text)
<ebroder> (X fails to start on Radeon HD 2400 Mobility (Ubuntu 8.10 RC)) since ubottu didn't find it)
<maxb> Hmm, I just had to do a "Partial upgrade" rather than a normal update-manager run - shouldn't libgpod4 declare "Replaces: libgpod4-nogtk" ?
<bryce> ebroder: there is no git repo for -ati
<bryce> ebroder: use upstream's git repo for -ati
<bryce> ebroder: or look in the xserver git repo (directions for X git usage at http://wiki.ubuntu.com/X/)
<bryce> heya Rocket2DMn
<ebroder> bryce: Ok. What are your thoughts on trying to track down this particular bug for an SRU? Should we work on the backport instead?
<Rocket2DMn> hey bryce
<bryce> ebroder: a backport is more likely to go through
<bryce> ebroder: however if you can identify a sufficiently minimal patch that can be shown to have no regression risk, then maybe an sru would be doable
<ebroder> bryce: Yeah....that, uh, sounds kind of hard. I think I'll probably work on the backport
<bryce> sounds goo
<bryce> +d
<cjwatson> jelmer: I'm trying to GPG-verify your subvertpy sync, but the key used to sign it (060F66E5) doesn't seem to be on the keyservers
<cjwatson> jelmer: could you please push it somewhere?
<jelmer> cjwatson, it's a subkey that's on my main key (1EEF5276)
<cjwatson> ah. funny that subkeys.pgp.net didn't return it
<cjwatson> oh, drat, something weird with the firewall
<cjwatson> ok, got it now
 * ogra gives up in desparation ... 
<ogra> :(
<Moe> Hello ..
<Moe> I'm wondering if pitti is around
<Moe> alright, doesn't seem to be the case
<Moe> good night
<directhex> Moe, pitti occasionally lets his feeble human side show, and succumbs to his biological need to sleep. the plan is to patch that out in the next beta
<cjwatson> OTOH, directhex sometimes forgets to read part messages ;-)
<directhex> cjwatson, i saw he parted, but decided my reply was too damn good to go unbroadcasted
<Caesar> Should I discuss Hardy backport requests here, or in another channel?
<maxb> Caesar: Depends whether it's main or universe I guess.
 * Caesar checks
<Caesar> All three are in universe
<maxb> #ubuntu-motu then
<Caesar> righto
<Caesar> thanks
<maxb> (I think)
#ubuntu-devel 2009-02-11
<TheMuso> slangasek: Do you still get lots of CPU usage with pulseaudio under jaunty when playing music, or is this in intrepid where youe xperience CPu load?
<slangasek> TheMuso: jaunty
<TheMuso> slangasek: Right. What hda codec do you have?
<Amaranth> is 12% for pulseaudio on a 2Ghz C2D when playing music in banshee "lots of CPU usage"?
<TheMuso> Amaranth: Depending on pulse version, probably.
<slangasek> As far as I'm concerned, showing up in top is 'lots of CPU usage'
<Amaranth> I've got 0.9.14 now and it's only using 4-6% so I dunno
<TheMuso> Amaranth: Again, what hda codec do you have, if you have hda at all
<Amaranth> Then again I'm watching a flash video, not playing music in banshee
<slangasek> TheMuso: remind me how to find the codec?
<Amaranth> 00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 03)
<Amaranth> 	Subsystem: Apple Computer Inc. Device 00a1
<Amaranth> unless there is something else you're looking for?
<TheMuso> slangasek: CHecking with aplay -l, or /proc/asound/card#/codec# I think it is
<slangasek> ah, *a*sound, right
<TheMuso> so for me its /proc/asound/card0/codec#2
<slangasek> TheMuso: Codec: Analog Devices AD1981
<Amaranth> $ cat /proc/asound/card0/codec#0
<Amaranth> Codec: Realtek ALC889A
 * Amaranth cries
<Amaranth> I already know I'm boned
<TheMuso> Amaranth: Ok for you the high CPU is understandable, since glitch free doesn't work well if at all for realtek hda codecs, according to upstream.
<TheMuso> slangasek: I need to check the driver broken list to see if analog devices codecs are known to not work with glitch free.
<TheMuso> slangasek, Amaranth, one thing you could try when you have a chance is to edit /etc/pulse/default.pa and add "tsched=0" at the end of the line that loads module-hal-detect.
<TheMuso> This turns off glitch free.
<Amaranth> gah, between pulseaudio and banshee 25% of one of my cores is gone
<TheMuso> slangasek: Your codec is not on the broken list, but this doesn't mean anything unfortunately.
<slangasek> TheMuso: er, I thought it was asserted last week that upstream's list of devices that didn't work with glitch-free was adequately comprehensive?
<Amaranth> E: module-alsa-sink.c: ALSA woke us up to write new data to the device, but there was actually nothing to write! Most likely this is an ALSA driver bug. Please report this issue to the ALSA developers. We were woken up with POLLOUT set -- however a subsequent snd_pcm_avail_update() returned 0.
<Amaranth> I get that about 5 times a second from pulseaudio
<TheMuso> slangasek: It may have been, but I can't remember whether it was myself or someone else who said it, and if I said otherwise then, I certainly change it now, based on whats on the upstream wiki.
<slangasek> TheMuso: so if we don't know what devices are broken, that makes it hard to implement an appropriate blacklist for jaunty?
<Amaranth> now pulseaudio is down to 2-4% CPU though
<TheMuso> slangasek: Indeed it does.
<TheMuso> Amaranth: After adding that flag?
<Amaranth> yeah
<TheMuso> Right.
<TheMuso> I need to put my realtek codecs through a thorough test with pulseaudio from jaunty and my PPA to see where my cards stand.
<Amaranth> I seem to always get broken hardware
<slangasek> well, pulse is only at 4% on my system before making this change - but as I said, this is comparable to what the media player itself takes, and the media player has to do real work
<Amaranth> also don't most laptops use realtek codecs?
<RAOF> For what it's worth, pulseaudio 0.9.15 _still_ underruns at the barest hint of CPU usage on my hda-intel.
<Amaranth> slangasek: what media player is that? obviously not one using gstreamer
<TheMuso> Amaranth: Unfortunately realtek codecs are some of the most common, however I *BELIEVE* its an alsa driver issue.
<slangasek> Amaranth: er, it is one using gstreamer
<slangasek> perhaps I have a faster processor than you?
<Amaranth> slangasek: You got a 2.8Ghz Core i7 or something?
<TheMuso> hrm even the login sound has glitches in it for my notebook.
 * TheMuso turns off glitch-free
<RAOF> Yeah; banshee and pulseaudio trade places at ~2% CPU regularly on this system.
<Amaranth> I find it amusing that glitch-free _causes_ glitches
<Amaranth> Also, banshee and rhythmbox both used 10% CPU on my slower computer as well
<Amaranth> It seems as my CPU speed increases their use of the CPU does as well
<slangasek> clearly something was lost in translation, and it was meant to be called "free glitches"
<TheMuso> Ok, turning that off helped the login sound, now time to test with rhythmbox and mp3s.
<Amaranth> RAOF: What processor?
<RAOF> core 2 7400 or some such.
<TheMuso> I'm seriously considering offering Lennart SSH access to a box to help debug this issue on a realtek device.
<RAOF> Amaranth: 7200
<Amaranth> RAOF: How about in real terms? 2.4Ghz? 2.2Ghz? :P
<RAOF> 2.0 GHz.
<Amaranth> Cache matters but not for this
<Amaranth> grr, that's what I have
<Amaranth> Why is my pulseaudio and banshee using 5x as much CPU?
<Amaranth> I've got the T7300 (2.0Ghz)
<RAOF> With 4MB cache :P
<TheMuso> RAOF: Have you tried turning off glitch free?
<RAOF> Just have.
<TheMuso> right
<Amaranth> Is pulseaudio really not supposed to show up in top using CPU?
<RAOF> Adding tsched=0 seems to bump CPU usage up another couple of percent, but on the plus side it hasn't crackled like mad, either.
<slangasek> Amaranth: who are you asking?  *I* consider it unacceptable for a software sound mixer to take up that much processor time...
<Amaranth> I meant typically, not ideally
<Amaranth> I know at one point rhythmbox was using 10% CPU and using pulseaudio made rhythmbox use less but combined with pulseaudio it was still 10%
<Amaranth> But now with banshee it's using more CPU having pulseaudio then not
<TheMuso> Here I have rhythmbox using 5% and pulse using 3% this is with glitch free. No crackling in sound, but not sure about logs. WIll check that in a sec.
<TheMuso> Amaranth: I get the same message re no data to write although pulse was woken up, however I don't get any glitches in audio. However any sound played via canberra with glitch free turned on has glitches in it.
<Amaranth> yep, definitely sounds like he meant "free glitches"
<RAOF> TheMuso: Are you also using pluse 0.9.15 in your PPA?  Do you also find the 'flat volume' thing, or whatever it is that causes app volume changes to influence sink volume (and it seems, often mute it for no discernable reason) somewhat unintuitive?
<TheMuso> RAOF: no still using 0.9.14 here atm, although will upgrade shortly.
<LaserJock> is postgresql
<LaserJock> lighter than mysql
<TheMuso> Wow, pulseaudi 0.9.15~test1 turns on my notebook's digital out.
<TheMuso> And uses that as the default sink.
<RAOF> This sounds unlikel to be what you want.
<TheMuso> yep
 * TheMuso clears home dir pulse files
<TheMuso> And things work again
<TheMuso> What really scares me with pulse is the fact that home dir files can cause pulse to break when one upgrades from one version to another.
<RAOF> Mmm.  Turning off glitch-free seems to (a) make it stop glitching, and (b) make pulseaudio increadibly chatty about ALSA waking it up.
<TheMuso> great
 * TheMuso does that here to see what happens.
<RAOF> It appears to be generating that message at a rate of ~100Hz, given what the ratelimit warning is suggesting.
<TheMuso> ouch
<TheMuso> Well except for canberra, I don't get glitches with audio from rhythmbox. Time to try some wav files with aplay etc.
<TheMuso> aplay works ok
<TheMuso> RAOF: How you finding the new volume stuff in pulse? I am finding with rhythmbox it constantly changes volume when I change tracks.
<RAOF> TheMuso: I find that it seems to mute for no discernable reason.
<RAOF> Using Banshee it doesn't do anything strange on track change, but when I switch apps strange things happen, which usually results in the sound being muted.
<RAOF> Also it seems to override the volume-control-applet, which isn't my idea of a good time.
<RAOF> Oh, and that it'll be muted on startup without fail.
<TheMuso> RAOF: Right, I may not have things set up correctly with configs etc however.
<TheMuso> Pulseaudio IMO is getting more complex, but introducing more problems. I am seriously starting to question whether its worth keeping it around, at least for jaunty+1 and beyond.
<RAOF> You seem to turn off module-positional-sounds, or whatever, which apparently is broken, so that's right.
<RAOF> Pulseaudio _desperately_ needs an actual user-visible use-case.
<TheMuso> RAOF: I agree, switching streams between devices is not common enough for users to want it yet.
<RAOF> I disagree.  It's just a policy-daemon & UI away from being awesome.
<TheMuso> I don't use pulse, because it introduces too much latency for speech.
<RAOF> I want to switch streams ALL the time; when I plug in my USB speakers, headset, unplug to move around, ...
<TheMuso> RAOF: But there are so many stability/glitch issues with the underlying infrastructure, that some users would think dealing with alsa's annoyances is better than glitchy sound and fancy stream switching.
<RAOF> I suppose.  But I'd like plugging in USB audio devices to work _properly_, and that's just not going to happen with ALSA, is it?
<RAOF> But if pulse isn't actually getting _better_ at doing just the sound bit, then... :(
<RAOF> I guess you can only live on "it'll get better, really" for so long.
<TheMuso> RAOF: No, I agree, the plugging in devices etc is neat.
<TheMuso> Anyway, I've offered Lennart ssh access for testing realtek glitch free issues so we will see what comes out of that.
 * TheMuso is seeing lots of debian changelogs with git hashes in them, and IMO it looks ugly.
 * RAOF thinks git could do with growing real revnos
<TheMuso> I don't mind git hashes, but not parts of them in debian changelogs.
<maxb> But revnos are somewhat incompatible with git's love of rewriting history
<ion_> One should never rewrite history that has already been pushed.
<jdong> is THAT what Git does?
<jdong> I've been wondering why shortlog dates on git.kernel.org seem to jump back and forth; and I blamed it on my lack of sleep
<ion_> Sure, if you add --force everywhere. :-P
<ion_> As good an idea as using --force with any other program with an equivalent parameter.
 * jdong will award one McDonald's chocolate chip cookie for the first person to invent the GUIID (The Globally Unique [strictly] Increasing Identifier)
<jdong> you guys laugh now, but in 50 years I will be one cookie poorer :)
<superm1> lool, ping.  it looks like your debian maintainer of gnome-python-desktop.  bug 223671 needs to get fixed now, but i would like to make sure that it's fixed in a way that you as debian maintainer can agree upon
<ubottu> Launchpad bug 223671 in ubiquity "wnck and rsvg should be provided in seperate packages not requiring gnome" [Undecided,New] https://launchpad.net/bugs/223671
<ion_> Simple. Just setup an official server with a simple protocol to request a new number. :-P
 * jdong quickly trademarks Ubuntu LIVE (TM) Number (sm)
 * bryce reserves GUIID 42
<bryce> heya TeTeT
<TeTeT> hi bryce
<ion_> jdong: nc heh.fi 56888
<jdong> ion_: lol can I have that code so I can run another one?
<jdong> </irony>
<ion_> ;-)
 * jdong looks up and sees a fellow Linerva resident
<mdomsch> superm1, ping
<superm1> mdomsch, contentless pong
<mdomsch> hehe
<mdomsch> xps m1330 headphone volume sucks
<mdomsch> solution known?
<superm1> mdomsch, not until IDT's equalizer support enters ALSA
<mdomsch> boo
<superm1> a lot of codecs are intentionally set lower than they can actually drive
<mdomsch> yeah, but I can't even hear the audio with noise-canceling headphones on
<superm1> i wasn't aware the 1330 was part of them, but it's not a surprise.  if you drive it any higher, you'll hit some resonant frequencies
<superm1> on the chasis
<superm1> oh wait you said headphone volume. no this i wasnt aware of
<superm1> make sure you are turning up "front" all the way?
<superm1> as well as PCM and master and what not
<mdomsch> mplayer -af volume=20
<mdomsch> is the only thing that helps
<mdomsch> yeah
<mdomsch> all lines maxed
<superm1> perhaps your headphone jack is being detected as a line out rather than a HP
<superm1> i've been seeing that on another platform. do both headphone jacks do this?
<mdomsch> there are 3 jacks - only one (the one labeled microphone) outputs any audio at all
<mdomsch> regardless of the 'line in as output' setting
<mdomsch> so I think I"m getting "line out" levels instead of headphone levels
<superm1> what kernel is this?
<mdomsch> fedora 10 2.6.27.x
<mdomsch> (my ubuntu load is horked, not your problem...)
<superm1> can you double check with a git snapshot of alsa?  if the problem persists, i can try to help out more tomorrow
<mdomsch> I can't tonight, but no worry or rush - I just thought you might know already
<mdomsch> I'm OoO rest of the week
<mdomsch> rain! :-)
<mdomsch> superm1, have a good week
<superm1> yikes yeah!, time to get off the patio.  well let me know if it persists with a snapshot when you get a chance and we'll go from there
<mdomsch> and hail!
<hyperair> jpds: hmm intersting. i never knew there was such a thing as memoserv
<hyperair> jpds: it's fine =p i was just curious where you got it from.
<superm1> slangasek, can you re-enable the daily cron job on mythbuntu disks?  the alpha4 disks are not going to happen, but would like to be able to see that a few of the fixes for the problems at what would have been a4 are getting fixed still
<dholbach> good morning
<stgraber> morning ? already ? I should really go to bed then :)
<LaserJock> man
<LaserJock> it seems like dholbach's mornings keep getting earlier and earlier
<stgraber> yeah, it's not even 7am in europe :)
<dholbach> LaserJock: no no - I was up earlier yesterday :)
<LaserJock> anybody here happen to know SQL?
<Mithrandir> LaserJock: just ask your question, lots of people here probably know SQL
<LaserJock> I've got a postinst that's failing like: Failed to execute SQL: GRANT ALL PRIVILEGES ON moodle.* TO www-data@localhost IDENTIFIED BY
<LaserJock> it seems to not like having a "-" i.e. www-data
<LaserJock> is that a common problem?
<Mithrandir> you need to quote it, I suspect.
<Mithrandir> and you should create your own db user and use that instead of a shared one.
<LaserJock> yeah, well, i didn't pick that
<LaserJock> but the quoting I could maybe fix
<pitti> Good morning
<directhex> no it isn't. my new pc STILL isn't working
<pitti> directhex: I have tried pitti/debian/patches/nosleep.patch for a while, but after some time the system became really unstable, so I reverted it
 * StevenK waves to pitti 
 * pitti hugs StevenK
<lool> superm1: Until now we have been reluctant on the Debian side to split up modules as we don't have a mean to map modules to packages in our packaging arsenal
<lool> superm1: I don't really know how you could find a way to avoid splitting, or it would be complex just to please Debian
<atari2600a> hey, I'm not sure if this is the correct place to ask, but asking the developer channel seems right
<atari2600a> how come libdvdcss isn't included in restricted?  I'm sure many people prefer VLC over mplayer
<atari2600a> (or whatever totem is based off of)
<liw> it is not legal to distribute them in some parts of the world that are considered important to Ubuntu, unfortunately
<atari2600a> oh
<atari2600a> that sounds....quite reasonable actually
<atari2600a> well luckily videolan maintains a /deb directory
<liw> I think the legal restrictions are incredibly unreasonable :)
<atari2600a> well thank you, /parting now
<pitti> Keybuk: hello
<pitti> Keybuk: got a minute to discuss some questions about readahead and bootspeed?
<pitti> seb128: got my current bootcharts at http://people.ubuntu.com/~pitti/tmp/, BTW
<seb128> hey pitti
<pitti> seb128: I recreated /etc/readahead/boot to include the full desktop
<pitti> and that dropped gdm->desktop from 35 to 18 seconds
<pitti> with only adding about 1.5 to the grub->gdm time
<seb128> that's good
<seb128> is that on your laptop?
<pitti> seb128: yes
<pitti> seb128: I'm running vesa and metacity now, though
<seb128> 18 seconds on a slow disk is good
<pitti> (-intel is broken ATM)
<pitti> seb128: it's not quite the 8 seconds I get on a hot cache (second login), but much better
<seb128> gdm is taking a lot of time
<pitti> seb128: be aware that this is not autologin
<seb128> gdmgreeter to gnome-session is over 15 seconds on your chart
<pitti> so there's a period of low cpu and I/O when I log in
<pitti> so the two are neatly separated
<seb128> ok, I guess the 3 seconds blue gdm bar is you typing your password
<pitti> the 6 seconds between aplay and the gdm fork is the entering password time
<seb128> that makes sense
<pitti> hm, or that
<seb128> there is not a lot of easy desktop targets now looking at the chart
<pitti> I deliberately waited a couple of seconds to let everything else settle
<pitti> seb128: you are looking on the -gnome or -default one?
<seb128> default
<seb128> the gnome one is cheating ;-)
<pitti> well, "optimizing" :)
<pitti> but yes, desktop startup is pretty tight now
<seb128> well not something users will get
<pitti> I wish we wouldn't need this seahorse thing
<pitti> seb128: that's something I want to discuss with Keybuk (extend the readahead lists)
<seb128> pitti: did you notice seahorse-daemon is not started now?
<pitti> and we should get rid of this cpp and cc1
<seb128> pitti: you don't want the agent either?
<pitti> seb128: right, daemon doesn't start
<pitti> seb128: well, of course I'd like to keep the functionality
<pitti> just unqualified wishful thinking :)
<seb128> we need dbus activation on signals
<pitti> it should get d-bus activated or so
<pitti> well, neither gpg nor ssh support d-bus, they just check an env variable, don't they?
<pitti> $GPG_AGENT_INFO and $SSH_AUTH_SOCK
<seb128> right
<seb128> SSH is gnome-keyring
<seb128> I'm wondering if we need a gpg agent by default
<seb128> or if that should be conditional on a gconf key too or something
<pitti> I was just going to ask
<pitti> seb128: at least we could convert it to an xdg autostart instead of an Xsession.d/ script
<pitti> then it can start later, and in parallel
<pitti> ah, no
<seb128> there is no xsession script for this one
<pitti> it needs to set that silly env var for all processes
<seb128> there is also a gdmprefetch taking 1.6 seconds in your chart that we should comment
<seb128> I think Keybuk said that was useless
<pitti> martin    3975  0.0  0.6  19716  6536 ?        Ss   10:16   0:00 /usr/bin/seahorse-agent --execute x-session-manager
<pitti> hm, but that looks like an Xsession.d script...
<pitti> /etc/X11/Xsession.d/60seahorse-plugins
<seb128> do we install that by default?
<seb128> or is that something you added?
<seb128> it's a recommends so it's installed
<pitti> oh, what's that apport thing doing there...
<seb128> I've not it installed on this box ;-)
<seb128> dunno
<pitti> ah, it indeed caught a crash
<seb128> I noticed apport on my charts too
<pitti> it's tiny on the -gnome chart (no crash there)
<seb128> but that's around the time where the desktop is loaded so that's not an issue
<pitti> it's from update-notifier, I guess
<seb128> we can probably delay evolution-alarm-notify too
<pitti> seb128: seahorse Recommends: seahorse-plugins
<seb128> I'm going to use this sleep workaround too I think ;-)
<pitti> good idea
<pitti> and isn't seahorse-plugins what provides the gpg agent?
<seb128> that's it indeed
<pitti> seb128: e-a-n isn't taking much resources, though
<mvo> pitti: 18s? that is pretty impressive :)
<seb128> it creates activity for aorund 3 seconds on your chart
<pitti> seb128: oh, right, was looking at the readahead'ed one
<soren> Do I need to put something on my kernel command line to activate bootchart?
<pitti> mvo: gdm to session, not grub to session :)
<seb128> and trigger the e-d-s start I think which takes some 9-10 seconds
<pitti> soren: no, just install it
<pitti> soren: I removed /etc/rc2.d/S99stop-bootchart, so that I can run it until after GNOME started
<mvo> oh, misread :) still a good improvement
<pitti> seb128: is e-d-s really triggered by e-a-n, or rather by the panel?
<liw> hmm, gdm does not seem to allow one to configure automatic login to a specific user, but with the screen locked immediately
<jpds> soren: Just restart and there should be a png in /var/log/bootchart/ .
<pitti> seb128: or does the panel only start e-d-s once you try to open the calendar?
<soren> jpds, pitti: that's what I thought, but it didn't happen. Odd.
<pitti> soren: hang on
<pitti> soren: for me, it crashed with an exception
<pitti> I had to do a "sudo ln -s headless xawt" to make it find a library
<pitti> ./usr/lib/jvm/java-6-openjdk/jre/lib/i386/headless/libmawt.so is shipped by the package
<pitti> but bootchart looks in ./usr/lib/jvm/java-6-openjdk/jre/lib/i386/xawt/libmawt.so
<pitti> it probably needs a rebuild, or so
<soren> pitti: I've got /usr/lib/jvm/java-6-openjdk/jre/lib/amd64/xawt/libmawt.so
<pitti> soren: well, kill the rc2.d symlink and start /etc/init.d/stop-bootchart by hand after login, then you should see
<seb128> pitti: I need to check, I'm not sure
<soren> pitti: It's supposed to collect data in /var/run/bootchart, correct?
<seb128> pitti: the clock applet should try to use it only when you click on it to display the calendar
<seb128> "should"
<pitti> seb128: I'll test it; I disable e-a-n and see when e-d-s gets started
<seb128> ok
<seb128> soren: not run, log
<pitti> soren: yes, but moves them to /var/log/bootchart.tgz or os
<pitti> s/os/so/
<soren> Oh. I thought it collected data in /var/run and then turned that into a png in /var/log
<seb128> soren: right
<seb128> soren: I though you were asking where to look for the charts
<soren> seb128: I was at first :)
<soren> ..but since that failed.. :)
<pitti> seb128: confirmed, that works
<pitti> seb128: move e-d-s autostart .desktop -> ps ux|grep evo is empty
<seb128> pitti: ;-)
<pitti> seb128: so if we delay that by, say, 30 seconds, then it should be all good
<seb128> pitti: btw no need to move the rc script, you can use "bootchart=nostop" as a boot option
<pitti> seb128: nostop> nice, didn't know that
<seb128> I learned that from Keybuk some days ago ;-)
<seb128> pitti: right
<pitti> seb128: want me to upload, or do you want to?
<seb128> pitti: you can do it if you want
 * soren reboots to figure out why bootchart isn't doing its thing.
<pitti> doing then, and then I'll see how much it helped
<seb128> ok
 * mrooney waves to pitti and seb, and goes to sleep :)
<seb128> 'night mrooney
<shankhs> I think there is a bug in bzr which prevents it from passing through proxy... How can I download the source code of bazaar then?
<pitti> bye mrooney
<pitti> seb128: hm, buys some 2 seconds
<seb128> pitti: that's good to take ;-)
<soren> Well, I've figured out why bootchart doesn't run on my box... I don't get, though, why it only happens for me.
<seb128> why doesn't it work for you?
<pitti> seb128: uploaded
<soren> The bootchart init script in initrams runs with set -e. At some point, it tries to copy /lib/ld-linux.so.* into a jail.
 * seb128 hugs pitti
 * pitti hugs back seb128
<soren> I don't have /lib/ld-linux.so.* in my initrams, so the script bails out at that point, which is before it gets around to starting bootchart.
<soren> Now, why this doesn't happen for you guys is beyond me.
<soren> Do you have /lib/ld-linux.so.* in your initramfs?
<soren> And if you do, do you have any idea how it got there?
<seb128> soren: there is an init script so it doesn't need to be ran in initramfs no?
<pitti> $ zcat /boot/initrd.img-2.6.28-7-generic |cpio -t|grep ld-linux.so
<pitti> lib/ld-linux.so.2
<pitti> ^ i386
<soren> Oh, both of you are on i386?
<pitti> yes
<seb128> yes
 * pitti puts a no-change rebuild of bootchart into his ppa, to see whether it fixes the library path problem
<soren> seb128: The init script (outside initramfs) bails out if some of the right directories are tere.
<soren> there.
<pitti> maybe that'll magically fix things for you as well :)
<soren> ...which they are, becuase the init script in the initramfs creates those before failing here.
<soren> pitti: I doubt it.
 * soren patches bootchart..
<cjwatson> certainly the amd64 dynamic linker has a different name
<soren> Indeed.
<soren> I don't see how it could work at all on amd64.
<soren> Ah, it doesn't :)
<cjwatson> though I'm not seeing the bug you refer to here
<soren> but 32778.
<soren> but 327778.
<soren> cjwatson: No? Do you have /lib/ld-linux.so.* for some other reason in your initramfs?
<soren> bug 327778
<ubottu> Launchpad bug 327778 in bootchart "bootchart not working on AMD64" [Undecided,New] https://launchpad.net/bugs/327778
<cjwatson> oh, I'm out of date
<soren> Wow, spelling is hard. :)
 * soren fixes it.
<cjwatson> soren: I meant in the source code. I run i386. But never mind, I just needed to upgrade
<pitti> yay, -intel magically fixed itself again
<pitti> with today's dist-upgrade
<pitti> x and compiz are happy again
<pitti> bryce, tjaalton: ^
<soren> cjwatson: Ah, ok.
<pitti> (I noticed the usplash reversion, and maybe that indeed was it for me as well)
<pitti> I'm 100% sure I tested it without usplash, too, though; well, *shrug*
 * soren reboots to check his fix
<tjaalton> pitti: magic, and no updated X packages :)
<pitti> tjaalton: well, the breakage was equally magic, after all :)
<ogra> pitti, without any hacks like .drirc etc ?
 * soren just pushed a new bootchart
<soren> pitti: If you'd be so kind to check that I didn't break i386, that would be lovely.
<pitti> ogra: no
<pitti> soren: sure
<pitti> soren: I didn't check my PPA yet, whether the i386 rebuild works now; I'll just check your version then
 * pitti just had to rescue a .tex from his wife
<pitti> emacs thought it should write the file encoded in iso-2022-jp2 *grumpf*
<tjaalton> dholbach: looks like gnome-reset is unmaintained upstream, and broken in jaunty. maybe it should be removed frome the archive?
<tjaalton> no new upstream releases in three years
<pitti> Keybuk: WDYT about extending the default bootchart lists to cover the entire GNOME startup as well? it dramatically improves the gdm->session ready time (35 -> 18 s), while only increasing grub->gdm by 1.5 s
<soren> pitti: Bootchart improves gdm->session ready time?
<pitti> erm, s/bootchart/readahead/
<soren> Oh.
<soren> pitti: It depends on how much RAM you have, doesn't it? If readahead naÃ¯vely goes through the list trying loading stuff into ram, you might be discarding some of the earlier boot things once you start filling your cache with GNOME. I haven't looked at the readahead implementation, though. It might do something clever to avoid this.
<pitti> soren: right, if you have less RAM that you need to keep the boot and gnome in ram, you'd get taht
<pitti> that
<pitti> soren: but for that reason readahead has two stages (boot and desktop)
<soren> Ah, I see.
<soren> Still, whatever we put in the readahead list should fit in amount of RAM we put as recommended for a desktop install.
 * pitti nods
 * directhex steals all pitti's "#" characters & hides them
<pitti> o_O
<pitti> directhex: oh, I see :)
<pitti> directhex: better *use* them :)
<directhex> pitti, well i have a bunch spare now...
<directhex> pitti, i get confused by debian vs ubuntu bug closing format, so go for a nice happy medium of "works in neither"
<directhex> \o/
<pitti> directhex: but # is required in both...
<directhex> i just suck then
<asac> doko: do all sun-java plugin filenames have the same name?
<asac> i mean the .so
<asac> anyone uses ppp manually here (e.g. pppoe or wvdial)?
<pitti> geser, evand: nice race on attacking the sponsoring queue :)
<jpds> pitti: Thanks for the gdata upload. I'll test the plugins later on.
<Lure> asac: Riddell said that I should check with you about some MIRs pending for Jaunty. Are you the right person or should I contact somebody else?
<Lure> asac: bug 324523 and bug 325858
<ubottu> Launchpad bug 324523 in opencv "Main inclusion request for OpenCV" [Medium,New] https://launchpad.net/bugs/324523
<ubottu> Launchpad bug 325858 in lensfun "Main inclusion request for lensfun" [Medium,New] https://launchpad.net/bugs/325858
<RainCT> asac: why do you ask?
<directhex> pitti, with ndoc done, there are now officially only two Mono apps (libs are another topic) in Ubuntu built against the 1.0 runtime. one is blocked on a mono sync, the other is blocked on a lib stuck in debian NEW (though we could 0ubuntu1 the lib if need be)
<asac> RainCT: in ~network-manager team ppa there is a new ppp package ;)
<pitti> directhex: want me to look into the mono sync?
<asac> RainCT: just would like a confirm from a "manual" user that it doesnt break too much
<asac> before upload
<pitti> directhex: s/look into/just do it if it is okay/
<directhex> pitti, that'd be lovely
<pitti> directhex: bug #?
<directhex> pitti, bug 323790
<ubottu> Launchpad bug 323790 in mono "Please sync mono 2.0.1-4 (main) from Debian experimental (main)." [Undecided,New] https://launchpad.net/bugs/323790
<RainCT> asac: Sorry, I'm not using it anymore, was just curious :)
<RainCT> (I used wvdial before Hardy, when it was necessary to manually configure 3G devices like a modem.. Now nm configures them automatically, and I've switched to WiMAX anyway)
<pitti> directhex: done
<directhex> woo! i'll wait for it to filter through, and give muine a little test in a pbuilder
<Laney> \o/!
<directhex> now to give a MOTU a back rub until they let me stick sublib straight into the archive
<pitti> cjwatson: you are already doing the gparted sponsoring?
<slangasek> superm1: yep, mythbuntu reenabled
<RainCT> kirkland: Hey. I'm wondering what the MOTD tab in screen-profiles is supposed to be for :P
<cjwatson> pitti: yes, please see the latest comments in the bug, I want to hear back from Debian on the .orig.tar.gz before proceeding
<kirkland> RainCT: if you install screen-by-default-at-login, you'll miss the MOTD on login
<directhex> Laney, muine was your work, do you want to give it the requestsync poke once it's tested on jaunty? or shall i
<pitti> cjwatson: ah, ok
<kirkland> RainCT: it's easy to disable, F9->manage-default-windows->uncheck MOTD
<tjaalton> hmm, libmjpegtools0c2a was removed from the archive?
<RainCT> kirkland: and wouldn't it make more sense to show it above the bash prompt, and not have it always there?
<kirkland> RainCT: perhaps...  how do you suggest doing that?
<RainCT> (well, I'm still on Intrepid, from what I've heard perhaps in Jaunty the MOTD is more interesting :))
<kirkland> RainCT: i couldn't figure out how
<kirkland> RainCT: MOTD is slightly more dynamic, which is why that's a watch in the tab
<RainCT> kirkland: uhm.. just printing the MOTD and then launching bash doesn't work?
<kirkland> RainCT: how do you know you want to run bash?
<RainCT> kirkland: or whatever shell it is.. aren't they all the same?
<RainCT> kirkland: well, nvm about this :)
<kirkland> RainCT: i'm open to ideas
<RainCT> kirkland: Another thing, the menu doesn't work fine here (it can't handle resizing, etc)
<kirkland> RainCT: i'm not wild about dedicating a tab to it
<Laney> directhex: I don't mind. I'll be home at 5.30 or so to do it but do it sooner if you can
<Laney> I have reached not-caring-about-my-uploads-page nirvana
<directhex> there's an uploads page?
<pitti> speaking about ext4, I should update the usplash fsck integration...
<Laney> yeah, go to your launchpad profile
<RainCT> directhex: launchpad.net/people/+me/+packages
<Laney> "related software"
<Laney> RainCT: URL NERD
<directhex> Displaying first 30 packages out of 32 total
<directhex> that's a lot!
<Laney> \o/
<directhex> why on *earth* did i fix a bug in the "gourmet" package?
<directhex> a *python* app!
<RainCT> lol
<RainCT> directhex: look at sebner's page.. "Displaying first 30 packages out of 302 total" \o/
<RainCT> (but most of those are syncs.. bah :P)
<Laney> Look at sysinfo 0.7-1ubuntu{1,2,3,4} ;)
 * RainCT thinks that "sponsored packages" should also be displayed :P
<directhex> RainCT, #launchpad wi'yersen then!
<kirkland> RainCT: hmm, i'm not succeeding
<kirkland> RainCT: i'm tring to add something like this to ~/.screenrc-windows
<kirkland> screen -t shell 3 cat /etc/motd && $SHELL
<cjwatson> pitti: ext4/usplash/fsck> good catch, I missed that
<pitti> cjwatson: just noticed, apparently it was the first time I got fsck at boot on my new ext4 system
<highvoltage> you and your fancy shiney ext4 filesystems
<pitti> I like losing data :)
<johan> isn't the packages from ddeb.ubuntu.com supposed to be sync:ed with the ones from archives.ubuntu.com?
<pitti> johan: in theory yes, in practice it's a constant source of trouble
<kirkland> RainCT: okay, i found a workaround
<johan> pitti: I'm discovering that, seems xulrunner is causing trouble today
<kirkland> RainCT: if you file a bug, i'll upload a fix :-)
<johan> pitti: and only for i386/intrepid
 * pitti -> brb, testing fsck in usplash
<RainCT> kirkland: for the MOTD or the menu?
<geser> pitti: how usable is ext4 already? I've heard a talk from Theodore Ts'o at FOSDEM about ext4.
<allquixotic> bryce: I hit something where suspend causes the computer to come back to GDM login at resume. This could be the "crash on resume" others have seen, but are we sure it isn't some sort of intentional log-off, or crash for other reasons?
<allquixotic> geser: ext4's on disk format was considered final as of 2.6.28 (which is Jaunty's kernel) and it seems ready for ordinary desktop use... all of my current partitions are ext4 and they are fine
<allquixotic> geser: It's not like ext3 is somehow _more_ reliable because it's older; I've had completely hosed ext3 partitions only because of power failure. Weak. I thought journalling was supposed to take care of that. It didn't.
<dholbach> tjaalton: sounds like a good idea
<ScottK> allquixotic: A related question is how broad is the user space tool support for ext4?
<dholbach> tjaalton: do you want to request it? if not I'll do it later on
 * dholbach needs to take the dog out
<allquixotic> ScottK: gparted seems not to be aware of ext4 yet, but Jaunty's installer is, and e2fsprogs (e2fsck, tune2fs, etc) are fully ext4-aware
<ScottK> I recall someone mentioning there's a new gparted available.
<ScottK> Just needs to be merged/packaged/or something.
<dholbach> it's in the sponsoring list
<pitti> geser: works fine for me, and fsck is pleasantly fast :)
<allquixotic> Production server sysadmins are going to be cautious regardless of how stable we say it is, only because ext4 has yet to stand the test of time as a production filesystem. So we could say it's rock solid and swear by it, but some people are going to stick with ext3 or even older cruft just because it's well understood, whereas ext4 has new things that aren't as well understood.
<allquixotic> But for desktop users, I'm going to promote ext4 whenever users ask me, in Jaunty.
<geser> pitti: they made it 6-8 times faster according to the talk
 * ScottK knows of admins that still use ext2 because it's got an established track record.
<tjaalton> dholbach: ok
<geser> pitti: so using ext4 is as dangerous as using jaunty?
<cjwatson> yes, I know about gparted, just trying to make sure we're duly synced up with Debian first
<allquixotic> cjwatson: have you filed a bug about UXA yet?
<cjwatson> no
<cjwatson> largely because I upgraded usplash and it now appears to work
<cjwatson> I'm giving it a day or two's burn before changing my comment on UxaTestingg
<kirkland> RainCT: just a bug explaining your reasoning that we don't need to dedicate an entire window to the MOTD
<cjwatson> BTW, on ext4, if you boot today's alternate installer with partman/default_filesystem=ext4 then it should autopartition with ext4 rather than ext3
<RainCT> kirkland: Okay. Have you seen this message, though:
<RainCT> >> kirkland: Another thing, the menu doesn't work fine here (it can't handle resizing, etc)
<kirkland> RainCT: oh, missed that one
<cjwatson> actually desktop too, I think
<kirkland> RainCT: hmm, yeah, open a 2nd bug for that one
<kirkland> RainCT: perhaps nijaba will know how to fix that
<tjaalton> cjwatson: I've used ext4 since day one, and installing 12 desktops with it as we speak :)
<kirkland> RainCT: b/c I don't ;-)
<cjwatson> tjaalton: sure, just saying that now autopartitioning support for it is available; previously you had to use manual partitioning to get it
<cjwatson> or upgrade in-place from ext3
<tjaalton> cjwatson: yep
<cjwatson> should I add an 'ext4' preseeding alias for partman/default_filesystem=ext4?
<cjwatson> anaconda had that parameter in some Fedora release, I believe
<cjwatson> hmm, actually that's a little tricky
<RainCT> kirkland: alright, filed bug #328066
<ubottu> Launchpad bug 328066 in screen-profiles "Why is there a tab for MOTD?" [Undecided,New] https://launchpad.net/bugs/328066
<EagleScreen> cjwatson: I think you proposed usb-creator to depends on gksu
<kirkland> RainCT: thanks
<cjwatson> EagleScreen: given its code at the time when I proposed that, it should. It would be better for it to find an appropriate root-privilege-acquisition tool.
<cjwatson> EagleScreen: my bug was that it used gksu unconditionally without a dependency
<EagleScreen> what about using su-to-root and add depends on menu?
<cjwatson> I don't care
<cjwatson> if only it weren't in the menu package, which is completely useless for everything else in Ubuntu since we use .desktop files, and quite possibly harmful ...
<cjwatson> and in universe for pretty much that reason
<kirkland> RainCT: okay, can you test this for me?  see if it works better for you?
<RainCT> kirkland: sure
<nijaba> kirkland: RainCT: sorry, trying to catch up, what would I know how to fix?
<RainCT> (also filed bug #328067, with a screenshot)
<ubottu> Launchpad bug 328067 in screen-profiles "screen-profile's menu isn't displayed correctly" [Undecided,New] https://launchpad.net/bugs/328067
<RainCT> nijaba: look at that bug please :)
<kirkland> nijaba: the screen-profiles configuration menu doesn't handle window resizes
<EagleScreen> cjwatson: I have seen .desktop files which use su-to-root and they seems to work propertly
<kirkland> nijaba: hit f9 to open it, then resize gnome-terminal
<cjwatson> EagleScreen: the menu package isn't installed by default, and we don't want it to be
<kirkland> RainCT: okay, grab this shell script: http://pastebin.ubuntu.com/116828/
<kirkland> RainCT: save it as /tmp/foo.sh, chmod it 755
<kirkland> RainCT: edit your ~/.screenrc-windows file
<EagleScreen> why you dont want it? if can know it..
<kirkland> RainCT: replace the watch command with just /tmp/foo.sh
<kirkland> RainCT: and launch screen
<nijaba> RainCT: is this right after resizing the window?  If so, I believe it is a newt problem, and I have no clue how to fix it
<RainCT> nijaba: yep
<cjwatson> EagleScreen: because the menu package causes you to get the additional "Debian" menu
<cjwatson> hmm, or at least used to
<cjwatson> maybe it doesn't any more
<nijaba> RainCT: an it is not specific to terminator, it will do the same everywhere.
<EagleScreen> oh!, but i havent the Debian menu in KDE 4.2 and i have menu installed, is it happening only in Gnome?
<cjwatson> "used to"
<cjwatson> doesn't seem to happen in GNOME nowadays
<cjwatson> it really would be preferable to have su-to-root in a separate package though
<RainCT> nijaba: yep, I've just updated the bug's description..
<cjwatson> menu has historically had "interesting" effects
<RainCT> kirkland: works fine
<kirkland> RainCT: cool, i'll upload the fix
<cjwatson> EagleScreen: anyway, I wasn't saying usb-creator must use gksu, just that at the time it was broken without it, so I don't want to spend lots of time on this discussion
<kirkland> RainCT: note that you'll need to remove (or prune) ~/.screenrc-windows
<EagleScreen> I think applications like usb-creator shuldn't depend on gksu becouse it cause installation of unecessary Gnome packages in KDE
<RainCT> kirkland: Okay. By the way, what's the key combination to end screen?
<kirkland> RainCT: F6 will detach, but leave your stuff still running
<cjwatson> EagleScreen: sure
<kirkland> RainCT: F8 will show you all key bindings
<cjwatson> EagleScreen: (note that ubiquity manages this without su-to-root, albeit with more hacks)
<kirkland> RainCT: if you want to exit and kill all programs/windows, you want "pow_detach  D"
<EagleScreen> may be i will report a bug, I understand that you probably have more important things to do
<kirkland> RainCT: so ctrl-a-D
<cjwatson>   * Apply patch from Colin Watson to su-to-root. Closes: #103879
<cjwatson> gosh, I have no memory of that
<cjwatson> EagleScreen: please do, usb-creator isn't my program
<EagleScreen> okay, thanks, see you later
<cjwatson> ah, I don't remember that patch because it was miscredited to me and I never noticed ;-)
<RainCT> kirkland: that just detaches it
<jpds> RainCT: exit, or Ctrl-D
<apw> bryce, did the 'switching away to VT looks like the computer is on acid' bug fixes get uploaded?  got a bug reference?
<RainCT> jpds: that only closes the terminal, there's still the menu (and right now the MOTD).. talking about screen with screen-profiles
<RainCT> kirkland: anyway, thanks for fixing that :)
<Keybuk> pitti: you mean readahead, not bootchart, don't you?
<soren> Keybuk: He did.
<soren> 12:13:42 < ~pitti> erm, s/bootchart/readahead/
<Keybuk> pitti: I thought that gdm had its own readahead list
<Keybuk> which it ran internally?
<pitti> Keybuk: yes, readahead
<pitti> Keybuk: it does, but it doesn't seem to be very effective
<pitti> geser: there's still a data corruption bug open, although this might have been fixed with 2.6.28-7
<pitti> geser: for now, I only use it on /, not /home, so that errors become visible, but aren't disastrous
<Keybuk> pitti: the problem with doing it in a single phase is that you're then reading a *lot* of data into the page cache
<Keybuk> usually more than the available memory
<pitti> Keybuk: right, soren pointed that out already
<Keybuk> isn't it simply that the gdm lists are out of date?
<pitti> Keybuk: but I wondered whether it should/could be put into /etc/readahead/desktop instead of boot?
<Keybuk> that file is only used if /usr is on a separate filesystem
<Keybuk> and contains things from the mainline boot
<Keybuk> (it's poorly named)
<pitti> ok
<pitti> Keybuk: another question I had is why the readline init script blocks instead of putting it into the background and give it a sleep 3 headstart?
<Keybuk> because that is faster
<pitti> curious
<Keybuk> you don't have SSD
<Keybuk> with spinning disks, you're attempting to minimise seek time
<Keybuk> running it in the background would mean the disk was attempting to do the readahead
<Keybuk> while also attempting to do writes, etc. required by other things during boot
<Keybuk> so you're defeating your own attempt
<Keybuk> with SSD, you're simply attempting to eliminate I/O wait
<Keybuk> SSD you tend to order the list differently too
<Keybuk> rotary you order by on-disk position
<Keybuk> SSD you order by required time in the boot
<RoyK> hi. where does ubuntu get the weather data shown in the status line?
<maxb> What datasource does people.ubuntu.com/~ubuntu-archive/madison.cgi use? It appears to be out of date.
<cjwatson> it's a mirror synced every six hours
<cjwatson> how out of date?
<maxb> only 3 hours, so never mind then
<PecisDarbs> pitti: can I talk to you about https://bugs.edge.launchpad.net/ubuntu/+source/jockey/+bug/295158? :)
<ubottu> Ubuntu bug 295158 in jockey "Jockey doesn't find Si3054 Modem (winmodem trough ALSA)" [Medium,Triaged]
<superm1> lool, okay well that question was mostly posed as a naming convention that you could agree on.  surely the split has to happen for that bug to be solved.  i'm guessing python-wnck and python-rsvg etc.  i'll make them dependencies of python-gnome2-desktop then too so in ubuntu packages should still be able to depend on python-gnome2-desktop if they so pleased in ubuntu until this type of change could float into debian
<seb128> superm1: what is the bug you are speaking about?
<seb128> superm1: you want to do yet another gnome-python binary split?
<superm1> seb128, that was the idea, but i'm talking to evand about this right now, so perhaps we'll be able to avoid it
<superm1> evand indicated he'll rework it to use png instead so ubiquity doesn't need rsvg, so that bug is a moot point for this purpose then
<EagleScreen> hello, a few time ago I was "talking" here about the problem of some packages that depends on gksu, causing them to install unnecessary Gnome packages in KDE, it is necessary an alternative autentication method to avoid this problem
<pochu> superm1: if you plan to split gnome-python-desktop, the work has already been done in the Debian svn repo
<pochu> superm1: cf http://svn.debian.org/viewsvn/pkg-gnome/desktop/experimental/gnome-python-desktop/debian/control.in?rev=18217&view=markup
<superm1> pochu, well i'd like to avoid having to do it at the ubuntu level before debian, and it's looking to be a lower priority now because ubiquity won't need it soon and be breaking xubuntu and mythbuntu anymore
<Riddell> EagleScreen: this seems to be something that concerns you :)
<Riddell> EagleScreen: you could work out what's wrong with su-to-root that people don't like and fix that
<EagleScreen> I have three ideas: 1) is to use su-to-root, but it is in universe, and is not a good idea packages in main to depend on packages in universe. 2) is make a .desktop file for KDE and another one for Gnome as synaptic does. 3) is to launch the program from an script that check if gksu or kdesudo is installed and run one of them. For 2) or 3) the package could depends on gksu | kdesudo. What do you think about these alternatives?
<Riddell> EagleScreen: I guess i'd first find out why su-to-root is in universe
<lool> superm1: I'm fine with your proposed changes
<EagleScreen> yes Riddell, i am going to investigate it, any report in Launchpad?
<Riddell> EagleScreen: no idea I'm afraid
<superm1> pochu, has that change not been uploaded in debian because of the lenny freeze?
<superm1> pochu, even though this behavior is getting changed in ubiquity, perhaps it's still worthwhile to pull that change as it looks beneficial anyhow
<Chipzz> EagleScreen: as suggested, 1) could be solved by getting it promoted to main ;)
<EagleScreen> yes Chipzz, but people say that menu package in which is su-to-root, has some kind of problem
<EagleScreen> C. Watson propose to split menu and su-to-root, may be it is a good idea
<Chipzz> that's what I was going to say next :)
<Chipzz> although I know neither package
<pochu> superm1: it's targetting experimental for now, but it's probably waiting Lenny, I guess
<pochu> superm1: I'm not totally sure as I didn't do the change
<directhex> yay, experimental
<leszek> hi, why is the python-gnome2-desktop package in intrepid creating its own libtool thats used for compiling, when obviously rebuilding the package with this libtool is not working ?
<seb128> leszek: what do you mean creating its own libtool?
<pitti> PecisDarbs: hi
<PecisDarbs> pitti: hi
<pitti> PecisDarbs: the bug for jockey is still open, for detecting it
<leszek> seb128, I mean that it won't use the one installed
<pitti> PecisDarbs: however, it needs to be fixed in sl-modem as well
<seb128> leszek: why should it use it?
<PecisDarbs> pitti: I wanted to do that small change in Jokey and slmodemd init.d script before Jaunty release it's that possible. I can try to write a patch for that init.d, but I don't know where I have to fix it in Jockey
<leszek> seb128, because I get a compile error with this "internal" libtool
<PecisDarbs> pitti: yes, so I wanted to know if I will write a small patch will someone put it there? :)
<pitti> PecisDarbs: if you can get sl-modem fixed, I can transition the same fix to jockey
<leszek> seb128, so I cannot rebuild the package
<seb128> leszek: it built fine on the buildds and on my box, check your installation
<pitti> PecisDarbs: yes, I'm happy to review and sponsor it
<PecisDarbs> pitti: cool, then I will jump on it tonight, thanks :)
<leszek> seb128, ok will check that
<pitti> PecisDarbs: if you have a patch, please subscribe me to the sl-modem bug
<pitti> PecisDarbs: cool, good luck!
<PecisDarbs> ok
<Keybuk> debugging with sudo perl -e 'open FOO, ">/dev/sda"'
<Keybuk> what could possibly go wrong?
<pitti> o_O
<EagleScreen> I can see that su-to-root is just a bash script inside menu package, so it should be extracted easily
<cjwatson> EagleScreen: talk to the Debian maintainer
<cjwatson> this would be better done in a common fashion
<leszek> hmm... I still get a lot of ../libtool: line 824: X--mode=compile: command not found
<leszek>  errors and whole of ther libtool errors, what the hell is going on ?
 * tedg wants a bot that anytime someone mentions "sudo perl" it kicks them from the channel :)
<leszek> seb128, hmm... still get libtool command not found errors, like : ../libtool: line 824: X--mode=compile: command not found
<seb128> leszek: run autoreconf, you are running autotools incorrectly
<james_w> leszek: you need to autoreconf the source to remove those
<leszek> ah ok
<seb128> leszek: why do you rebuild the package btw?
<leszek> I patched libwnck for vertical panel, but need to patch python-gnome2-desktop to have this functionality in python also
<seb128> what is different in the vertical case?
<leszek> the wnck.Tasklist is not growing horizontaly but verticaly or should grow this way
<leszek> its a libwnck bug known also from the gnome-panel ;)
<leszek> seb128, here is the patch that I found for libwnck : http://bugzilla.gnome.org/attachment.cgi?id=124112
<leszek> would be nice to have this patch somehow build in :P
<seb128> what is the bug number?
<seb128> that change seems to not be correct
<leszek> GNOME Bug 86382.
<ubottu> Gnome bug 86382 in window list "Fix window list on vertical panels (with possible rotation)" [Major,New] http://bugzilla.gnome.org/show_bug.cgi?id=86382
<bryce> apw, yep #325781
<apw> bug #325781
<ubottu> Launchpad bug 325781 in xserver-xorg-video-intel "[jaunty] [i855] screen corruption when switching resolution / clone mode does not work" [Unknown,Confirmed] https://launchpad.net/bugs/325781
<apw> bryce, ta, seems that the new ones have appeared in my updates list since this morning, which is when i saw it
<apw> will download and test those
<ogra> ogra@osiris:~/Desktop$ du -hcs /var/log/bootchart
<ogra> 37M	/var/log/bootchart
<ogra> hmm
<ogra> we should probably start considering adding /var/log/bootchart to logrotate
<ogra> i totally forgot i had it installed ...
<apw> what time are the iso's made UTC ?
<cjwatson> apw: depends which ones you mean
<cjwatson> there is a crontab with various times for various images
<cjwatson> apw: http://paste.ubuntu.com/116916/
<LaserJock> anybody know offhand how I could figure out for somebody what they need to download to get working nvidia drivers?
<LaserJock> seems like a "you need to get the following .debs" would be helpful
<bryce> asac: http://wiki.x.org/wiki/RadeonProgram
<lool> mvo: Hmm I've lost all my keybindings over the compiz upgrades (not sure which); it seems this is now handled by a new plugin which isn't enabled and didn't have my config anyway
<mvo> lool: could you plesae check if you have the gnomecompat plugin enabled?
<lool> mvo: I do not
<mvo> lool: hrm, thanks!
<mvo> lool: I check why its not, it should be :)
<tseliot> LaserJock: nvidia-glx-VERSION and its dependencies and the linux-headers should be enough
<lool> mvo: Enabling it didn't get the keybindings back either
<LaserJock> tseliot: ok, cool
<lool> mvo: BTW over time it seemed to me compiz switched from .ini to gconf and back, I'm not sure what it is using now
<asac> bryce: nice. though my R580 isnt in that table at atll
<lool> At some point, I was tired of it and wrote a python script to write my settings via the python bindings, but even these broke
<mvo> lool: urghs, can we talk/debug it in a bit? I need to run for some errands
<lool> mvo: Hmm sure
<lool> The backend switches were a while ago, and I saw these in Debian as well
<mvo> lool: I added a patch that should prevent it, could you please check if you got the latest libcompizconfig apckage too?
<bryce> asac, sauerbraten works pretty good on my card; 120 fps
<cjwatson> dholbach: so, um, given that TeamReports is still apparently preparing the January report, should I just create a February page as well?
<dholbach> cjwatson: oh, I can do it well, sorry
<asac> bryce: ok finally i will check that too now ;)
<LaserJock> tseliot: do you happen to know if dkms is installed by default on Intrepid?
<asac> bryce: but for you compiz works too ... so.
<cjwatson> don't mind doing it, just wasn't sure whether it was supposed to go into January until it's finalised or something
<lool> mvo: I have 0.7.8-0ubuntu3 which seems the latest
<tseliot> LaserJock: I'm not sure. superm1 should know it though
<dholbach> cjwatson: done: https://wiki.ubuntu.com/TeamReports/February2009
<cjwatson> thanks
<ogra> is my screen supposed to have a black wallpaper after login with the lastest upgrades or is that a bug
<ogra> (i mean after gdm and before nautilus draws the desktop)
<ogra> pitti, hmm, sad i hoped my X would behave better when you said yours works ... but i still have hangs switching virtual desktops in compiz
<cjwatson> dholbach: do I just delete the "Team Name" blocks upon adding something?
<cjwatson> actually, never mind, not relevant since I'm adding a TB meeting note
<dholbach> yeah, sounds good
<Keybuk> quest udev% ls -l /dev/disk/by-uuid | grep sdc1
<Keybuk> lrwxrwxrwx 1 root root 10 2009-02-11 17:10 CD55-342D -> ../../sdc1
<Keybuk> quest udev% sudo mke2fs /dev/sdc1 > /dev/null
<Keybuk> mke2fs 1.41.3 (12-Oct-2008)
<Keybuk> quest udev% ls -l /dev/disk/by-uuid | grep sdc1
<Keybuk> lrwxrwxrwx 1 root root 10 2009-02-11 17:12 96aa3c56-00dc-4dfa-96e1-91ebe5689e33 -> ../../sdc1
<Keybuk> \o/
<kees> mvo, bdmurray: is there a general wiki landing page to help people with all the various package management errors they can hit?
<jdong> Keybuk: am I interpreting that as by-uuid dynamically updates?
<Keybuk> jdong: yes
<jdong> neato!
<superm1> LaserJock, it's only installed if you have a driver that needs it such as nvidia or fglrx
<LaserJock> superm1: heh, ok
<LaserJock> this poor friend of mine has no internet and lives 1000 miles away
<highvoltage> :(
<superm1> oh that makes life more difficult doesn't it.
<superm1> LaserJock, they're on ubuntu DVD media too
<LaserJock> superm1: well, I tried to find a DVD briefly but I couldn't find one for Intrepid
<LaserJock> and he can't download a DVD .iso obviously
<LaserJock> I sent him an openSUSE DVD to see if maybe he can get *something* going
<LaserJock> poor guy has been trying to get linux working for a couple months now
<superm1> well how are you going to get him a set of debs in the first place then?
<LaserJock> .debs he can download from my brother
<LaserJock> but my brother tried to download an Ubuntu DVD but it was too much
<cjwatson> LaserJock: http://cdimage.ubuntu.com/releases/intrepid/release/
<LaserJock> cjwatson: darn it, I shoulda looked there. I was looking on releases.ubuntu.com
<highvoltage> LaserJock: where I live bandwidth is very expensive, so I download the ubuntu archives and distribute it on DVD. perhaps you could do the same and send it to them to distribute
<LaserJock> I just had a couple minutes to look for it so I could hand it off to some people
<LaserJock> highvoltage: you do just Main?
<LaserJock> it's just amazing how difficult this can be for people even in the US :-)
<LaserJock> I've gotten so used to great bandwith
<jdong> is there an effective/intuitive way of downloading a package and all its dependencies suitable for burning on a CD?
<LaserJock> well, aptoncd might work
<jdong> I had a script that starts with like a pbuilder environment and grabs the packageset that it tries to download
<LaserJock> but part of my problem is just getting the guy up-and-running so he can learn how to use Linux at all
<highvoltage> LaserJock: I do main universe multiverse and restricted for i386. it's about 22GB for intrepid
<Turl> hi there, can you take a look at https://bugs.launchpad.net/ubuntu/+bug/328156 ?
<ubottu> Ubuntu bug 328156 in ubuntu "There is a big delay between logging in in GDM and getting the desktop fully loaded" [Undecided,New]
<highvoltage> LaserJock: heh well, over here all of us think that everyone in the US has at least uncapped 20mbit connections
<LaserJock> I think I'll just mail him the DVD
<LaserJock> it only takes me ~ 45 min to download
<cjwatson> jdong: I'm pretty sure there's a document on this in the apt-doc package
<cjwatson> /usr/share/doc/apt-doc/offline.html/index.html
<calc_> highvoltage: heh, US has crap broadband, Korea is where its at ;-)
<calc_> i'm hoping to get 10/1.5 on friday upgraded from my previous max of 3.0/0.5
<LaserJock> calc_: US can have crap connectivity period, my parents have a nice speedy 28.8k dialup ;-)
<calc_> highvoltage: aiui in korea and japan you can get gigabit to your home fairly cheap
<highvoltage> calc_: wow
<calc_> highvoltage: persia has gigabit aiui
<calc_> what does a blue (@) mean in the new screen theme?
<Turl> anyone please? https://bugs.launchpad.net/ubuntu/+bug/328156
<tedg> calc_: run!!!!
<ubottu> Ubuntu bug 328156 in ubuntu "There is a big delay between logging in in GDM and getting the desktop fully loaded" [Undecided,New]
<calc_> tedg: heh
<kees> james_w: in BzrBuildPackage, you have --builder defaulting to "dpkg-buildpackage -rfakeroot -uc -us".  shouldn't this be "debuild -uc -us" given Ubuntu's compiler flag default settings that doko built into debuild?
<LaserJock> calc: if it starts blinking faster and faster cut the red wire
 * calc finally gets to go back home in the morning, back to nice 25C weather, no more snow and ice on the ground, heh
<james_w> kees: yes, it probably should, I've been meaning to change it, but never quite got around to it
<doko> kees: these are built into dpkg-buildpackage
<james_w> kees: I think I'll just make it "debuild"
<kees> doko: oh, you moved them into dpkg-buildpackage?
<kees> doko: when did that happen?
<doko> kees: hmm, I never moved them ...
 * kees scratches his head.  memory fail.  :P
<calc> kees: thats what happens when you get old ;-)
<kees> :P
<jdong> cjwatson: thanks! (apt-doc pointer)
<kees> james_w: is there a work-flow documented anywhere for the steps to take to do the bzr-style work?  i.e.  "bzr bd -w" *repeat* "debcommit" "debcommit -r" "bzr bd" *upload* etc?
<james_w> that pretty much sums it up :-)
<kees> I'm not clear on what goes into the change between the debcommit and the debcommit -r (without manually doint a bzr ci --unchanged -m 'releasing...')
<james_w> (-w is un-needed now btw)
<kees> why?
<james_w> it's the default
<kees> ah! heh, okay
<james_w> https://wiki.ubuntu.com/DistributedDevelopment/Documentation
<james_w> that's where I'm doing the documentation currently
<cjwatson> kees: people who know about it generally put DEBCHANGE_RELEASE_HEURISTIC=changelog in ~/.devscripts, after which your last change before releasing is dch -r (which changes UNRELEASED to jaunty at the top of debian/changelog, and updates the timestamp)
<kees> okay, cool.  back-links from BzrBuildPackage would be nice.  :)
<cjwatson> much friendlier to revision control
<kees> cjwatson: ah! that's the missing piece for me.
 * LaserJock wishes we could put cjwatson's brain on paper :-)
<Keybuk> cjwatson: the comments on bug #85014 may amuse ;)
<ubottu> Launchpad bug 85014 in upstart "Fail to enter rc1.d by putting 1 in bootparam in edgy" [Low,Triaged] https://launchpad.net/bugs/85014
<kees> cjwatson, james_w: is there a tool that does the s/UNRELEASED/jaunty/ on the change log, or is that bit manual?
<james_w> dch -r
<cjwatson> Keybuk: what a mess
<cjwatson> especially from somebody using the royal we
<kees> james_w: okay, perfect, so process is:   *setup* (*hack* ("bzr bd", test)*repeat* debcommit)*repeat* "dch -r" "debcommit -r" *upload*
<Keybuk> cjwatson: it's not as if I even closed the bug won't fix ;)
<kees> seems almost like "debcommit -r" should run "dch -r"
<cjwatson> I'd find it surprising if debcommit changed the working tree
<jpds> Keybuk: Looking at his related bugs... I'd say he likes to write essays for responses.
<cjwatson> what's that stuff about jigdo being broken? I assume that it's somebody trying to jigdo a point release or something
<cjwatson> (which has never worked)
<kees> cjwatson: oh... you didn't update vte bzr :)
<cjwatson> kees: I did, I asked somebody to pull for me since I'm not in ubuntu-desktop
<cjwatson> kees: lp:~kamion/vte/udeb-fixes I think
<kees> cjwatson: oh! yeah, I'm going to be in the same boat, it seems.
<kees> james_w: exported directories from 'bzr bd' are world-writable.
<james_w> kees: ouch
<james_w> kees: which directory exactly?
<kees> all of them, it seems
<kees> $ ls -lda vte-0.19.4
<kees> drwxrwxrwx 11 kees kees 4096 2009-02-11 10:17 vte-0.19.4/
<kees> $ ls -lda vte-0.19.4/src
<kees> drwxrwxrwx 2 kees kees 4096 2008-12-15 12:45 vte-0.19.4/src/
<kees> i wonder if this is a tarball glitch
<kees> $ tar zvtf vte_0.19.4.orig.tar.gz
<kees> drwxrwxrwx 500/500           0 2008-12-15 12:45 vte-0.19.4/
<kees> oh, so it is.  how intensely strange.
<james_w> the python tarfile module is a little lacking in places, and I know there is some issues with UMASK handling where it differs from tar, perhaps this is another area where it falls short
<kees> tar man says:
<kees>        --no-same-permissions
<kees>               apply umask to extracted files (the default for non-root users)
<kees> so it seems that tar explicitly applies umask when unpacking
<kees> ah, debian bug 470494
<ubottu> Debian bug 470494 in bzr-builddeb "bzr-builddeb: Permissions of unpacked files don't respect umask" [Normal,Open] http://bugs.debian.org/470494
<kees> james_w: until tarfile is fixed, would you consider switching to subprocess.call(['tar',...  ?
<james_w> kees: yes, I would consider it
<james_w> I need to do it to fix bug 303931 as well
<ubottu> Launchpad bug 303931 in bzr-builddeb "Doesn't handle tar extensions" [Medium,Triaged] https://launchpad.net/bugs/303931
<kees> cjwatson: did you just ping seb128, or is there a more formal process to request pulls for a branch?
<kees> (better yet, anyone from the desktop team able to pull cjwatson and my branches for vte?)
<cjwatson> kees: I think I pung mvo
<kees> james_w: this works for external tar usage (and likely solves your other bug too):  lp:~kees/bzr-builddeb/external-tar
<kees> tedg: around?  can you merge two branches of vte for me and cjwatson?
<tedg> kees: Me?
<kees> tedg: yawp
<kees> tedg: you're in the ubuntu-desktop group
<tedg> Heh, yeah, but considering I'm not on that team I'd feel a little odd about editing their branches.
<tedg> bryce: ^
<kees> tedg: you're the only one in the timezone.  :)  and bryce isn't on the member list for some reason.
<cjwatson> FWIW I already uploaded my branch to the archive with consent from other folks involved
<tedg> kees: Heh, okay.
<cjwatson> so pulling it would just reflect reality
<kees> I didn't really have consent exactly, but I just did a patch update to match the current upstream tracker.
<tedg> kees: cjwatson: what are the branches?
<kees> tedg: lp:~kamion/vte/udeb-fixes and lp:~kees/vte/bolding-update
<cjwatson> into lp:~ubuntu-desktop/vte/ubuntu
<cjwatson> you should just be able to pull the former; don't know if you'd need to merge or pull the latter
<james_w> thanks kees
<kees> james_w: np
<tedg> kees: You just had to go and use a tag didn't you... now upgrading the branch format to support tags...  :)
<kees> tedg: d'oh, sorry, it's part of the process I was trying to follow.  :P
<tedg> kees: No problem.  No stack dumps on bazaar this time, so I'm a happy bazaar user today :)
<tedg> kees: cjwatson: pushed.
 * kees hugs tedg
<bgamari> Has anyone put together Python 2.6 packages for Intrepid yet?
<bgamari> According to bug #278230, it was supposed to be released in a PPA after release?
<ubottu> Launchpad bug 278230 in python-defaults "Python 2.6 for Intrepid" [Wishlist,Won't fix] https://launchpad.net/bugs/278230
<btQuark> any idea if the synaptics-usb kernel driver is to be supported any time soon?
<btQuark> i've created a ticket on some of the ubuntu trackers (brainstorm imho) but did not get any responses
<btQuark> actually the drivers seems to work well, but is in conflict with the hid-drivers
<btQuark> and needed to use the synaptics x driver with any synaptics device connected via usb
<btQuark> provided by jan-steinhoff.de
<btQuark> it would be most lovely it that would work :D
<RoyK> hi. where does ubuntu get the weather data shown in the status line?
<ogra> it asks the little frog builtin to your CPU
<btQuark> rofl
<quadrispro> lol
<RainCT> XDD
<bryce> ogra: you're saying your CPU croaked?
<ogra> yeah, but mine already has T.O.A.D 2.0 builtin :)
<ogra> waay advanced :)
<ScottK> Based on calc's feedback on weather, I thought it was anywhere it doesn't matter because you don't know where you live anyway.
<ogra> ScottK, well, actually it polls airport data ... prob is if you dont live near an airpirt you have no weather ...
<jpds> RoyK: It uses libgweather.
<mvo> kees: what branch do you want me to merge? happy to do that
<RoyK> jpds: any idea what weather source that uses?
<ogra> RoyK, airport data
<jpds> RoyK: According the source, various sources, but you might have better luck looking around: http://svn.gnome.org/viewvc/libgweather/trunk/
<ogra> try: firefox file:///usr/share/libgweather/Locations.xml
<ogra> that gives you a list of all known locations mapped to the airport
<RoyK> why on earth would people write XML files in one line?
<ogra> RoyK, because it saves whitespace ... (i agree its silly, but it might save a byte or so and usually xml is interpreted)
<ogra> thats why i pointed you to firefox ;)
<RoyK> I didn't see that - just opened it with vi
<RoyK> still doesn't say anything about the source used
<RoyK> hm. that svn repo doesn't work
<ogra> RoyK, it uses the NWS servers
<RoyK> ogra: ok
<RoyK> ogra: are their data available freely_
<RoyK> ?
<ogra> apparently
<ogra> i know many IRC bots using it
<RoyK> ok
<RoyK> met.no, the Norwegian counterpart just opened all their data recently - with lots of details down to weather reports for small towns with 500 people and so on
<RoyK> worldwide as well
<RoyK> a few companies have been a little pissed off by them for that :)
<RoyK> see yr.no for the main site
<ogra> i guess you could patch gweathr to use other servers
<LaserJock> I just leave the lab once in a while and look outside :-)
<ogra> LaserJock, pfft, thats cheating ... thats like taking to your wife across the table while you could IM her
<ogra> *talking
<RoyK> lol
<LaserJock> ogra: yeah, I suppose it is
<LaserJock> I need to figure out a nice avahi Valentines Day gift
<ogra> *grin*
<LaserJock> maybe just ssh in to her laptop and change the background to a vase of roses?
<LaserJock> much cheaper :-)
<ogra> lol
<mathiaz> If a package (mysql-server-5.1) declares a conflict with another one (mysql-server-5.0) but *no* replaces what should apt-get install mysql-server-5.1 do on a system with mysql-server-5.0 installed?
<mathiaz> apt-get shows that mysql-server-5.0 will be removed and mysql-server-5.1 installed.
<mathiaz> isn't a conflict supposed to prevent that?
<cpufreak> a conflict means they can't both be installed at the same time.
<mathiaz> shouldn't apt-get refuse to install mysql-server-5.1 rather than remove mysql-server-5.0 and installing mysql-server-5.1?
<LaserJock> mathiaz: hmm, is it perhaps guessing since you've explicitly said you wanted to install mysql-server-5.1 that mysql-server-5.0 is "lower priority"?
<LaserJock> so "I want to install" is higher priority than "already installed"
<mathiaz> LaserJock: hm. may be. What I want to achieve is that if mysql-server-5.0 is installed you cannot install mysql-server-5.1 (which would be an upgrade from mysql point of view)
<mathiaz> LaserJock: if there isn't any replaces then the install fails because /usr/bin/mysqld is both in -5.0 and 5.1
<LaserJock> mathiaz: well, I think the Conflicts system just says "you can't have both"
<mathiaz> According to the debian policy (http://www.debian.org/doc/debian-policy/ch-relationships.html - 7.4 Conflicting binary packages - Conflicts): if the package being installed is marked as replacing [...] then dpkg will automatically remove the package which is causing the conflict, otherwise it will halt the installation of the new package with an error
<mathiaz> in this use case mysql-server-5.1 does *not* replace mysql-server-5.0
<mathiaz> it only conflicts with mysql-server-5.0
<LaserJock> right
<LaserJock> so is there a problem with people installing -5.1?
<Laney> that talks about dpkg
<Laney> apt must be being more clever than that
<mathiaz> LaserJock: a fresh install of 5.1 works
<mathiaz> LaserJock: however if you have 5.0 installed you'd better not install 5.1
<LaserJock> mathiaz: why not?
<mathiaz> LaserJock: even though 5.0 and 5.1 are considered two different src packages they share data
<LaserJock> but Conflicts makes sure you don't have both
<mathiaz> LaserJock: so installing 5.1 tries to setup a brand new install
<mathiaz> LaserJock: while there is already one running for 5.0
<mathiaz> LaserJock: there isn't any proper upgrade logic in 5.1 to handle an upgrade from 5.0
<mathiaz> LaserJock: and I don't plan to get this done in jaunty
<LaserJock> that sounds kind of like a different kind of problem though
<mathiaz> LaserJock: so I want to make sure that people can't install 5.1 if they have 5.0 already there
<LaserJock> does Replaces work?
<LaserJock> will that remove 5.0 first?
<mathiaz> LaserJock: yes - even *without* Replaces 5.0 is removed
<mathiaz> LaserJock: yes - even *without* Replaces, 5.0 is removed
<kirkland`> any idea why a fresh install of Jaunty desktop would leave me with really huge, strange looking fonts?
<maxb> dpi issue - System > Preferences > Appearance > Fonts > Details... > override DPI to 96 and see if it looks sane again
<beuno> pitti, FWIW, some update today fixed the black-screen-on-startup issue for me
<cjwatson> tedg: vte> thanks
<cjwatson> bgamari: "deb http://ppa.launchpad.net/doko/ppa/ubuntu jaunty main" - no extensions yet, though, so it may not be very useful in many cases. It's planned to go into Jaunty over the next few days though
<cjwatson> mathiaz: there is no way, period, for a package to say that it may not be removed in favour of another package
<bgamari> cjwatson, alright, I just installed jaunty
<cjwatson> mathiaz: Conflicts says that they can't be installed simultaneously, and Conflicts+Replaces says "can't be installed simultaneously, also this one is better than that other one so use it if you can't decide"
<bgamari> cjwatson, It will still be a few days though?
<cjwatson> bgamari: yes
<cjwatson> mathiaz: if this is a problem, maybe having upgrade logic in 5.1 *needs* to be on your (plural) list for jaunty ...
<bgamari> cjwatson, alright, thanks
<cjwatson> mathiaz: or else fail in 5.1's preinst, but that will cause confusion for users
<mathiaz> cjwatson: ok - I'll see how complicated the upgrade logic would be. The backup plan is to fail in preinst
<cjwatson> BTW, the reason that Conflicts+Replaces has a special meaning distinct from Replaces is not entirely obvious (or at least wasn't to me) but is quite simple
<cjwatson> the reason is that Replaces talks about what happens when two packages are installed simultaneously but share files
<cjwatson> but Conflicts ensures that the two packages cannot both have their files unpacked
<cjwatson> so when Conflicts is used, Conflicts+Replaces is free for another bit of information
<cjwatson> there are a lot of places in the archive where people use Conflicts+Replaces but meant to use just Replaces; this is partly because until a couple of years ago dpkg didn't handle Replaces on its own quite right, so people used Conflicts+Replaces to force the issue
<LaserJock> hmm, I'm really getting to think cjwatson > Policy :-)
<Keybuk> cjwatson: random of the day
<Keybuk> do we have to include Canonical's own copyright in debian/copyright for upstream packages we patch? :)
<nhandler> cjwatson: You really should add that to some FAQ on the wiki (if it exists). That is a pretty common question that many people have. It would be great to be able to point them to a wiki page instead of trying to explain it each time
<cjwatson> LaserJock: Policy says this, it's just a bit vague about it
<cjwatson> nhandler: actually, I'd rather expand it in the policy manual
<cjwatson> it's silly to have a document, and then a clarification document
<nhandler> cjwatson: That would work too ;)
<cjwatson> Keybuk: depends how significant and original our changes are, I suppose
<cjwatson> I thought we had some kind of document about this, but can't find it
<Keybuk> cjwatson: well, our copyright line is in the upstream .c file
<cjwatson> Keybuk: technically speaking it probably ought to be acknowledged in debian/copyright; this should all be a bit more rational with the new copyright format, I think
<Keybuk> there's a new copyright format?
<cjwatson> http://wiki.debian.org/Proposals/CopyrightFormat
<Keybuk> let me guess, rfc822 files?
<cjwatson> what else?
<LaserJock> copyrightkit
<ion_> laserjock: :-D
<cjwatson> usual caveats about design-by-wiki-committee, but the guts of the proposal are pretty good
<Keybuk> that is a massive document
<cjwatson> it is, but most of it is devoted to enumerating machine-readable names for individual licences
<cjwatson> it's got a bit out of hand in the last few months and needs to be taken off the wiki and trimmed down by a maintainer
<cjwatson> looks like there's consensus among the active editors that that needs to happen, so it should happen post-lenny
<cjwatson> ... i.e. next week
<cjwatson> Keybuk: /usr/share/doc/base-passwd/copyright is my interpretation of what the results would actually look like, although it's written to a somewhat older version
<cjwatson> oh, the proposal also has lots of inline comments, further increasing massiveness
<Keybuk> doesn't that just make the whole thing overly complicated?
<Keybuk> previously I just amalgamated all the various copyright lines into one bloce
<Keybuk> now every time every single file has a slightly different copyright line, you need to list it separately?
<cjwatson> Files: *
<cjwatson> I think you could perfectly well get away with smoothing over trivial differences
<Keybuk> is that allowed?
<Keybuk> in your example, you list different files in different blocks just because they have different copyright, but the same licence
<cjwatson> only because they had completely different heritage
<cjwatson> the copyright dates on the .c file and the man pages are probably not identical, for instance
<cjwatson> I think stating the union is fine
<directhex> cjwatson, copyrightformat needs a sensible way to document +dfsging source
<cjwatson> if it were very fiddly I'm pretty sure I would just list all the copyright holders in Files: src/* or whatever
<cjwatson> same as upstream probably does in AUTHORS
<cjwatson> directhex: why isn't that in debian/README.source, which documents other unusual source handling practices?
<cjwatson> directhex: although if you search for "orig" in the proposal you'll find a comment about this
<directhex> cjwatson, it is. it just seems opportune to have a machine-readable list of +dfsg changes, if you're having a machine-readable list of other things
<cjwatson> anyway, given a vaguely sane editor and marginally less wikibikesheddery I think it should be OK
<directhex> we've been using it for a while in pkg-monofoo, but it's definitely changed at least once between when we started using it & now
<cjwatson> yes
<cjwatson> I certainly don't think it's ready yet, although I've started using it with a nominated revision in some of my packages for practice
<cjwatson> among other things, GPLv3 taught us that we need some kind of automated way to track this stuff
<directhex> if nothing else, something approximating the copyright format is *MUCH* nicer for *HUMAN* readability than a wooly "well, it's a bit o' this and some o' this"
<RAOF> I also like the structure; I find it makes it easier for me to do the initial copyright search and to update stuff.
<directhex> and a dash o' that
<directhex> RAOF, updating copyright seems to never ever happen
<cjwatson> rarely, at least. I do try to remember on new upstream versions
<cjwatson> but particularly when it's just a year update, people forget
 * RAOF checks his copyright on new upstreams fairly conciensiously.
<directhex> i've been bitten by people not updating their copyright when trying to re-use some of their content
<RAOF> Right.  Hello, tomboy keybinding code!
<cjwatson> copyright is important to acknowledge, but we're unlikely to be breaking any laws by leaving a holder out of debian/copyright (it'll be documented in the files themselves anyway)
<cjwatson> whereas licences are actually important to track
<cjwatson> and also change rather more rarely and with more fanfare, so are a bit easier to pay attention to
<directhex> cjwatson, from where i'm sat i don't care as long as ftpmaster lets it through the gate
<cjwatson> as an Ubuntu ftpmaster, I care :)
<directhex> as an ubuntu ftpmaster, you have a waiting list of less than a month. copyright needs to be pristine first try in debian because if it ain't, then it's to the back of the queue
<LaserJock> does anybody know if the text installer on the DVD runs tasksel at all?
<directhex> and the back of the queue sucks
<cjwatson> directhex: I think it's worth recognising that the Debian FTP team has other things to do with lenny coming on
<cjwatson> s/on$/up/
<cjwatson> and TBH, every time you've mentioned mono in the last month it seems to have gone with a complaint about Debian NEW
<cjwatson> I understand your frustration but ...
<cjwatson> LaserJock: yes
<directhex> cjwatson, i'm a mono packager, what else am i likely to mention?
<cjwatson> it just gets a bit old
<LaserJock> cjwatson: as in, does it offer the user task selections?
<cjwatson> LaserJock: should od
<cjwatson> do
<LaserJock> cjwatson: hmm, ok, I'll give it a go again, I got impatient
<cjwatson> tasksel should offer task selection provided that more than one task is available on the DVD, and it isn't preseeded
<cjwatson> mind you, I guess it might be preseeded
<LaserJock> ah, ok
<cjwatson> yeah, I suppose it is
<cjwatson> does this need to be changed?
<LaserJock> because it was acting just like the regular Ubuntu Alt CD
<LaserJock> well, I was trying to think of ways people could get Edubuntu all in one go
<LaserJock> and since the DVD is the only place were all the needed packages exist, it'd be nice
<cjwatson> it does make some sense to remove that
<LaserJock> also, I used the 8.10 DVD and I didn't see a LTSP install option
<LaserJock> when I hit F4 that is
<cjwatson> that's odd, it looks like it's there
<cjwatson> file a bug about that one
<cjwatson> I suspect that gfxboot-theme-ubuntu is a bit confused about what it's booting
<TheMuso> cjwatson: whats with ports images in http://cdimage.ubuntu.com/daily/current?
<LaserJock> cjwatson: I get Normal, Safe graphics mode, Use driver update CD, OEM install from the F4 menu
<cjwatson> TheMuso: I screwed up
<TheMuso> Ok np, just checking to see if it was known.
<cjwatson> I was doing an image rebuild and accidentally did so from a shell in which I had been doing some script debugging and had some variables exported
<TheMuso> np.
<LaserJock> cjwatson: what should I file a bug against?
<cjwatson> TheMuso: I'll fix it up now, thanks for the reminder
<cjwatson> LaserJock: gfxboot-theme-ubuntu
#ubuntu-devel 2009-02-12
<LaserJock> cjwatson: filed
<TheMuso> Hrm. Even more weird, it seems that the cd images I get from rsync are different to the ones I get via http, or at least thats what the MD5sums suggest.
<cjwatson> cdimage@antimony:~/cdimage/www/full/daily/current$ md5sum -c MD5SUMS
<cjwatson> jaunty-alternate-amd64.iso: OK
<cjwatson> jaunty-alternate-i386.iso: OK
<cjwatson> I've fixed LaserJock's DVD tasksel preseeding thing
<TheMuso> cjwatson: Hrm ok, I'll sync again and th en compare once more.
<TheMuso> Well, there is certainly an inconsistancy somewhere, as I have pulled the MD5sums file via rsync after syncing images from rsync, and an md5sum check still fails.
<TheMuso> No matter, I'll do a netboot install.
<cjwatson> I did just do a sync to mirrors, but it shouldn't have affected image contents or MD5SUMS file contents
<TheMuso> hm ok.
<cjwatson> are we talking about the same images? the above is for the Ubuntu alternate CDs
<TheMuso> Yes I am talking about those as well.
<cjwatson> it might clear up tomorrow once they're auto-built properly ... I hope
<wasabi> odd. getting a lot of kernel dumps since latest kernel in intrepid-updates. That's suprising.
<StevenK> TheMuso: Looks like sparc for linux-ports wants makedumpfile too
<TheMuso> StevenK: Yes, because I forgot to turn it off for sparc.
<StevenK> TheMuso: Ah!
<StevenK> TheMuso: The hppa failure looks damn strange, too
<TheMuso> StevenK: But easily fixable I am pretty sure, not worrying about it now though.
<ScottK> TheMuso: mesa built on powerpc and so did qt4-x11, so it's some real progress.
<ScottK> I'm going to see how far I can get on getting all of KDE built.
<TheMuso> ScottK: Ok, I should have other arches for ports sorted out after work today.
<StevenK> TheMuso: The ia64 failure looked simple-ish, too
<ScottK> Great.
<TheMuso> StevenK: Yeah it is.
<TheMuso> StevenK: I'll be able to get it to build at least.
<TheMuso> Looks like libdrm was also given back
<TheMuso> Or was mesa the only issue?
<ScottK> mesa was the issue.  It couldn't build because libdrm-dev was uninstallable.
<TheMuso> Right.
<ScottK> So due to that it's mesa -> qt4-x11 -> soprano -> and then I can start to build KDE.
<TheMuso> Interesting actually since there is no linux-libc-dev listed for libdrm-dev for ports arches, I am surprised it worked.
<ScottK> It built.  I've got no way to test if it works or not ....
<TheMuso> Right, once I get ports sorted, I'll check for myself,.
<ScottK> So soprano went from estimated build start in 7 hours to currently building started 4 minutes ago in less than 10 minutes ...
<TheMuso> wow
<kees> anyone know of the dash-equivalent to bash's -o pipefail?
<ion_> kees: sh -c '(cat /foo || kill $$) | cat; echo bar' ;-)
<ion_> Not equivalent to pipefail, more like set -e + pipefail
<kees> ion_: hrm...
<kees> ion_:    find /fail | cpio --quiet -o | gzip >/dev/null      I want that to fail...
<ion_> Is (find /fail || kill $$) | cpio | gzip enough?
<kees> nope
<kees> I'm gonna just cheat and use pipefail.  :)
<cjwatson> there really isn't a good portable version of pipefail
<cjwatson> the best you can do is to echo return codes out on some spare file descriptor, and catch them at the top level
<cjwatson> if [ "$( ((find /fail || echo $? >&3) | cpio --quiet -o | gzip >/dev/null) 3>&1 )" ]; then kill myself horribly; fi
<cjwatson> or words to that effect
<cjwatson> but it always ends up being horribly gross and you want to hang yourself with a dangling file descriptor
<cjwatson> I do it occasionally when I have no other choice and usually have to fight redirections for a while before it actually works
<IntuitiveNipple> Which package to file this bug against? Start-up drops to shell when fsck runs because two crypto-volumes haven't been unlocked by cryptdisks-early. They aren't unlocked since the custom script that unlocks them via a key-file is in /usr/local/sbin/, and /usr/local/ is on a separate mount :)
<maxb> Is there any page like SyncRequestProcess but for merges? Or are merges just like any other change following SponsorshipProcess?
<nhandler> maxb: There is https://wiki.ubuntu.com/UbuntuDevelopment/Merging
<ScottK> maxb: On merges.ubuntu.com there's a pointer to the grab-merge.sh script, but once you make the debdiff it's just like any other.
<kees> cjwatson: yikes, that's sick.  any chance we can just use pipefail and bash for mkinitramfs?
<lifeless> cjwatson: how much to stop you pasting shell fragments like that ? :)
<kees> lifeless: ieeee  http://cfaj.freeshell.org/shell/cus-faq-2.html
<lifeless> 4 years without updates
<lifeless> tsk
<kees> no mention of pipefail.  I want to pluck out my eyes after reading the POSIX solution
<lifeless> yay single letter variable names
<calc> jcastro: hmm will look into the dialogs when i get home, there hasn't been any commits regarding KDE 4 dialogs recently
<calc> jcastro: its possible the user just read the release notes and assumed the kde support it talks about is for kde4, heh
<ScottK> calc: There was someone in #kubuntu-devel a few hours ago claimin OOo KDE4 patches, but Riddell looked and they were KDE3.
<ScottK> Dunno if it's the same someone.
<calc> ScottK: yea that is what i was talking about, jcastro sent me the log and i looked and i didn't see anything to indicate there were kde4 patches
<calc> well i'm about to head to the airport, headed home from Hamburg today :)
<LaserJock> calc: did you eat a hamburger there?!
<calc> McD :)
<calc> i ate snitzel most of the time though
<calc> lol
<LaserJock> calc: you went all that way for McDs?
<LaserJock> that's about as bad as highvoltage and I at UDS-Paris
<calc> its very cold outside and McD was the closest restaurant i saw
<StevenK> LaserJock: What did you and highvoltage do at UDS Paris?
<LaserJock> we had Subway across from Notre Dame and a street full of cafes
<calc> well very cold for me anyway, ~ -5 - -10 and snowing most days
<LaserJock> but it was the weirdest Subway I've ever been too, no cheese!
<LaserJock> how do you make a sandwich in Paris of all places without cheese
<LaserJock> so for UDS Sevilla we did Burger King
<StevenK> I ate at Subway in Prague, since it was right by the metro station
<LaserJock> I was so starved in Paris, first time outside the US
<LaserJock> all the French food was pretty weird for my American senses
<ajmitch> LaserJock: you poor fellow
<LaserJock> I really started to think that their kitchen had no ovens/burners
<LaserJock> but the 16 euro ride into Paris proved much more succesful
<StevenK> LaserJock: The food was cold or uncooked?
<LaserJock> uncooked mostly
<LaserJock> raw, thin sliced beef
<LaserJock> with a little lettece and a rock hard roll
<jldugger> haute cuisine indeed!
<LaserJock> I was an interesting experience
<stgraber> LaserJock: sounds expensive :) though usually really good
<LaserJock> jbailey tried 3 times to get a vegan meal at the dinner on the last day
<LaserJock> I think there was bacon in the salad or potatoes
<stgraber> hehe
<LaserJock> must have been the potatoes
<LaserJock> because then there was a honey-mustard dressing for the salad
<LaserJock> it was a lot of fun anyway
<stgraber> you really didn't take the less expensive meal you can find :)
<LaserJock> but I was coming down with monster ubuflu by that time
<calc> so far i didn't get sick this trip, still have 14hr of plane air to survive today though
<stgraber> calc: usually I get sick a day or two after :) worked for all UDSes so far.
<calc> fun
<LaserJock> one of the times I was sick and people were trying to teach me Mao
<LaserJock> baaaaad combo
<StevenK> I bet they weren't, I bet you were playing
<jldugger> you dont teach mao
<ScottK> Sure you do.  It'd just done in an unorthodox manner.
<LaserJock> well, by the end they were so fed up with me there was some definate coaching
<LaserJock> I just couldn't think at all
<jldugger> ScottK: if they're learning, you're doing it wrong
<ScottK> I didn't say what was being taught.
<jldugger> im pretty sure you did
<LaserJock> heh, the first line on the History of Mao on wikipedia says "(This Game is Cruel and Unusual)"
<LaserJock> man, it sure felt it at the time
<ScottK> Heh.
<ScottK> First time I didn't find it cruel and unusual.  I thought it was interesting.
<ScottK> That probably says more about me than the game though.
<LaserJock> yeah, I've just got no patience for games usually
<StevenK> You two need to have Phase 10 inflicted on you
 * calc bbia 18hr probably
<Amaranth> LaserJock: Once time playing with vuntz he made us name a module in GNOME he maintained (in a certain order) every time we changed the suit
<Amaranth> Took like 20 minutes to figure that one out
<lifeless> ScottK: it may say more about who introduced you
<lifeless> ScottK: it can be very collaborative and fun, or plain evil
<ScottK> True.
<LaserJock> lifeless: you might have been involved in my torture
<LaserJock> I remember colin and soren being there
<lifeless> LaserJock: I try very hard to play an entertaining game not a cruel one ;)
<LaserJock> oh, I'm sure it was entertaining ... :-)
<Amaranth> I was playing with plain evil guys
<Amaranth> I think they were all GNOME devs
<dholbach> good morning
<pitti> Good morning
<ion_> ing
<doko> hurray for the new autoconf \o/
<StevenK> doko: That is so the first time I've seen someone proclaiming "hurray for autoconf"
<doko> just sarcastic about the gcc build failures
<StevenK> Haha. Okay, sarcasm makes it better. :-)
<ion_> Such a phrase is inevitably either sarcasm or evidence of a psychosis.
<StevenK> It's *doko*, so it's both
<Koon> pitti: Archive question : I have three new packages to import from debian to universe, one is in sync and the other two require a small diff. What's the best way to proceed ? Ask you for the sync and upload the merges myself ?
<Koon> hm. in fact it's just two packages. The last one is just a merge of an existing one.
<persia> Koon, The typical answer to such questions is: request the syncs and upload the merges (once build-dependencies are published).
<Koon> persia: thx.
<dholbach> doko: are you going to work on python today? might be worth checking out bug 324708
<ubottu> Error: Could not parse data returned by Launchpad: timed out (https://launchpad.net/bugs/324708/+text)
<dholbach> bug 324708
<ubottu> Error: Could not parse data returned by Launchpad: timed out (https://launchpad.net/bugs/324708/+text)
<doko> dholbach: not python2.5
<dholbach> ok
<savvas> is the mount type ntfs using ntfs-3g driver?
<oskar-> hi, who is the right one to address with a question regarding NM and wpa_supplicant?
<cjwatson> kees: I think it'd be fine to use bash for mkinitramfs as long as you don't try to use it for the initramfs itself :-)
<cjwatson> savvas: ntfs-3g> yes
<cjwatson> oskar-: asac
<savvas> thanks :)
<primes2h> pitti: Hi, BTW did you have a look at the patch for this bug #172353 ?
<ubottu> Launchpad bug 172353 in human-icon-theme "Human theme has non-translatable emblem names." [Low,Fix released] https://launchpad.net/bugs/172353
<oskar-> asac, is there a way provided to tell NM which configuration options to pass to wpa_supplicant (for example "fast_reauth=0")?
<asac> oskar-: not that i know.
<ogra> cjwatson, wrt compcache, i saw some users in ubuntu-users@ for which the compcache initrmfs hook seems to persist in the installed system, can we make ubiquitey care that it goes away after install ?
<oskar-> thanks
<cjwatson> ogra: if it fails to go away, then I think something has already gone wrong in ubiquity - i.e. casper has failed to be removed
 * ogra glares at hs fingers ... need some type training again :P
<cjwatson> ogra: in other words, ubiquity is already trying to make sure of this
<ogra> hmm, intresting
<cjwatson> it's possible for the installer to crash before removing casper, though, and for the user to think "oh well, I'll try rebooting anyway"
<ogra> right
<cjwatson> ogra: the hook itself should still be there, of course, since it's in initramfs-tools, just not its configuration
<ogra> well, the hook wont create the script if COMPCACHE_SIZE isnt set
<ogra> which isnt the case by default ... the user definately has a conf.d file left behind
 * ogra looks up the mail
<ogra> https://lists.ubuntu.com/archives/ubuntu-users/2009-February/174405.html
<directhex> which virtualization system do the ubuntu buildds use?
<Mithrandir> directhex: xen, I believe.
<StevenK> The distro buildds are bare-metal, the PPAs are Xen
<directhex> gotchA
<StevenK> directhex: Are Mono assemblies arch independant?
<cjwatson> ogra: unless the initramfs is created in /target before removing packages, I guess
<cjwatson> which is possible ...
<ogra> oh, really ?
<cjwatson> blast. Yes, it is.
 * ogra wasnt aware ubiquity installs the kernel separately 
<directhex> StevenK, in most cases, yes. there are exceptions when badly marshalling arch-specific libraries using arch-specific type lengths
<cjwatson> err, it doesn't
<ogra> but still, that file comes from casper
<cjwatson> but it does need to regenerate the initramfs
<cjwatson> and remember that ubiquity (1) copies the live filesystem, then (2) removes the bits that are unnecessary
<cjwatson> unfortunately, it generates the initramfs between (1) and (2)
<ogra> /usr/share/initramfs-tools/conf.d/compcache is only in casper ... and i would assume an initramfs generation only hapens after casper was removed
<ogra>  *happens
<cjwatson> sadly that is not currently the case
<ogra> ah
<cjwatson> is there a bug filed about this?
<cjwatson> that's actually kind of bad
<ogra> i asked him several times, but he only pointed at the upgarde bug over and over, i'll file it
<ogra> what should it be, ubiquity or casper ?
<directhex> StevenK, a bunch of mono packages include C libs as well as mono assemblies, so those are usually arch:any
<cjwatson> ogra: ubiquity, please
<cjwatson> it isn't casper's fault at all
<cjwatson> ogra: please mark it importance high
<StevenK> directhex: Right, there's a package in the binary NEW queue which includes a Mono .dll and it's arch:all
<StevenK> directhex: Wasn't sure if it was grounds for rejection or not
<cjwatson> can anyone think of a "human-friendly" way to say "Building initramfs..."?
<directhex> StevenK, arch:all is correct more often than not
<directhex> StevenK, what's the package?
<cjwatson> that step can easily take 30 seconds, so I think it's worth describing separately; however following ogra's bug it can't just be subsumed into the description of the steps on either side of it
<cjwatson> (it used to be part of "Configuring hardware..."
<ogra> cjwatson, bug 328437 for you
<ubottu> Launchpad bug 328437 in ubiquity "casper compcache configuration is not removed in some cases" [High,New] https://launchpad.net/bugs/328437
<cjwatson> thanks
<cjwatson> perhaps "Preparing startup files..."
<cjwatson> ogra: s/can happen/unconditionally happens/ :-P
<pitti> cjwatson: that's for d-i? (I assume in ubiquity we just copy it from the live system?)
<cjwatson> pitti: wrong on both counts :)
<directhex> hm, tomboy-blogposter
<ogra> cjwatson, updated :)
<pitti> cjwatson: I thought rebuilding was only necessary once we start supporting raid/lvm/cryptroot in ubiquity.. but oh well :)
<cjwatson> there is an argument that casper should rebuild the initramfs when it's removed
<cjwatson> pitti: well, rebuilding is necessary for exactly the reason ogra quotes - the live CD initramfs contains casper, and we don't want that on the installed system
<pitti> ah
<StevenK> directhex: Right, tomboy-blogposter
<cjwatson> ogra: the good news is that this will go away with the first kernel upgrade
<ogra> will it ? i wonder how the file can persist at all ... the conf.d file is as i said owned by casper ... its shouldnt be there after casper removal
<ogra> i suspect we have two different bugs here
<ogra> now that i think about it
<cjwatson> no
<cjwatson> the conf.d file is *copied* into the initramfs
<ogra> oh, right !
<cjwatson> ok, admittedly that user reported that /usr/share/initramfs-tools/conf.d/compcache was still there
<cjwatson> so I suppose that is technically a separate problem, and I wouldn't mind seeing his installer syslog
<directhex> StevenK, something like that is very highly likely to be arch:all. i can verify if you like
<cjwatson> but I'm a lot more interested in the bug that seems to affect everyone :)
<ogra> indeed, well i asked him to comment on the bug in -users
<ogra> lets hope he does :)
<cjwatson> gar
<cjwatson> no, can you ask him to file a separate bug if he has problems not described by the one you filed
<cjwatson> otherwise we'll just get a multiple-problems bug which won't help anyway
<cjwatson> anyone
<ogra> ok
<cjwatson> thanks
<directhex> StevenK, just checked. no modulerefs so nowhere for arch-specific issues to appear
<StevenK> directhex: Okay, I'll accept it.
<cjwatson> nhandler: regarding the Replaces vs. Conflicts+Replaces point from the other day, I just read the relevant section of the policy manual and it is in fact quite clear about this
<cjwatson> For Replaces alone, it says:
<cjwatson>             Furthermore, this usage of <tt>Replaces</tt> only takes
<cjwatson>             effect when both packages are at least partially on the
<cjwatson>             system at once, so that it can only happen if they do not
<cjwatson>             conflict or if the conflict has been overridden.
<cjwatson> and for Conflicts+Replaces, it says:
<cjwatson>             Secondly, <tt>Replaces</tt> allows the packaging system to
<cjwatson>             resolve which package should be removed when there is a
<cjwatson>             conflict - see <ref id="conflicts">.  This usage only
<cjwatson>             takes effect when the two packages <em>do</em> conflict,
<cjwatson>             so that the two usages of this field do not interfere with
<cjwatson>             each other.
<ScottK> If there's a buildd admin around, I'd appreciate it if you would rescore kdepimlibs to start sooner.  I've got a large pile of further rebuilds that are dependent on that being done.
<ScottK> Sorry, on power pc.
<pitti> ScottK: nudged
<ScottK> pitti: Thanks.
<tjaalton> mvo: typo in /etc/update-motd.d/daily/10_releae_upgrade :)
<mvo> tjaalton: let me have a look
<tjaalton> mvo: the filename should have an 's'
<mvo> tjaalton: thanks, fixed
<tjaalton> mvo: thanks :)
<petski> mvo, asac: I was just reading the apturl RFC. I was wondering if PPA's could also be added in the policy. Within launchpad, you quite often see "could you please add my PPA to see if this resolves the issue", it would be super to simplify adding PPA's to the apt sources.
<asac> petski: its not ment to be constrained to any particular archive. if your PPA fulfills the requirements it can be whitelisted too
<asac> (now that we have signed PPAs)
<asac> petski: actually iirc PPAs are even explicitly mentioned somewhere, arent they?
<mvo> petski: now that ppas got singnatures we can support ppas as well
<asac> petski: seems they are not mentioned in the current version, but there is nothing in it that would exclude PPAs
<petski> well, I use my PPA only for bug-fixing, and some bugfixes might not work as expected. I don't think my PPA will pass the 'quality'-test.
<asac> heh.
<mvo> evand: I think I killed my syslinux boot record on my freshly created usb stick, is there a easy way to get it back without having to run the usb-creator again ?
<evand> yes...
<evand> dd if=/usr/lib/syslinux/mbr.bin of=/dev/sdb bs=446 count=1 conv=sync
<petski> Talking about PPA's ... mvo, already had some time to review https://code.launchpad.net/~petski/update-manager/ppa-support/+merge/3390 ? :)
<evand> mvo: ^
<mvo> petski: oh, right, I did briefly and commented somewhere too I think
<evand> might also want to run syslinux /dev/sdb1 - but the former command will dump a bootloader to your MBR
<mvo> evand: thanks! I try it out now
<petski> mvo, I haven't received it, I'm afraid
<mvo> petski: strange, I wonder where my comment got to
<petski> maybe you added it on staging.l.c ?
<mvo> petski: https://code.edge.launchpad.net/~petski/update-manager/ppa-support/ <- I put it into the whiteboard - looks like I clicked onthe wrong LP link or something
<petski> ah :)
<petski> Thanks for your comment. Anything I can do?
<mvo> petski: not question :) I wonder if we should just add it nevertheless
<mvo> petski: lets jump to #launchpad and ask how they feel about the added load
<petski> mvo: the "patch" contains a bugfix as well. IMHO that should be added whatever the launchpad guys say
<Adri2000> petski: has this feature been discussed somewhere already? I don't think it's a good idea to integrate ppa like official archive in update-manager. people will think ppa are like official packages and will trust them like official packages...
<petski> Adri2000, please take a look at https://code.launchpad.net/~petski/update-manager/ppa-support/+merge/3390
<mvo> petski: I have a look again. the problem with the merge was that it is based against the intrpid branch afaics and the jaunty branch changed a bit
<Adri2000> petski: I did already
<petski> mvo: https://code.launchpad.net/~ubuntu-core-dev/update-manager/jaunty gives 404
<mvo> petski: sorry for that, please try https://code.edge.launchpad.net/~ubuntu-core-dev/update-manager/main
<mvo> petski: I will see if I can get LP to have a alias so that at least "ubuntu" works
<Adri2000> petski: but a comment from Scott and an answer from you is not enough. has it been discussed on a mailing-list for example?
<petski> Adri2000, scott shares your thought, my suggestion was to prefix that changelog with something like '[This package originates from a Personal Package Archive]'
<cjwatson> I don't see why update-manager is controversial. If the user has already added the archive to sources.list, and has already added the key or acknowledged the warning (we can assume this, otherwise the package won't be eligible for installation), then update-manager should not obstruct matters by refusing to display the changelog
<cjwatson> the user has already said that that PPA is OK as far as they're concerned
<Adri2000> petski: average user won't consider such a statement as a warning that the package may break their system or steal their private data
<IntuitiveNipple> fooey! Evolution 2.25.90 has just duplicated every email in all the folders (more than 10,000), a result, I think, of the import into sqlite db from the mail folders
<cjwatson> Adri2000: that warning belongs earlier, not in update-manager
<cjwatson> update-manager is not the place where you add the PPA
<Adri2000> cjwatson: if update-manager behaves the same way for official trusted packages and ppa packages it will confuse people
<cjwatson> Adri2000: this makes no sense. If I have added a PPA to my sources.list then that's because I want to install packages from it
<mvo> Adri2000: adding changelog information sounds not too bad to me, a different heading for ppa updates should be used I guess
<cjwatson> once somebody has already acknowledged that the archive is untrusted, which I repeat is something that happens earlier when you're adding the PPA in the first place, it doesn't make sense to continue to complain about it
<cjwatson> note that if you've added the archive to sources.list, and the key to apt-key, then apt itself will behave the same way for both
<DktrKranz> mmh... is http://people.ubuntu.com/~ubuntu-archive/NBS/ running for main only? I cÃ
<pitti> DktrKranz: no, it should cover everything
<mvo> lool: I *think* I might have a backtrace now for the xine-list ugprade trigger crash
<DktrKranz> pitti: I'll have a deeper look, but it seems it doesn't keep track of universe
<Adri2000> cjwatson, mvo: I think the average user will think that ppa is somewhat trusted as it is integrated in update-manager, whereas actually ppas are not trusted more than any other thid party repository which is not integrated in update-manager
<Adri2000> when I say integrated in update-manager, I mean update-manager will put a special heading "Personal Package Archive", will fetch changelog, etc.
<cjwatson> Adri2000: they won't see it in update-manager *at all* unless they have already added the PPA to sources.list and added the key to apt-key, which involves acknowledging warnings about it being untrusted
<cjwatson> Adri2000: how many times do you want to warn them?!
<cjwatson> integration in update-manager isn't a matter of trust, it's a matter of convenience due to the fact that we know how the archive is laid out, that's all
<Adri2000> I just want ppas to be treated like any third party repository. them being hosted on launchpad doesn't change anything
<cjwatson> trust is handled separately, and I think it's very important to separate that
<cjwatson> I see no reason why we wouldn't fetch changelogs for other third party repositories if we knew how
<mvo> Adri2000: I understand your concerns, but I think cjwatson is right here, if we warn them too often peple will just blindly click away the warnings without bothering (and then miss one warning that actually was important)
<cjwatson> it's an inconvenience of the archive layout that this requires special knowledge
<Adri2000> because people will say "ah, update-manager knows repository X, so ubuntu people should know it, it should be safe to use"
<geser> adding more warnings won't help. either they know what they are doing or not (following just a howto which tells them what commands to run and where to click)
 * mvo wonders if we should have a "X-Changelog-URI" in the packages file so that it could be supported for other archives as well
<cjwatson> you're talking as if update-manager is the first place people will see PPAs
<cjwatson> it isn't
<petski> mvo: I like the idea
<cjwatson> if they see it in update-manager, they have already taken the decision to use that PPA
<Adri2000> actually I was speaking of warning in case we really want update-manager to show ppa packages in the special section. I'd very much prefer them to stay in the third party repo section
<cjwatson> being concerned about its presentation in update-manager seems precisely backwards to me
<cjwatson> software-properties and the like is where people take decisions about whether an archive is safe to use
<Adri2000> mvo: if that X-Changelog-URI is implemented, so any third party repository could use it, then I wouldn't be against update-manager fetch changelogs from there, being for ppa repo or any other third party repo
<cody-somerville> My NetworkManager keeps crashing but apport keeps failing to report it because when it tries to open Firefox a popup comes up and says firefox is already running, blah blah blah
<cody-somerville> There appears to be some sort of bug in nm_connection_clear_secrets()
<cody-somerville> asac, ^^
<Adri2000> I'm under the impression that people generally trust more ppa packages than other third party packages because they are hosted on launchpad. that kind of features will just confirm that idea to them
<cjwatson> it doesn't matter by that point
<cjwatson> they've already signed on the dotted line
<Adri2000> well, I'd be interested to see if I'm the only one thinking that way
<kirkland> mdz: do you have a work around for https://bugs.edge.launchpad.net/ubuntu/+source/openssh/+bug/328445 yet?
<ubottu> Ubuntu bug 328445 in openssh "[Jaunty/amd64] Agent admitted failure to sign using the key." [High,Confirmed]
<kirkland> mdz: i'm uploading a new key to launchpad every time i reboot
<mvo> lool: I have a theory about the xine-list-1.1 crash, it might be something with nvidia not setting the libGL links corretly during a upgrade (or something equally crazy). the crash seems to be happening inside libgl
<lool> mvo: In a meeting, coming back to you soon
<asac> cody-somerville: is that with vpn?
<cody-somerville> asac, aye
<kirkland> mdz: and simply unable to use people.ubuntu.com and chinstrap, etc.
<asac> cody-somerville:  i think i saw that too ... can you get a backtrace manually from the .crash file or run nm in gdb?
<cody-somerville> asac, Where are the .crash files kept?
<cody-somerville> oh
<cody-somerville> found them
<asac> cody-somerville: /var/crash ... you need to use apport-unpack first and then use gdb on the Core
<asac> with dbgsym installed and so on...
<asac> cody-somerville: not sure about the firefox already running thing. is there a ffox already running? does it open if you try to open it manually?
<cody-somerville> asac, Yes it is and yes it does
<asac> cody-somerville: sounds a bit like an apport bug then
<asac> jaunty?
<cody-somerville> yup
<asac> cody-somerville: when it says that can you look what command line you see in ps?
<asac> (e.g. before closing that dialog)
<cody-somerville> sure
<lool> mvo: So, backtrace?  :)
<cody-somerville> asac, I've marked two bugs as duplicate of bug #318554
<ubottu> Launchpad bug 318554 in network-manager "NetworkManager (service) SIGSEGV in nm_connection_clear_secrets() when VPN connection fails" [Medium,Confirmed] https://launchpad.net/bugs/318554
<lool> mvo: Oh libGL, ugly
<lool> Sounds like absolute fun
<asac> cody-somerville: thanks for the cleanup ;)
<mvo> lool: yeah :) I wait for the retracer before I make further conclusions, need to debug some compiz stuff
<lool> mvo: compiz uses GL, it's all clear to me now: compiz broke intrepid
<lool> I knew it
<mvo> lool: haha
<mvo> lool: the crash happend for me in a text console, no X running ;)
<asac> cody-somerville: ok the dupes had bt
<mvo> lool: don't be a seb128 and try to push all the blame to compiz, we all know its a gtk bug in the end anyway :P
<cody-somerville> asac, I attached my stacktrace too
 * mvo hugs seb128
 * seb128 hugs mvo
<lool> mvo: I bet that compiz was installed and had been run at least once before on these computers; that kind of voids your Gtk+2.0 warranty I'm afraid
<mvo> haha
<asac> cody-somerville: what type of vpn do you use?
<cody-somerville> asac, OpenVPN
<cody-somerville> asac, Also, you wouldn't know how to get flash working again in Jaunty do you? The package is installed but Firefox doesn't recognize it.
<davmor2> cody-somerville: voodoo
<asac> cody-somerville: what does it recognize in about:plugins
<cody-somerville> QuickTime,Windows Media Player Plug-in 10, DivXÂ® Web Player, Default Plugin, Demo Print Plugin for unix/linux, and Java(TM) Plug-in 1.6.0_12-b04
<asac> ok check whether the xulrunner-addons-flashplugin alternative is correct
<cody-somerville> sudo update-alternatives --config xulrunner-addons-flashplugin
<cody-somerville> No alternatives for xulrunner-addons-flashplugin.
 * cody-somerville can never remember how to correctly use update-alternatives
<cody-somerville> asac, There is no xulrunner-addons-flashplugin alternative
<cody-somerville> seb128, Is there something wrong with rhythmbox's shuffle? I seem to always get the same ol' songs out of the 710 songs I have.
<broonie>  21
<cody-somerville> asac, Maybe I want to install adobe-flashplugin instead of what Firefox tried to get me to install?
<cody-somerville> asac, that worked
<seb128> cody-somerville: not that I know
<cody-somerville> seb128, Its a rather serious bug. Its affecting my sanity. I can only listen to so much ABBA in one day ;]
<seb128> cody-somerville: there is a gconf key to change the shuffle algorhythm try another one?
<cody-somerville> oh, neat
<cody-somerville> seb128, I'll do that. Thanks.
<cody-somerville> seb128, Whats the key's name?
<seb128> cody-somerville: there is not so many rhythmbox key is it? let me have a look for you
<seb128> that's /apps/rhythmbox/something
<cody-somerville> Is it maybe /apps/rhythmbox/state/play_order ?
<cody-somerville> oh no wonder!
<cody-somerville> random-by-age-and-rating
<seb128> right
<cody-somerville> No wonder I get so much ABBA! Its ancient!
<seb128> the default is linear
<cody-somerville> seb128, Thank you so much. You're a life saver.
<seb128> you're welcome
<seb128> you did change the key or used a software which changed it btw
<seb128> because that value is not the stock one
<emgent> calc: ping
<ScottK> TheMuso: I see I need to add sparc to my list of ports with working kernels.
<cody-somerville> seb128, Weird. I've never opened gconf-editor before
<seb128> you perhaps used some tweakit tool which did it
<emgent> calc: when you come back please take a look and vote http://marketing.openoffice.org/ooocon2009/cfl/orvieto.html :)
<cody-somerville> seb128, no
<seb128> dunno why it changed then
<cody-somerville> seb128, IF you enable shuffle and repeat, it goes to "random-by-age-and-rating"
<seb128> ah
<cody-somerville> seb128, a rather unintended consequence ;]
<asac> cody-somerville: you sure you had flashplugin-nonfree installed?
<mdz> kirkland: no, I don't
<mdz> kirkland: well, apart from disabling the agent
<cody-somerville> asac, Yes. It got removed when I installed adobe-flashplugin
<mdz> env -u SSH_AUTH_SOCK ssh ...
<mdz> kirkland: could you add a link to the new bug to that old bug which was similar but said to be unrelated?
<mdz> I've lost track of it
<cody-somerville> asac, https://pastebin.canonical.com/13783/
<kirkland> mdz: i already did
<seb128> kirkland, mdz: what was the question?
<mdz> seb128: workaround
<mdz> kirkland: great, thanks
<kirkland> mdz: the old bug was https://bugs.launchpad.net/bugs/201786
<seb128> mdz: what is the issue?
<ubottu> Ubuntu bug 201786 in openssh "ssh Agent admitted failure to sign using the key on big endian machines" [Undecided,Confirmed]
<seb128> kirkland: I doubt it's it
<mdz> seb128: bug 328445
<ubottu> Launchpad bug 328445 in openssh "[Jaunty/amd64] Agent admitted failure to sign using the key." [High,Confirmed] https://launchpad.net/bugs/328445
<kirkland> seb128: the new bug is https://bugs.launchpad.net/bugs/328445
<ubottu> Ubuntu bug 328445 in openssh "[Jaunty/amd64] Agent admitted failure to sign using the key." [High,Confirmed]
<seb128> gnome bug #571060
<ubottu> Gnome bug 571060 in keyring files "gnome-keyring-daemon makes ssh fail with DSA keys" [Major,Unconfirmed] http://bugzilla.gnome.org/show_bug.cgi?id=571060
<seb128> and
<mdz> seb128: I filed a new bug as you said it was unrelated to that old one
<seb128> gnome bug #571422
<ubottu> Gnome bug 571422 in keyring files "ssh agent stopped working after 2.25.90 upgrade" [Normal,Unconfirmed] http://bugzilla.gnome.org/show_bug.cgi?id=571422
<seb128> mdz: right
<seb128> one issue is due to dsa keys, the other one not sure
<kirkland> i'm using rsa
<seb128> so that's the second one
<seb128> mdz: bug #328127
<ubottu> Launchpad bug 328127 in gnome-keyring "gnome-keyring-daemon returns Agent admitted failure to sign using the key." [Low,Triaged] https://launchpad.net/bugs/328127
<kirkland> mdz: aha, mdeslaur's workaround works for me
<kirkland> unset SSH_AUTH_SOCK
<mdz> kirkland: <mdz> env -u SSH_AUTH_SOCK ssh ...
<seb128> kirkland: set it to /tmp/ssh-... and run ssh-add
<seb128> so you have an agent again
<kirkland> mdz: sorry missed that one
<mdz> kirkland: it doesn't get the agent working again, so it's only a partial workaround
<mdz> sounds like seb128 may have a better one
<kirkland> seb128: Could not open a connection to your authentication agent.
<seb128> kirkland: do you have a socket in /tmp/ssh-.......
<seb128> and did you set SSH_AUTH_SOCK to this one?
<kirkland> seb128: export SSH_AUTH_SOCK=/tmp/ssh-ilNHaf4279/agent.4279
<kirkland> seb128: ssh-add
<kirkland> Could not open a connection to your authentication agent.
<seb128> ok, I don't know then, that's working on my box
<maxb> I think the x11 startup scripts decline to start a ssh-agent if one is already running (e.g. gnome-keyring's one) ?
<maxb> Workaround: gconftool -s /apps/gnome-keyring/daemon-components/ssh -t bool false
<cody-somerville> seb128, Also, I dunno if you say my bug report, but gedit in jaunty double frees right now when you quit
<seb128> cody-somerville: I did, there is nothing really useful in the log and it doesn't do it for me either
<cody-somerville> seb128, maybe its a plugin?
<seb128> could be
<seb128> try disabling those and see if it still crash
<DktrKranz> pitti, I checked some NBS results. i.e. http://people.ubuntu.com/~ubuntu-archive/NBS/libgconf2.0-cil, it lists only a couple of main packages but there are several packages in universe still b-d on old libgconf2.0-cil. This happens with several other packages listed.
<ember> DktrKranz i will update tomboy as it was blocked due to gnome-desktop-sharp2
<Laney> ember: did you forward the patch?
<ember> Laney to slomo?
<Laney> ye
<DktrKranz> ember: cool. If you're interested in that, there are several packages which need love (bug #314516)
<ubottu> Launchpad bug 314516 in tomboy "gnome-sharp2 transition" [Medium,Confirmed] https://launchpad.net/bugs/314516
<ember> Laney sure.
<Laney> goodo
<Keybuk> pitti: http://people.ubuntu.com/~pitti/tmp/bootchart-parallel-readahead/jaunty-20090212-sync-readahead.png
<Keybuk> your machine is not a happy one
<seb128> cody-somerville: do you use the seahorse gedit plugin? see bug #327252
<ubottu> Launchpad bug 327252 in seahorse-plugins "seahorse-plugins make gedit do a double free on exit" [Undecided,New] https://launchpad.net/bugs/327252
<cody-somerville> seb128, yup
<seb128> cody-somerville: bug dupped then
<cody-somerville> thanks
<seb128> you're welcome
<doko> ubuntu-archive: please accept mpfr in NEW
<primes2h> pitti: Hi, BTW did you have a look at the patch for this bug #172353 ?
<ubottu> Launchpad bug 172353 in human-icon-theme "Human theme has non-translatable emblem names." [Low,Fix released] https://launchpad.net/bugs/172353
<primes2h> pitti: I mean, at the debdiif.
<pitti> Keybuk: any idea how to make it more happy?
<seb128> in which way it's unhappy?
<pitti> primes2h: high on my list
<primes2h> pitti: Thank you :-)
<Keybuk> well, your disk IO is high all the way through the boot
<Keybuk> one CPU is spent almost entirely in I/O wait
<Keybuk> I know this sounds like a bad thing, but have you run memtest and badblocks on that?
<seb128> Keybuk: that's because it uses a real disk and not a fast sdcard or whatever you are using? ;-)
<Keybuk> seb128: pitti's laptop and mine are near-identical
<seb128> Keybuk: my bootchart are IO high almost during the whole boot too
<Keybuk> and my bootchart doesn't look like that
<pitti> Keybuk: what does sudo hdparm -tT /dev/sda show for you?
<pitti> Keybuk: this is a clean jaunty install from three days ago..
<seb128> Keybuk: do you have a chart from your laptop online somewhere?
<pitti> plus some extra packages, of course, but nothing particular that affects booting
<seb128> Keybuk: I'm just curious to see the difference
<Keybuk> no, I've actually not put bootchart on here yet
<Keybuk> the disk failed during the sprint!
<Keybuk> pitti: 1600 MB in 2.00s seconds = 800.53 MB/sec
<Keybuk> 50 MB in 3.12 seconds = 16.03 MB/sec
<Keybuk> pitti: what's odd is that there's no process to account for all that I/O
<pitti> Keybuk: I have 660 MB/s cached and 25 MB/s uncached, so that shouldn't be so much different
<pitti> (even looks faster than your's..)
<Keybuk> you have an entire CPU in I/O wait, that should show up like a sore thumb!
<pitti> Keybuk: how long does it take from grub->gdm and gdm->desktop on your d430?
<davmor2> guys strange question.  If I were to hit ctrl-l in nautilus and type in an sftp://user@machine after it's asked for the password should it goto /home/user on the machine or just / ?
<Keybuk> davmor2: yes
<davmor2> Keybuk: yes to what sorry?
<pitti> Keybuk: it goes to / for me, too
<davmor2> it should go to /home/user
<Keybuk> davmor2: yes, it should go to /home/user or /
<Keybuk> I think the current trend is /
<seb128> davmor2: it should not go to your user directory
<Keybuk> pitti: 15-17s or so I think
<pitti> Keybuk: !
<Keybuk> pitti: just doing an upgrade to see if it's something recent that's broke it
<davmor2> Keybuk: seb128: Okay thanks it's just in others it goes to /home/user and I thought I'd better check
<pitti> Keybuk: that's grub->gdm?
<Keybuk> pitti: right
<Keybuk> davmor2: sftp urls are a bit wishy-washy, I think the current trend is that sftp://user@machine/ means /
<davmor2> thanks guys
<seb128> Keybuk: my current desktop is weird, http://people.ubuntu.com/~seb128/jaunty-20090212-7.png
<seb128> Keybuk: do you have any idea why it's sitting there for 10 seconds before booting?
<Keybuk> weird
<seb128> indeed
<Keybuk> corrupt swap partition?
<Keybuk> cat /proc/swaps
<seb128> I think it's just display the Loading information ... line during that time
<Keybuk> no, it's in "resume"
<seb128>  cat /proc/swaps
<seb128> Filename				Type		Size	Used	Priorit
<seb128> no swap
<Keybuk> your swap has been corrupted by a bad hibernate
<Keybuk> that probably explains all that I/O too - your computer is paging like mad
<seb128> how do I fix that now?
<Keybuk> grep swap /etc/fstab
<seb128> UUID=10539512-374f-4517-8998-e550a1ebc4b3 none            swap    sw              0       0
<pitti> Keybuk: indeed it currently takes about 15 seconds until usplash even starts
<Keybuk> mkswap -U 10539512-374f-4517-8998-e550a1ebc4b3 /dev/sdXY
<pitti> Keybuk: there's a possiblity that the new kernel did something different, or that it's ext4 specific
<Keybuk> pitti: ext4 is kinda interesting, I've had several problems with it
<majeru> hello, are there any serious reasons why desktop x86 kernel lacks PAE support?
<Keybuk> majeru: it breaks old computers
<Keybuk> those with valves in them
<majeru> Keybuk: what kind of computers?
<Keybuk> majeru: 486s, etc.
<majeru> okay
<MacSlow> What's needed after "bzr revert -r n" to really touch and alter the files?
<majeru> but there could be an extra kernel package compiled with PAE, i guess
<Keybuk> I tend to believe the opposite; our default distribution should be built for i686 with PAE, etc.
<majeru> i agree
<Keybuk> and if we really need support for older machines, we could have a different architecture or something
<Keybuk> others disagree with me ;)
<majeru> anyway, ubuntu is damn slow on 486 boxes
<majeru> so we should move on
<Keybuk> ubuntu is slow on 686 boxes because we support 486 boxes
<cjwatson> majeru: there *is* such an extra kernel package with PAE: -server
<majeru> IMHO, ubuntu should target currently-produced hardware
<cjwatson> and PAE has problems on more than just 486s AFAIK
<cjwatson> but I can't remember where the bug about that is right now
<majeru> cjwatson: but the server one is incompatible with some drivers
<Keybuk> cjwatson: every other major distribution uses PAE without problem
<Keybuk> they use -march=686 too
<Keybuk> (note: very annoyed about this :p)
<cjwatson> you seem to have an astonishing familiarity with every other major distribution's complete list of bugs ;-)
<cjwatson> I get bug reports about systems that fail server installations due to PAE
<cjwatson> they aren't 486s either
<Keybuk> cjwatson: they just don't consider old hardware not being supported a bug
 * Keybuk files a bug that the kernel doesn't boot on an IBM XT
<Keybuk> can we fix that?
<cjwatson> don't be ridiculous
<Keybuk> we have honest, true, benchmark comparisons with other Linux distributions that show that Ubuntu is generally slower
<cjwatson> bug 151942, bug 227869
<ubottu> Launchpad bug 151942 in virtualbox "PANIC: CPU too old for this kernel" [Unknown,Fix released] https://launchpad.net/bugs/151942
<ubottu> Launchpad bug 227869 in base-installer "Server installer should not use -server kernel for non-PAE CPU's" [Medium,Triaged] https://launchpad.net/bugs/227869
<Ng> aren't there some VIA CPUs that don't work with full 686 build stuff? istr the C3 in my mini-ITX box is such a thing
<majeru> well, computers older than pentium3 can barely run Ubuntu with GUI
<Keybuk> and this can generally be attributed to the fact we don't use -march=686
<Keybuk> modprobe being the higher profile case recently
<Ng> it's almost a 686, but not quite, or something
<cjwatson> ridiculous hyperbole doesn't remotely help your case, though
<Keybuk> my case has already been thrown out
<Keybuk> ridiculous hyperbole is all I have left
<majeru> please calm down the flames
<majeru> :)
<cjwatson> if the kernel could switch at run-time between PAE and non-PAE using alternatives, I'd be all for us supporting PAE by default
<majeru> so there are CPUs that don't support PAE
<Keybuk> it cannot switch at runtime
<majeru> what if the bootloader choses the best ?
<cjwatson> majeru: unfortunately we don't have space on the Ubuntu CDs for more than one kernel
<cjwatson> hence my comment about alternatives
<majeru> when installing the system
<majeru> okay
<cjwatson> Ng: yes, VIA C3 systems are mentioned in at least one of the bugs I quoted above
<cjwatson> they are (AFAIK) currently-manufactured hardware on which PAE breaks
<Ng> carry a non-PAE kernel on the installer, have some magic that bumps you up to a better kernel if your hardware supports it? horrible hackery \o/
<Keybuk> cjwatson: and there's currently manufactured hardware that requires PAE to operate as intended
<Keybuk> Ng: nobody has ever come up with a way to do that
<cjwatson> Ng: needs either (a) two kernels on the CD (b) alternatives (see above)
<Ng> cjwatson: sorry, bu "bumps you", I meant "downloads it post-install". doesn't help with the case of requiring PAE, so it's not a useful suggestion other than improving post-install performance, I guess
<majeru> i wonder how hard would it be to make the kernel support both and be able to choose at runtime
<cjwatson> I have never heard of hardware that actually requires it to function - only for performance
<cjwatson> well, and high memory
<Keybuk> cjwatson: it's required to access all memory
<majeru> i'm interested about the memory side of it
<cjwatson> but we do install a PAE kernel by default on server installations
<cjwatson> which I suspect are the majority of cases requiring high memory at the moment
<majeru> nowadays desktops tend to get closer to the 4gig limit
<Keybuk> not true, desktops increasingly come with more memory
<cjwatson> "majority" "at the moment"
<Keybuk> you can't even boot Windows XP on non-PAE machines
<cjwatson> oh and "suspect"
<Keybuk> thus my belief that if we really must support older hardware, it should be done in a different CD - and our desktop CD should support current hardware
<cody-somerville> 0_o
<cjwatson> StevenK: I figured out the UMPC syslinux/gfxboot bug
<majeru> Keybuk: amd64 does that, most of the current cpus are 64bit :p
<Keybuk> majeru: but most users still avoid the 64bit CD because of issues with things like flash
<cjwatson> StevenK: turns out it's because your cdimage code uses the build system's syslinux, which is hardy; I fixed this syslinux bug in intrepid ...
<majeru> Keybuk: yes
<majeru> Keybuk: but why not make it like sparc64 did it
<majeru> 64bit kernel and 32bit userland
<cjwatson> StevenK: install a *current* syslinux on it and it works perfectly
<majeru> and make 64bit apps only for the apps that really need large integers
<cjwatson> majeru: last I checked, several of the 32->64bit thunks didn't actually work properly
<cjwatson> majeru: in fairly important areas - USB or printing or something like that
<majeru> i agree
<cjwatson> you asked why; if you agree, why did you ask? :-)
<majeru> but as the hardware is evolving in this direction, they will also evolve
<seb128> Keybuk: ok, that fixed the 5 seconds resume call, but still not the 5 first seconds where it's doing nothing
<Keybuk> seb128: got an updated chart?
<seb128> Keybuk: http://people.ubuntu.com/~seb128/jaunty-20090212-8.png
<Keybuk> seb128: got a copy of /var/log/dmesg as well?
<Keybuk> and kern.log
<seb128> Keybuk: http://people.ubuntu.com/~seb128/dmesg http://people.ubuntu.com/~seb128/kern.log
<Keybuk> hmm, your missing 5s are somewhere between kernel init and initramfs
<Keybuk> if you do break=top, how long does it take (stopwatch) after grub to get there?
<seb128> let me try
<seb128> Keybuk: 5 seconds
<Keybuk> ok, so it's somewhere in the kernel :-/
<Keybuk> if you boot without quiet, does anything show up in the waiting time?
<Keybuk> (I doubt it, since there's nothing in dmesg)
<seb128> no
<seb128> ok, not a big issue anyway, I get that only on my desktop box
<cjwatson> StevenK: getting the right syslinux content in place is a bit non-trivial. Could you take care of that please?
<cjwatson> slangasek: re grub2, looks like we need to get at least grub-common promoted to main anyway; the XFS handling in grub-install now depends on it (currently undeclared)
<slangasek> sounds reasonable
<cjwatson> I think I might just file a bug though
<Keybuk> bryce, tjaalton: how much do you know about xkbcomp?
<wasabi> Hmm. Latest console-setup package is... locking up during configure.
<wasabi> From SSH anyways.
<bryce> Keybuk: not deeply, just that it's useful for getting certain kbd debug info upstream always wants
<wasabi> The console stuff is one aspect of this system I seem to have never figured out much about.
<bryce> Keybuk: but I can find out more if there's an issue in it
<Keybuk> bryce: so our X server always runs xkbcomp on startup to compile its keymap-of-the-day
<bryce> o_O
<Keybuk> instead of us just precompiling them in the package
<bdmurray> jdstrand: I added the ufw package bug guidelines thanks!
<wasabi> setupcon --force is stopping.
<jdstrand> bdmurray: np :)
<bryce> Keybuk: sounds... inefficient.  can we change that?
<Keybuk> bryce: I have a patch to change it
<Keybuk> but I can't figure out the xkbcomp invocations I need to precompile them ;P
<bryce> Keybuk: looking at the man page there is a -xkm flag - did you already test that?
<Keybuk> oh, no, I'm just being silly
<Keybuk> the patch actually still invokes xkbcomp, it just doesn't delete the output after so it can reuse it next time
<bryce> ahh
<Keybuk> the reason my keyboard map is "wrong" is that I've never set it, lol
<Keybuk> function keys, etc. work which implies X isn't lobotomised
<cjwatson> wasabi: a sh -x trace of what setupcon is doing would help
<ScottK> bdmurray: Thanks for taking care of ubuntu-qa-tools bugmail.
<wasabi> + /bin/echo -n -e \033%G
<wasabi> that's the last line
<wasabi> not sure where that's heading to
<wasabi> need to understand the script first. :)
<bdmurray> ScottK: no problem, I didn't realize LP behaved that way
<tritium> kirkland: does ecryptfs meet FIPS 140-2?
<Keybuk> pitti: hmm, after the latest update to jaunty I see the continuous IO too
<wasabi> /bin/echo -n -e '\033%G' >$console    that's probably it
<Keybuk> also my keyboard has gone uppity ;)
<ScottK> bdmurray: Every week it seems to find a new way to send me stuff I don't care about ...
<cjwatson> wasabi: it's supposed to go to the console, indeed
<cjwatson> wasabi: do you *have* a working console on this system?
<kirkland> tritium: ecryptfs has not been certified against anything
<wasabi> As in true console or pseudo?
<wasabi> machine seems to be normal to me. :0
<tritium> kirkland: ok, does it rely on anything such as openssl that hsa been?
<cjwatson> wasabi: as in a device that won't block when you write to it :P
<tritium> has*
<cjwatson> wasabi: it's writing to one of /dev/tty[1-6]
<wasabi> Ahh. Those should be fine.
<cjwatson> wasabi: maybe an strace
<cjwatson> ?
<wasabi> Looks like tty5 blocks
<kirkland> tritium: for the filesystem and filename encryption, it uses the encryption algorithms in the linux kernel
<wasabi> sysadmin tty5     -                27Aug08 169days  0.42s  0.01s /bin/login --
<wasabi> Just sitting at a login prompt.
<kirkland> tritium: i don't think those have been certified (matter of cost, and changing too much over time)
<kirkland> tritium: but they are well vetted
<tritium> kirkland: hmm, ok.  Thank you.  I do appreciate the quick reply.
<kirkland> tritium: there is an openssl key module, however
<wasabi> on another machine both 1 and 4 block.
<cjwatson> maybe we should only do the UTF-8 setup at boot. not sure
<tritium> kirkland: :)
<cjwatson> or at least not when running the thing from postinst
<kirkland> tritium: i've never used it
<wasabi> I am ignorant about what could block up a tty
<wasabi> But I find it odd that 3 servers have various ones blocked up here.
<tritium> kirkland: nor have I.  I'll do some more research.  I'm working on a proposal that would use jaunty with ecrypfs, but one of my external requirements is that it meet FIPS 140-2.
<kirkland> tritium: nice ;-)  good luck with that
<tritium> kirkland: thanks!
<kirkland> tritium: the few things in Linux that have been FIPS-certified were mostly done by RH + IBM
<kirkland> tritium: and it's always a year+ after release
<tjaalton> Keybuk, bryce: that has been discussed upstream, but AIUI it's not trivial to fix
 * kirkland has worked on EAL certifications of RHEL/SLES in lives past ;-)  (blah)
<tritium> kirkland: ah, ok
<Keybuk> tjaalton: http://people.ubuntu.com/~scott/xkbcomp.patch
<tjaalton> Keybuk: oh, quite fresh too :)
<awsoonn> where would I look to add functionality to the Fn keys on my laptop?
<tjaalton> Keybuk: doesn't seem to be applied upstream
<awsoonn> I suppose I should be more specific: the touchpad enable/disable button.
<Keybuk> tjaalton: Intel in only applying patches in their own packages shocker ;)
<tjaalton> Keybuk: bah :)
 * Keybuk found it in the Moblin packages
<tjaalton> Keybuk: so it speeds up starting X clients?
<Keybuk> it speeds up starting the X server
<tjaalton> it takes less than two seconds here
<Keybuk> I envy you, it takes over 5s here without the patch
<tjaalton> heh
<tjaalton> but hot-starting gnome takes a long time, with practically no disk activity
<awsoonn> tjaalton: what patch are you guys talking about /me is interested
<pochu> awsoonn: 18:31 <    Keybuk> tjaalton: http://people.ubuntu.com/~scott/xkbcomp.patch
<awsoonn> pochu: thanks
<bryce> awsoonn: regarding your earlier question, see http://wiki.ubuntu.com/Hotkeys
<slangasek> awsoonn: FWIW, touchpad enable/disable is a known bug on acpi-support, which I'm going to work on next week
<LaserJock> asac: I'm a bit confused by the apturl RFC
<LaserJock> asac: do you have any example packages/repos ?
<LaserJock> If a 3rd-party repo can't be in Ubuntu due to licensing, I would think it would fail the LP requirements for FLOSS projects as well
<ScottK> LaserJock: I had the same thought.
<awsoonn> slangasek: feel free to e-mail me for testing/assistance. So you wold around the touchpad area much? I might have a -semi-related question for you. :)
<ScottK> LaserJock: Alternatively, if there is a contractual arrangement between Canonical and the third party to allow it, then I don't see why Partner wouldn't serve just as well.
<cjwatson> LaserJock: I fixed the way DVDs preseed tasksel, I think - just after you left last night
<slangasek> awsoonn: I'm working on hotkey-related issues; I don't do a lot with touchpads specifically, that's more tjaalton's domain I think
 * awsoonn is learning a lot today
<tjaalton> slangasek: I'll toss that ball to wgrant, I don't even have a touchpad :)
<slangasek> oh. :)
<awsoonn> ironicly enough, the touchpad I'm trying to fix belongs to someone named grant
<LaserJock> cjwatson: oh yeah, so when will a DVD show up I can test? are they dailies?
<cjwatson> LaserJock: twice-weekly or something like that
<LaserJock> cjwatson: ok, cool, thanks for that
<cjwatson> LaserJock: 17 12 * * 2,6   buildlive ubuntu-dvd; for-project ubuntu cron.dvd
<cjwatson> so Tue/Sat
<LaserJock> great, I try it out next week
<LaserJock> *I'll
<mr_pouit> superm1: the patch is missing from your branch (at least it was when I quickly looked this afternoon).
<slytherin> can anyone please give back xorg-server on powerpc?
<pitti> slytherin: poked
<superm1> mr_pouit, oh did i forget a bzr add :S?  i'll poke it in a little bit
<ebroder> Any backporters around that could take a look at bug #323546?
<ubottu> Launchpad bug 323546 in hardy-backports "xen-meta only depends on Xen 3.2 packages" [Undecided,New] https://launchpad.net/bugs/323546
<tjaalton> slytherin: why? it doesn't build until the ports are running 2.6.28
<jdong> ebroder: looking
<slytherin> tjaalton: ports now have 2.6.28 kernel.
<tjaalton> slytherin: so libdrm needs to be fixed next
<LaserJock> can I assume that a package that cannot reinstall after a failed install is a bug?
<asac> LaserJock: i dont think launchpad prevents that. most likely they need to get explicitly permission, which should be ok.
<jdong> ebroder: seems a bit hacky... this doesn't stop (likely nonfunctional) mixes of 3.2/3.3 alt deps, right?
<slytherin> tjaalton: the failure I saw in build log was because of libgl1-mesa-dev installation problem. This problem should not exist now so I thought it was good idea to give bacl xorg-server
<LaserJock> asac: well, I think you have to pay for non-FLOSS LP projects
<LaserJock> or something like that
<LaserJock> so I'm just wondering how common of a use case this is
<tjaalton> slytherin: mesa doesn't build either, that's why
<ebroder> jdong: Correct. I can try to come up with a packaging that splits things off into, e.g., ubuntu-xen-server-3.2 and ubuntu-xen-server-3.3 and then has ubuntu-xen-server depend on ubuntu-xen-server-3.2|ubuntu-xen-server-3.3, but I'm not sure how that looks when you upgrade into Intrepid
<jdong> ebroder: how often is it that one would want both 3.2 and 3.3 installed on the same system?
<tjaalton> slytherin: they both need the drm headers from linux-libc-dev (>2.6.28-foo)
<ebroder> jdong: You can't mix and match. For that matter, you can't really mix. A few of those packages conflict with their differently-versioned counterparts
<slytherin> tjaalton: It has built, at least on powerpc. https://edge.launchpad.net/ubuntu/jaunty/+source/mesa/+builds
<LaserJock> asac: when you consider Multiverse + Partner, I'm not sure what the use of these "trusted 3rd party" repos are? especially considering how much process your proposal is adding
<jdong> ebroder: ok, then would it be reasonable to simply offer xen-meta that depends on pure 3.3 in backports, and if one chooses to upgrade (in fact, dist-upgrade) to the backports version they will be forced onto -3.3?
<asac> LaserJock: partner is not enabled by default
<slytherin> tjaalton: http://ports.ubuntu.com/pool/main/l/linux-ports/linux-libc-dev_2.6.28-1.4_powerpc.deb
<asac> it has a good placement in the software sources dialog afaik
<LaserJock> asac: neither is a 3rd-party apt-url repo, right?
<ebroder> jdong: That's plausible. Having -backports turned on does already break Xen 3.2 if you're not careful (see bug #297077)
<tjaalton> slytherin: ok, nice
<ubottu> Launchpad bug 297077 in xen-3.3 "libxen3 in hardy-backports breaks Xen 3.2" [Undecided,New] https://launchpad.net/bugs/297077
<asac> LaserJock: no, but you can enable it through apturl ;)
<asac> LaserJock: if it got whitelisted
<jdong> ebroder: yay accurate abinum bumping :). I think pure-3.3 in backports is the best approach for this; would  you like to put on a debdiff for this?
<LaserJock> asac: but it could just as well make Partner more prominent in Software Sources
<ebroder> jdong: Sure, I can do that. I've got to go AFK for a bit, but I'll put it up later. Thanks for the help
<LaserJock> like with -proposed and -backports or something
<jdong> ebroder: yeah I shoudl go back to listening to 6.004 lecture too; ping me after you attach it :)
<kees> LaserJock: okay, so, what's the state of moodle?  I wanted to start digging into all the recent updates so we can get them into the stable releases.
<LaserJock> kees: well, I've apparently joined the Debian maintanence team
<kees> sweet
<LaserJock> kees: I'm working on the merge
<LaserJock> I filed a MIR for smarty
<asac> LaserJock: prominently hidden in some config dialog is still different from putting a link on your website.
<LaserJock> asac: but why would Partner be on a website somewhere when it's already in sources.list
<kees> LaserJock: cool, yeah, the jaunty packaging will be improved by getting more of the embedded stuff out.
<LaserJock> kees: yui was split out as well in Debian, *but* it deps on wwwconfig-common
<kees> LaserJock: I guess I will start collecting all the CVE patches from the latest releases
<LaserJock> kees: I could perhaps see if I can strip out the wwwconfig-common stuff (it wasn't there in Intrepid)
<LaserJock> or I could keep yui embedded for Jaunty and deal with it again for Jaunty+1
<kees> LaserJock: probably a good idea to check with the server team about wwwconfig-common.  it's been discussed several times before.
<asac> LaserJock: its not in sources.list by default
<LaserJock> asac: partner is
<kees> dbconfig-common got into main, I can't imagine it'd take much for wwwconfig-common too
<LaserJock> just not enabled by default
<asac> yes. so its not ;)
<LaserJock> but it *is* there, unlike other 3rd party repos
<LaserJock> so the system already has access to it, unlike something that's not there at all
<asac> LaserJock: commented in source.list is the same as prominently hidden in a preference dialog ;)
<LaserJock> well, then deal with it
<LaserJock> that's not my point
<asac> LaserJock: yes. of course we could have treated partner different for apturl, but wanted to come up with something in general
<LaserJock> I'm simply saying, what's the use case for these whitelists as in your RFC when Multiverse and Partner exists
<LaserJock> do we have examples repos?
<LaserJock> *example
<cody-somerville> LaserJock, the bzr repo?
<LaserJock> I wouldn't think that'd make it
<kwah> hi, everyone
<kwah> is there a way to find out how many memory linux graphics driver uses?
<LaserJock> it's commonly uninstallable and I don't think I'd want it whitelisted
<asac> LaserJock: well. there could be valid use for free software too.
<LaserJock> asac: like?
<asac> LaserJock: the idea was to make it hard to get whitelisted and learn from the experiences
<LaserJock> right
<kwah> I mean for various buffers and related staff
<asac> what we dont want is that we get hundreds of applications that we cant review
<LaserJock> but if they can get whitelisted, why can't the be in the regular repos?
<LaserJock> I just don't see a very good use case that wouldn't be covered by existing Ubuntu repos
<LaserJock> I could totally be wrong, I'm just not seeing it right now
<asac> LaserJock: we will see. initial discussion we things like wine in mind
<LaserJock> wine itself?
<asac> LaserJock: if it turns out that all this is not required, but we should just whitelist partner, then thats good too. its just that we need feedback
<asac> and want to learn ... before doing that.
<LaserJock> I don't know why you'd whitelist partner
<LaserJock> in the sense that, the repo information is already on the users machine, and where would they click on to enable it?
<asac> LaserJock: whitelisting is about providing a way to enable repos through apturl.
<LaserJock> right
<asac> LaserJock: there are different kind of users
<asac> we have ubuntu hardcores, but also "normal" users that might even not know how to use synaptic
<LaserJock> ok, so this is for people who can find the clicky link somewhere on canonical.com but can't use Software Sources?
<asac> i think you question the use of apturl at all
<LaserJock> no, not at all
<LaserJock> I love apturl
<asac> why would you want to place a link that installs a package if you alreawdy have the repo on your machine ;)
<asac> thats the question i get.
<LaserJock> you do have it there
<LaserJock> so if Partner is important, let's make it easier to get at in Add/Remove and/or Software Sources
<LaserJock> I just don't imagine that the use case for enabling Partner via apturl is very large
<LaserJock> as the person needs to find the webpage in the first place
<asac> LaserJock: well. so you say that installing packages through apturl has its use
<asac> LaserJock: but then you say that its ok that you need to add instructions next to the link for partner
<asac> saying: "take care: this link is broken until you go to software sources and check this"
<LaserJock> no, I'm saying you shouldn't need to do that
<asac> LaserJock: that means that we enable partner by default
<LaserJock> if Canonical is using apturl then they can whitelist it if they want, i don't care
<asac> or index the packages, which is equivalent imo
<asac> LaserJock: right. but is it bad to have a process to get whitelisted?
<LaserJock> it could be
<asac> why?
<LaserJock> it's adding a whole new category of stuff people have to look at
<LaserJock> you're proposing new teams, new applications that have to be reviewed, etc.
<LaserJock> so I'd want to make sure that we don't:
<LaserJock> 1) add process for processes sake
<LaserJock> 2) add a process for 1 use case (Partner)
<LaserJock> so my question was, how often are we going to be whitelisting? what use cases? are there example packages/repos?
<slangasek> well, "partner" are Canonical's partners; surely we want an open, symmetric process that lets other service providers participate on the same footing?
<ScottK-laptop> asac: I think it's a problem to write a process that can only ever apply to Canonical.
<ScottK-laptop> slangasek: But the proposed process doesn't do that.
<LaserJock> slangasek: right, but would imagine the TB could do that
<slangasek> hmm, doesn't it?
<slangasek> I haven't read the draft; that was just my impression from the UDS session
<ScottK-laptop> slangasek: Nope.  The only projects that could benifit can't be hosted on LP without paying for it and they have to be on LP.
<slangasek> hmm
<ScottK-laptop> It's a catch 22.
<ScottK-laptop> The only projects that could use the current process can either go in Multiverse or Partner.
<ScottK-laptop> I don't think it's reasonable for Ubuntu to write a policy based on the assumption that Launchpad's terms of service can be ignored.
<mvo> is anyone else bitten by the compiz problem that alt-f2,f1 does no longer work after the recent upgrade? if so, I would like to ask for " gconftool --get /apps/compiz/general/allscreens/options/active_plugins" (via /msg) please
<ScottK-laptop> I think a reasonable goal of this process would be to change what third party commercial providers can be whitelisted from an exclusively Canonical decision to an Ubuntu one.
<ScottK-laptop> This doesn't to that.
<LaserJock> well, I guess it could
<LaserJock> but it's sort of oddly done
<asac> ScottK-laptop: how is that?
<ScottK-laptop> The only people who could benifit from it would need Canonical's special permission to be on Launchpad.
<asac> ScottK-laptop: i have to admit that the launchpad point is quite a valid one
<LaserJock> yeah, but Canonical's unlikely to interfer I'd think
<asac> ScottK-laptop: otoh, i dont think that canonical would decide whether to allow a launchpad project depending on wehether they want that 3rd party repo
<LaserJock> but I don't know why the TB wouldn't make the decision on a case-by-case basis
<LaserJock> how often are we going to get these that we need a whole team/process for thit?
<asac> especially since you need to get the project before you can submit your application with details
<ScottK-laptop> So it moves the control point to a different part of Canonical, but that's it.
<ScottK-laptop> asac: That's my only issue really.
<asac> right. but the control point is before we even know whats going on.
<asac> but then, i also dont know about any official terms for non-free projects and launchpad
<ScottK-laptop> asac: True, but it doesn't change the fact that the proposed process can only benifit projects with some kind of special permission to use LP.
<asac> nobody raised that point during discussion ;)
<ScottK-laptop> The public terms say FOSS only.
<ScottK-laptop> Obviously there are exceptions since Launchpad is hosted on Launchpad.
<mvo> hm, that sounds like a valid point
 * mvo scratches his head
<asac> ScottK-laptop: well, maybe a project that gets permission should automatically get a launchpad permission or something
<asac> so we dont make it a prerequisites. but in the end i would think its not a real problem
<ScottK-laptop> Then Canonical would have to publish revised TOS for LP I think.
<asac> ScottK-laptop: where is the public term?
<asac> ScottK-laptop: from what i see it just says that its free if your are foss
<asac> nothing else
 * ScottK-laptop digs
<asac> but i might look at the wrong page
<LaserJock> right, so if you're not FLOSS you have to talk to Canonical and pay for it
<LaserJock> which is fine, but in the end you're always going through Canonical anyway
<mvo> the requirement for launchpad was really just so that we can ensure that there is one central place where we can find bugreports
<ScottK-laptop> On the project registration page, it says, "Launchpad.net is free to use for software projects that share their source code and comply with these  licensing policies.   Contact us if your project uses a proprietary license."
<LaserJock> mvo: what if it's a private LP project?
<mvo> the "it needs to go through canonical" is something we tried to avoid
<mvo> LaserJock: I don't think that would work out, in order to be a third party repo it would have to have a public bugtracker
<ScottK-laptop> Right, I'm not saying there was any ill intent, I just think this got missed in the previous discussion.
<ScottK-laptop> The licensing policies are https://help.launchpad.net/Legal/ProjectLicensing
<mvo> I see little point otherwise, how could we ensure the quality otherwise
<LaserJock> of course
<mvo> indeed
<mvo> its a good point, maybe as asac pointed out, some sort of exception or something
<LaserJock> but I belive that a lot of the people using LP for proprietary stuff are private
<LaserJock> so ...
<asac> LaserJock: right. but what we want - and why we said launchpad - is that users on ubuntu can file their issues public so that we can review the state of apackage and so on
<mvo> sorry, I don't really get it, if its private on LP it can not qualify as a trusted third party repository
<LaserJock> obviously
<asac> and having those bugs spread around the net would make it really hard to make a review on 3rd party stuff from within ubuntu
<LaserJock> but your use case for the whitelisting is precicesly the people who hav private LP projects
<asac> LaserJock: no.
<asac> LaserJock: where did we say private?
<LaserJock> the primary users of private LP projects are proprietary
<asac> private usually even menas that you need password to access repo
<LaserJock> the primary usage of this whitelisting is proprietary
<asac> LaserJock: but its wrong to make deduce from that that proprietary projects cannot have a public bug tracker
<LaserJock> I agree
<LaserJock> but it's a consideration
<ScottK-laptop> asac: I would suggest abstracting the characteristics of LP that caused you to say it has to be on LP and change it to must be hosted in an infrastructure that provides ...
<ScottK-laptop> If LP is an easy was for people to meet that requirement, that's fine, but I don't think that it can require LP be used.
<LaserJock> I dont' think you can just assume it's easy for them to have a public bug tracker on LP
<asac> LaserJock: this process was not designed with "easiness" for the 3rd party folks in mind
<ScottK-laptop> Also in a proprietary bug tracker there is no way to know that if there is a public bug tracker it is the only one or even the primary one.
<asac> LaserJock: we firmly believe that the right approach is to distribute in archive.
<LaserJock> but further, if the point of the proposal is to make a neutral place for 3rd parties to creat Partner-like repos I would think that the TB would be the right place
<asac> ScottK-laptop: we tried to address that in the document too
<asac> ScottK-laptop: we require that the repo folks that place a link should also post a link to bugtracker there
<ScottK-laptop> asac: I think if you focus on the hosting requirements and don't require LP, it's basically OK.
<LaserJock> I just can't imagine that there will be a lot of people who are going to meet the requirements, so I'd rather see it be case-by-case approval by the TB
<mvo> I guess we should change it so that it encourages LP (becuase it makes our life easer) but does not require it stricly
<LaserJock> how big do you imagine ~ubuntu-tpr will be?
<ScottK-laptop> The process should also define how that group is selected (don't recall if it does).
<superm1> mr_pouit, repushed
<rohan> https://wiki.ubuntu.com/KernelTeam/SuspendResumeTesting --> the script provided here for stress testing suspend/resume is meant to be run on which distribution?
<rohan> or is it distro agnostic?
<asac> LaserJock: i wouldnt expect too many volunteers for the review work.
<Keybuk> thought for the day
<soren> StevenK: Hey. I've fixed the missing copyright stuff in the eucalpytus package, so if that was the only issue you had with the package, it would be lovely if you could accept it (instead of getting one of the other AA's to start from scratch reviewing it).
<Keybuk> WHY is facebook mirroring my git repository?
<Keybuk> http://mirror.facebook.com/kernel.org/scm/linux/hotplug/keybuk/
<soren> Keybuk: I noticed almost the same thing yesterday.
<soren> (for a kvm repo)
<soren> Perhaps they're mirroring all of kernel.org. Yikes.
<LaserJock> asac: I dont' know, I'd probably volunteer :-)
<Keybuk> it does look like they mirror kernel.org
<Keybuk> pitti: what's most baffling about this never-ending-I/O is that it's *not* usplash
<Keybuk> which is what I traditionally blame for everything
<pitti> Keybuk: no, I started a boot without splash and quiet
<pitti> there wasn't one event which took 10 seconds, just several which took quite a while
<pitti> [    0.943156] pnp 00:03: io resource (0x1010-0x102f) overlaps 0000:00:1f.0 BAR 7 (0x1000-0x107f), disabling
<pitti> [    1.774255] Clocksource tsc unstable (delta = 2290571778 ns)
<Keybuk> it just seems like the entire system is on lithium
<pitti> [    1.832291] checking if image is initramfs... it is
<pitti> [    2.923320] Freeing initrd memory: 7756k freed
<pitti> ^ initramfs uncomression, I guess
<pitti> [    2.945129] pci 0000:00:02.0: Boot video device
<pitti> [    4.477063] pcieport-driver 0000:00:1c.0: setting latency timer to 64
<pitti> no idea about that one
<pitti> and so one
<pitti> it's just sluggish :/ (and so far it isn't ext4 related at all, I think)
<pitti> Keybuk: at least I don't remember earlier releases booting significantly faster, so it isn't a recent regression
<pitti> the initial 15 second lag until usplash is, though
 * pitti chuckles at apw's rejected apport upload
<apw> pitti, heh where did i upload it to that you'd have seen it?
<apw> i almost always forget to update the UNRELEASED to jaunty
<pitti> apw: it gets sent to Maintainer: and the uploader
<pitti> apw: and you apparently forgot to push your branch :)
<apw> oh thats silly given i sent it to a PPA
<pitti> apw: also, I made another commit this afternoon
<apw> yeah not pushed it with the last change yet
<apw> bah
<pitti> apw: ppa> please don't commit the unreleased->jaunty change then
<pitti> just do it, upload to ppa, and revert
<apw> i guess you'll merge it anyhow
<apw> right not commited
<pitti> apw: ah, right, or push it to a branch, and I'll review it
<pitti> apw: I might want to do some extra test suite checks for that, and so on
<apw> i am trying to test it before pushing it to you for merge
<apw> but the new keys seem to be stopping me installing it
<apw> grrr
<apw> pitti, when i do a change in bzr is it correct to use dch on its own to change the changelog?
<pitti> apw: no, not really; you should always commit the changelog together with the actual change
<apw> yeah i am doing that
<apw> doing a dch then a debcommit
<pitti> apw: if you already committed the change, then either uncommit, or commit it afterwards (more ugly, but works)
<pitti> apw: right, debcommit is â¥ :)
<apw> _but_ is the dch bit right?
<pitti> apw: thanks for workign on it
<pitti> apw: yes, dch is fine, I'm using that all the time
<apw> its a good way to learn the other stuff as i go
<apw> how bzr and deb packaging work together etc
<apw> and i want to fix apport as its making my life hard as it is
<pitti> apw: dch for changes, and dch -r/debcommit -r for an upload
<Lure> pitti, asac: any way to get lensfun & opencv packages get through MIR review before FF? Kubuntu would love to have these in main in jaunty...
<apw> and it knows things and should do it right
<apw> pitti, cool.  i want to end up a core-dev so i'll need to know
<apw> pitti, anyhow, i'll ping you when the branch is up, and you can tell me all the things i've done wrong
<pitti> apw: heh; thanks
<Keybuk> pitti: I don't think it's bootchart itself doing the IO :p
<asac> Lure: i will get them now
<Lure> asac: great! thanks in advance!
<pitti> Keybuk: no, all the times I mentioned in the mail were done with a stopwatch, without bootchart
<pitti> Keybuk: anyhow, if it just affects my laptop, but in general is very fast nowadays, then I won't complain :)
<Keybuk> plus bootchart=1hz still shows the I/O - albeit very imprecisely :p
<Keybuk> it seems to affect mine too ;)
<pitti> Keybuk: I already checked the acoustic setting in the bios, it's set to "performance"
<pitti> (FSVO "performance"...)
<pitti> [X] slow and silent [X] even slower and just a whisper
<apw> pitti, does your other fix change the url to which we send things?
<pitti> apw: no
<pitti> apw: if you push to your own branch, it doesn't affect commits to the ubuntu one
<apw> well its trying to send to file:://ubuntu/+source ...
<apw> right so what i am saying is the current apport with just my changes is sending to the wrong URL it appears
<apw> and i think i saw someone on one of my bugs reporting the same thing
<Keybuk> pitti: what's dellWirelessCtl?
<apw> pitti, i get the separation of branches.  what i am talking about is the submit side of apport has broken and i don't think i broke it
<pitti> Keybuk: something from libsmbios-bin, but I don't know -- /me eyes at superm1
<apw> yeah your changes are all docstrings and stuff
<pitti> wow, that package has a lot of stuff
<pitti> apw: don't worry, I can easily merge that
<pitti> Keybuk: tons of programs, but not /usr/sbin/makeItBootFast :(
<apw> yeah should merge fine.  but why is submit going to a mad place
<apw> pitti, the hostname has gone missing in the push part here
<apw> its going to file:///ubuntu/.... instead of to launchpad
<apw> waht defines that
<pitti> apw: push lp:~apw/apport/suspend-gui or so?
<apw> no no not bzr
<apw> i am generating a bug, and it all works until it says "send report" then it fires up
<pitti> oh
<pitti> apw: that has recently been fixed in glib; are you running current jaunty?
<apw> firefox with the wrong url, its a local file url not an http url
<pitti> or restarted your session in the last week?
<apw> its newish
<apw> i'll go update
<pitti> bug 314263
<ubottu> Launchpad bug 314263 in glib2.0 "regression - URIs opened with firefox %u load as local files (file:///...)" [High,Fix released] https://launchpad.net/bugs/314263
 * pitti pokes ubottu
<tobi> which package contains the debugging symbols for: xserver-xorg-video-nv?
<pitti> apw: suspend/resume testing to the max, eh? :-)
<apw> yeah gotta test ones changes before actually asking you to merge them
<pitti> tobi: xserver-xorg-video-nv-dbgsym, if you have ddebs.u.c. enabled
<apw> we had a case of someone not doing that recently and its not cool
<pitti> apw: I meant, never restarting your session :)
<apw> hehe. actually a just logged in
<apw> but tere are some 22MB of jaunty updates
<apw> which i should put on before i say "its still borked'
<superm1> pitti, for jaunty all of that stuff is now in smbios-utils instead of libsmbios-bin.  most of it has been rewritten in C with python bindings
<tobi> pitti, not until now. thank you!
<pitti> superm1: oh, I still have libsmbios-bin installed
<superm1> pitti, yeah smbios-utils is marked as a replaces for libsmbios-bin
<pitti> at least dellWirelessCtl is already an ELF file, not python
<pitti> superm1: should I flip the Recommends: in hal then? it still says libsmbios-bin
<superm1> pitti, yeah i was going to do that after smbios-utils cleared NEW.  I guess it has by now, so go ahead
<pitti> superm1: shoudln't it also Conflicts:libsmbios-bin then, to make sure it gets uninstalled?
<pitti> superm1: oh, you mean that the new smbios-utils is Python now, and the old one was C?
<superm1> pitti, well I was quite on edge about whether to mark it as conflicts, because there are still a few legacy binaries in it that are not part of the new libsmbios that someone "could" use if they wanted, but that weren't necessarily going to be supported going forward
<pitti> superm1: ah, I see
<superm1> pitti, no, libsmbios itself was C++ as well as all it's binaries.  now libsmbios is C based, and smbios-utils are all python
<pitti> that'll make Keybuk happy, more python in the boot processs :)
<superm1> pitti, if you think setting a conflicts: too is worthwhile, I can make that change too, just a little wary about it.
<Keybuk> pitti: Python is going to be banned from the boot process ;)
<pitti> superm1: as long as having both installed wont wreak havoc...
<pitti> superm1: we just have to assume that everyone has libsmbios-bin installed, and an upgrade will then have both
<apw> are we expecting any more fixes for pulse audio?  or what i have on my machines 'it'
<Keybuk> apw: I blame the kernel ;)
<apw> heh ... but i know if i disable pulse it will be better
<apw> i have not see 1 system which has good sound right now, they all break up
<apw> and i've had the oppotunity to see a large number in the last two weeks
<apw> and with FF a week away i am getting twitchy
<Keybuk> it's probably an I/O problem ;)
<superm1> pitti, well at least if someone wants to, they can write C apps that link to libsmbios_c instead of the python though.
<superm1> pitti, yeah having both installed will be okay.  I'll think more about if conflicts is appropriate though.
<Keybuk> apw: seriously, I/O performance in 2.6.28 is absolutely terrible right now
<Keybuk> my boot is 12s longer after a kernel upgrade
<apw> great... any clues?
<Keybuk> none
<Keybuk> stat shows that there's a lot of IO going on, but not attributed to any particular process
<Keybuk> one entire core is maxed out at I/O wait
<Keybuk> which tends to imply it's a kernel thread
<apw> pitti, my system is fully up to date now and still sending to the file:///ubuntu thing
<cody-somerville> pitti, mine did that too but often times I get "Firefox is already running but not responding..."
<cody-somerville> pitti, I mentioned the problem to asac this morning
<pitti> apw: eww; you restarted your session after the update?
<apw> i updated and rebooted
<apw> then i triped the susped
<apw> and rebooted again
<apw> and i have the supposedly fixed glib2
<apw> i'll test again
<pitti> apw: there were two patches
<pitti> apw: one hack, which reportedly worked, but got rejected upstream
<apw> both to glib2?
<pitti> and one "good" solution, where I didn't see feedback on
<apw> i got the version in the last comment in the bug
<apw> and i'd say its balls from my testing
<apw> will feeback there and then frig it in the next one
<apw> to get my testnig done
<pitti> apw: you could try to download https://edge.launchpad.net/ubuntu/+source/glib2.0/2.19.5-0ubuntu3 and build/install it locally
<pitti> that's with the previous patch
<pitti> if that works, we need to discuss the current patch upstream again
<apw> deffo does not work here
<apw> balls, why is there alway someone elses bug in your way
<apw> crap i can't frig it either as changing the url loses the post
<apw> GRRRR
<apw> pitti, is there an incantation to get that source there and expand it automatically
<pitti> apw: you click on that link and can get dsc/diff.gz/orig.tar.gz from there
<apw> nothing simpler than 3 downloads and a manual resostructc?
<pitti> apw: anyway, didn't you just change the UI? the submission part shouldn't have changed at all surely?
<apw> no, but it would be nice to test it all the way through
<pitti> apw: s/resostructc?/dpkg-source -x and debuild -b/
<apw> i am a pedant
<pitti> apw: sure, but just replace file:///ubuntu/ with https://launchpad/
<pitti> in the browser
<pitti> then it should be all good
<apw> no cause that loses the POST info
<apw> so you get a fesh virgin bug
<pitti> ?
<pitti> apport doesn't use POST
<apw> so how does the rest of the info get in to the bug
<apw> oh magic occurs
 * apw takes it back
<pitti> it first uploads the blob to lp, gets the ticket for it, and then uses /+filebug?DEADBEEF_ticketnumber
<pitti> apw: yeah, âª it's a kind of magic â« â¬
<apw> though it looses the title setting
<apw> and the tags
<apw> just the title, the tags are there
<apw> when did you add the arch to the tags?
<apw> pitti, ok it looks good.  i'll request my branch is merged
<pitti> apw: arch> committed last week, per request of bdmurray
<apw> yeah its good
<pitti> apw: hm, the title should have been a GET argument; I might misremember, though
<apw> pitti, ok officially requested merge: https://code.launchpad.net/~apw/apport/suspend-resume-pt3/+merge/3584
<pitti> apw: thanks; will look at it ASAP
<bardyr> apw, btw those vanilla kernels builds are great :) thanks for that
<apw> bardyr, they are getting a little out of date, as we are mid trying to convert them to central builds
<apw> so expect something more automatic soon
<jcastro> directhex: do you have anyone looking at monodevelop? I have a volunteer but I need to send him someplace. :)
<directhex> jcastro, upstream were releasing beta 1 todayish, meebey should be taking a look imminently
<apw> bardyr, what you using them for?  help me justify the effort to maintain them if i know
<jcastro> directhex: yeah mhutch told me has them ready. Where shall I send this new person, do you guys have a channel?
<bardyr> apw, trying out some kernel hacking and 2.6.29 kernel (which is great )
<apw> cool
<directhex> jcastro, all work tends to happen in oftc #debian-mono
<directhex> jcastro, in fact we seem to be accumulating non-debbuntu people now. we have a gentoo mono packager in residence, and a couple of upstream people
<jcastro> directhex: perfect, I'll send him along your way
<pitti> apw: oh, so this doesn't actually change the UI presentation, which still says "critical kernel problem encountered blabla"
<apw> no not yet.  this is just to stop it being a pain for us to handle the bugs
<apw> steve just sent me the bones of that bit, which is next
<apw> i will try and integrate and push that tommorrow
<pitti> apw: so, current changes look fine; I'll merge/commit/upload
<apw> i just spent half a day going through them and had to update the titles on them all
<apw> which was stupid as apport knows
<apw> pitti, thanks
<pitti> apw: [done]
<apw> pitti, top man
<pitti> apw: you should pull lp:~ubuntu-core-dev/apport/ubuntu/ into your branch, to get the conflicts resolved, etc.
<pitti> (if you plan to continue to use this branch)
<apw> will make a new one for the new topic
<ScottK> pitti: Would you please rescore qt4-x11 on sparc and if it's not too hard, could you at least rescore kde* on powerpc ahead of the Universe packages (if that's a lot of work, it'll get done eventually).
<pitti> ScottK: kde* expands to what?
<pitti> ScottK: qt4-x11 bumped
<ScottK> pitti: About 18 of the 24 source packages that make up KDE core.
<pitti> ScottK: ah, http://people.ubuntu.com/~ubuntu-archive/testing-ports/jaunty_outdate.txt FTW :)
<ScottK> pitti: Yeah.  I was about to hand you https://wiki.kubuntu.org/Kubuntu/Ninjas/DependencyGraph?action=AttachFile&do=get&target=kde-dep-graph.png
<ScottK> It's all but one of the leaf packages.
<kirkland> slangasek: kees said you had some udev/cryptsetup issues?
<kirkland> slangasek: i was having some trouble last night setting up encrypted swap, using the same steps i've been using for years
<kirkland> slangasek: what problem were you seeing, and has it been cleaned up yet?
<apw> pitti, just downgrading glib2.0 to the version you suggested has fixed apport.  writing it up in the bug and moving it back to BROKEN
<pitti> apw: thanks
<ebroder> Hey jdong: I've updated my xen-meta debdiff (LP bug #323546)
<ubottu> Launchpad bug 323546 in hardy-backports "xen-meta only depends on Xen 3.2 packages" [Undecided,New] https://launchpad.net/bugs/323546
<jdong> ebroder: thanks much; I'll review and upload
<ebroder> Awesome. Thanks
<jdong> sure thing
<jdong> ebroder: ok it's sitting in the queue.
<slangasek> kirkland: there's a udev bug, it's in the errata for alpha-4
<kirkland> slangasek: i'm experiencing https://bugs.edge.launchpad.net/ubuntu/+source/cryptsetup/+bug/316607
<ubottu> Ubuntu bug 316607 in cryptsetup "Encrypted SWAP partition not created/mounted" [Undecided,Confirmed]
<kirkland> slangasek: there's a patch attached to that one, i'm looking at it now
<slangasek> kirkland: ah, I haven't seen that one.
<slangasek> kirkland: mine was "initramfs missing the cryptsetup hooks"
<kirkland> slangasek: gotcha, that's different
<kirkland> slangasek: mine, too, however, appears to actually be a udev problem
<ogra> bryce, is the xrandr systray thingie your work ?
<ogra> (i mean the little applet you can enable in the screen settings)
<arthur-> doko: bootstrap finished on mips64, now running the testsuite
<bryce> ogra: it's from RedHat
<TheMuso> cjwatson: I still have reason to believe that the cd images obtained via rsync are older than the ones on http. I just built an i386 alternate image from jigdo, and it has the md5sum 736f5d628fc5a1894baaf1585baebb94
<bryce> ogra: I only put a few patches in it but don't maintain it regularly or anything
<ogra> bryce, ah ... would it be possible to package the sytray applet eparately ?
<TheMuso> cjwatson: in addition, the CD images I get via rsync still have the -6-generic kernel for d-i.
<bryce> ogra: that'd be a seb128 question
<ogra> bryce, the systray only would implement https://blueprints.launchpad.net/ubuntu/+spec/mid-screen-rotation immediately :)
<bryce> ogra: well it has kind of involved dependencies with gnome-desktop and gnome-settings-daemon, so don't think it'd be a trivial packaging task
<ogra> ah, sad
<bryce> ogra: fwiw, tseliot has been working on the side on another randr tool, that has a cleaner set of dependencies
<ogra> well, the spec is obsoleted for jaunty anyway, i just thought it would be a cheap way to get it implemented anyway
<TheMuso> cjwatson: no, its my screw up, thought the isos were in a particular dir on my machine, but they are somewhere else. Don't mind me.
<bryce> ogra: it's not in the archive yet, and probably needs more work before it's ready for prime time, but it'd probably be a simpler path, if you want to avoid the overhead of all the gnome-* dependencies
<ogra> i'll talk to him
<seb128_> re
<seb128_> got disconnected
<seb128_> I was saying that I didn't try recently and I don't want to do it now because previous time I tried xrandr rotation xorg screwed, that was in hardy or intrepid though, but we got no bug about it
<bryce> yeah I'd save my work before testing rotation
<ogra> heh
<bryce> but I think a lot of the issues have improved.  Used to crash/freeze more often than not this time last year.
<ogra> works for me, just trashes my panel setup every time
<ogra> it gets the applets out of order
<bryce> yeah, panel does that for screen resizes too
<bryce> my laptop's icons are always messed up
<cjwatson> TheMuso: ... ok, glad you sorted it out before I saw and got confused :-)
<StevenK> cjwatson: Ahhhhh! That makes perfect sense.
<StevenK> TheMuso: So, it appears you can have a maximum of 3 arches build from linux-ports
<TheMuso> StevenK: no, not quite, I'll have all of them built next time around, which will be tonight.
<StevenK> Famous last words
<StevenK> TheMuso: Should I rescue i386 and ia64 -1.5 from NEW?
<cjwatson> gar, and I was so close to declaring my partman-auto-lvm project complete
<cjwatson> oh well, three known bugs
<TheMuso> StevenK: No, because I'll be rebasing against mainline jaunty's new upload, which will likely bring about an ABI bump.
<TheMuso> As for now, onto dmraid matters...
<StevenK> cjwatson: Hmmm. ./usr/lib/syslinux/isolinux.bin shows itself as the "isolinux Loader", whereas I can't see anything similar in /usr/lib/syslinux for syslinux itself
<StevenK> cjwatson: And /usr/bin/syslinux is a linked binary, which means I need to worry about arch and libc6 compatibility
<cjwatson> StevenK: /usr/bin/syslinux writes /usr/lib/syslinux/ldlinux.sys, approximately, but it does it with some funky FAT-patching stuff that looks decidedly non-trivial to do in shell
<cjwatson> StevenK: your concern is pretty much the same as mine
<cjwatson> StevenK: see mtools/syslinux.c in the syslinux source if you want to have a look at what it's doing
<cjwatson> maybe it could be reimplemented in perl - not sure
<StevenK> cjwatson: Oh, so you don't actually run isolinux at all on the host
<cjwatson> right, mkisofs knows how to stick it in the right place in the ISO image
<cjwatson> anyway, bedtime
<klasikahl> howdy. it appears yesterday there were some changes made in jaunty that have changed the way gnome authenticates ssh-agent.  i suspect maybe a change in ssh-agent.  either way, i am also getting buffer_get_int errors when trying to ssh to servers using pub/priv key auth.
<klasikahl> thought i should pop in and let someone know since it appears pub/priv key auth is completely broken now in jaunty
<klasikahl> cjwatson: ping
#ubuntu-devel 2009-02-13
<doko> I really love autoconf-2.63
<Keybuk> really? why?
<Keybuk> what's better compared to 2.61? :p
<doko> just trying to get gcc-4.3 and gcj-4.3 buildable again
<Keybuk> did it break anything?
<doko> gcc-4.3 and gcj-4.3
<Keybuk> how were they broken?
<Keybuk> it didn't look like much changed from 2.61 to 2.63
<doko> see https://edge.launchpad.net/ubuntu/+source/gcc-4.3/4.3.3-3ubuntu4
<doko> fixed that by using autoconf-2.59, as required by upstream
<doko> still have to look at the failure for gcj-4.3
<doko> if /bin/bash ../../libtool --tag=CC --mode=compile /scratch/packages/gcc/4.3/u/java/gcj-4.3-4.3.3/build/./gcc/xgcc -B/scratch/packages/gcc/4.3/u/java/gcj-4.3-4.3.3/build/./gcc/ -B/usr/i486-linux-gnu/bin/ -B/usr/i486-linux-gnu/lib/ -isystem /usr/i486-linux-gnu/include -isystem /usr/i486-linux-gnu/sys-include -DHAVE_CONFIG_H -I. -I../../../../../../src/libjava/classpath/native/fdlibm -I../../include    @EXTRA_CFLAGS@ -O2 -g -g -O2
<doko>    -MT e_acos.lo -MD -MP -MF ".deps/e_acos.Tpo" -c -o e_acos.lo ../../../../../../src/libjava/classpath/native/fdlibm/e_acos.c; \
<doko>         then mv -f ".deps/e_acos.Tpo" ".deps/e_acos.Plo"; else rm -f ".deps/e_acos.Tpo"; exit 1; fi
<Keybuk> weird
<Keybuk> I can't see anything obvious in the i386 build log that looks like an autoconf failure
<doko> probably this is my mistake (@EXTRA_CFLAGS@ not substituted)
<doko> well, it does work again using autoconf-2.59
<Keybuk> I can't find the error in the build log?
<Keybuk> libtool: compile: not configured to build any kind of library
<Keybuk> libtool: compile: See the libtool documentation for more information.
<Keybuk> libtool: compile: Fatal configuration error.
<Keybuk> ./libtool: line 150: CDPATH: command not found
<Keybuk> that looks like the problem?
<doko> it's in libobjc
<doko> yep
<doko> anyway, heading to bed now, will look at this after feature freeze
<Keybuk> bit of an odd one
<Keybuk> since all libtool ever does with CDPATH is try and unset it ;)
<Keybuk> looks more like a libtool bug
<doko> maybe, triggered by the autoconf update
<Keybuk> sh -e debian/patches/libobjc-gc-link.dpatch -patch -d /build/buildd/gcc-4.3-4.3.3/src
<Keybuk> patching file libobjc/Makefile.in
<Keybuk> what does that patch do? :)
<Keybuk> patching file libobjc/configure.ac
<doko> patching the libobjc/configure.ac and after that calling atutoconf the regenerate the configure file
<Keybuk> it might just be an ordering of the configure.ac problem
<doko> 2008-07-03  Matthias Klose  <doko@ubuntu.com>
<doko>         * configure.ac (OBJC_BOEHM_GC_LIBS): Link with libgcjgc_convenience.la
<doko>         and needed thread flags and libraries.
<doko>         * configure: Regenerate.
<doko>         * Makefile.in (libobjc_gc$(libsuffix).la): Link with OBJC_BOEHM_GC_LIBS.
<Keybuk> did it work ok with 2.61?
<doko> yes, 4.3.3-3ubuntu3 was built sucessfully before the autoconf update
<Keybuk> kooky
<Keybuk> everything in here is just a bug fix
<Keybuk> mostly to do with string quoting
<Keybuk> I'll have a look here and see if I can figure it out
<Keybuk> hmm, you build-dep on automake 1.9?
<Keybuk> might be a bug caused by that - try 1.10?
<cody-somerville> Keybuk, :P
 * Adri2000 needs a core-dev click on bug #328874
<ubottu> Launchpad bug 328874 in samba "getent group crashes winbindd on domain controller" [Undecided,New] https://launchpad.net/bugs/328874
<Adri2000> (hardy nomination)
<Adri2000> cody-somerville or Keybuk ? ^
<ScottK> If there's a buildd admin around, I'd appreciate it if you would find out what's up with the qt4-x11 build for sparc on artigas.  That's an early step in a long chain of build and so it'd be nice to get it killed/finished/restarted/whatever.
<StevenK> artigas was showing as timed out on +builds ...
<ScottK> Yep.  So it can't even fail and I get to retry it for the other buildd, it's just stuck in suspended animation.
<StevenK> ScottK: I think you gave back kdegraphics too early. I got a failed mail for it, so I retried it last night and it has now built
<ScottK> I did jump the gun on a few.  Sorry for spamming your inbox.  Thanks for taking care of it.
<ScottK> Today I hit a few sparc retries by accident when I meant to do powerpc.
<StevenK> We could start fixing ia64, too. Hm, did I release it from NEW ...
<ScottK> Yes.  I retried mesa.  that's the first one.
<StevenK> On sparc or ia64?
<ScottK> Waiting for it now.  Unfortunately soyuz in it's infinite wisdom scores all manual retries at 0.
<ScottK> ia64
<StevenK> I'm not certain I released linux-ports ia64 from NEW
<ScottK> Someone did.
<ScottK> sparc it's done.  qt4-x11 was the next in the chain.
 * StevenK shrugs
<ScottK> I'm all trained now on doing binary New (thanks to pitti), but kernels are in the class that I can't do from the web u/i.
<StevenK> Yes, kernels are special
<ScottK> Which is fine.  I probably wouldn't touch them even if I could.
<ScottK> I knocked out at least a third of the out of date on power pc already last night and today.
<StevenK> The last time I NEW'd a kernel the whole thing ended up in universe :-(
<StevenK> Which involved a *large* one-liner and bunch of watching to fix
<StevenK> ScottK: So you're the reason the powerpc queue is so large? :-)
<ScottK> Yes.
<ScottK> I did the same thing to lpia and armel recently too.
<dholbach> good morning
<ion_> morniÅ
<ScottK> Good morning
<highvoltage> good moo
<highvoltage> and morning
<dholbach> hi ion_, scottK, highvoltage
<highvoltage> dholbach: nice stuff on the loco-doc day. one day when I'm rich enough to not have to work so hard during the day I also want to be as cool as you :)
<dholbach> highvoltage: it's not like I did most of the work there
<dholbach> highvoltage: check out http://www.jonobacon.org/2009/02/13/the-docs-were-indeed-rocked/
<dholbach> highvoltage: lots of people put some hard work into fixing the docs, which is awesome
<highvoltage> *nod*
<highvoltage> I just read that post
<dholbach> :)
<Koon> Archive admins: I just uploaded a cleaner new release of eucalyptus-javadeps (0.2.1), please do not waste any more time on the fat 0.1
<pitti> Good morning
<StevenK> Morning pitti
<seb128> hello pitti StevenK sabdfl
<StevenK> Hey seb128
<sabdfl> howdy seb128
<sabdfl> are we feeling jaunty this moining?
<pitti> hey sabdfl
<pitti> sabdfl: look, behind! a three-antlered jackalope!
<soren> pitti: Yikes.
<Koon> pitti: the jackalope is ahead, not behind.
<directhex> mornin'!
<apw> anyone know anything about glade widget definitions?  specicially if they can have variables in tehm?
<ogra_> you mean inside the xml ?
<apw> yeah in that xml spagetti
<ogra_> yep, you usually can define default values in there
<apw> i have two identicle widgets other than the description line, and that seems stupid
<apw> nice where can i find out how to override them
<ogra_> well, in the xml code worst case
 * apw needs some n00b docs, clearly
<ogra_> apw, i always use a gui for creating the glade files being a lazy chap ...
<apw> hmmmm yeah wonder what was used before
<ogra_> glade-3 or glade-gnome-3
<ogra_> they are very helpful tools
 * directhex used glade once upon a time
 * apw watches his disk space dissappear
 * ogra_ hands apw bzip2
 * apw tries to mount /usr/bin via fuse to it
<ogra_> haha
<liw> mvo, yo?
<liw> mvo, connectivity problems?
<mvo> liw: yes :(
<mvo> liw: give me some minutes, I'm still fighting a compiz problem
<liw> mvo, sure
<apw> pitti, which version of the glade editors would you have used to edit the apport glade stuff?
<pitti> apw: apport's glade is still glade-2, I believe
<apw> thats why the whole thing changed when i tried to edit it
<cjwatson> I always find it best to do a load/save in the glade editor before doing anything else, to see what it changes
<sabdfl> pitti: i blinked and missed it, it booted too fast
<savvas> slangasek: do you recall why was bug #232469 rejected for jaunty?
<ubottu> Launchpad bug 232469 in wget "wget does not use network proxy in some cases" [Undecided,Confirmed] https://launchpad.net/bugs/232469
<ivoks> correct me if i'm wrong...
<ivoks> gcc-4.2 in hardy is 4.2.4
<ivoks> but the kernel is compiled with 4.2.3
<cjwatson> savvas: declining a release nomination doesn't mean that it can't be fixed for the release - just means the release team isn't interested in tracking it
<ivoks> we can't build modules that way
<cjwatson> savvas: it's usually much more productive to figure out a fix rather than arguing about the nomination state :-0
<cjwatson> :-)
<savvas> aaah
<savvas> cjwatson: ok, thanks!
<savvas> cjwatson: I wasn't going to argue about it, I was just curious :P
<apw> cjwatson, did we just have a gcc update for security?
<ivoks> 4.2.4 is in updates
<ogra_> seb128, the "evo doesnt unfold the folder tree for message folders" (remember, the thing i showed you at the sprint) bug comes and goes for me, now i can expand and collapse with +/- but mouseclicks still dont work
<seb128> weird bug
<ogra_> yeah
<ogra_> its only in evo
<ogra_> and this time i rebooted before checking, but its definately there
<seb128> nobody else complained about that and I never got this issue
<ogra_> but you use subfolders as well ?
<seb128> yes
<ogra_> though it doesnt work on the toplevel either
<ogra_> i.e. the inbox expander
<seb128> it work on the account, inbox, subfolder there
<apw> ivoks, that version is pretty old, entered updates on 2008-10-22, and the kernel version in update and proposed were buld 2009-01-29 ish
<apw> so i would have expected them to be built with it?
<ivoks> apw: correct
<apw> can you paste the full version string for me from /proc/version
<cjwatson> apw: no idea I'm afraid
 * apw notes there _is_ something cjwatson doesn't know ... odd
<cjwatson> I could look it up ;-)
<cjwatson> (https://launchpad.net/ubuntu/+source/gcc-4.2)
<apw> cjwatson, s'ok ... don't worry
<cjwatson> 4.2.4 was in intrepid as released, according to that
<cjwatson> oh, this was hardy
<ogra_> seb128, clicking fast i can see "opening folder" in the status bar
<ivoks> apw: Linux version 2.6.24-23-server (buildd@crested) (gcc version 4.2.3 (Ubuntu 4.2.3-2ubuntu7)) #1 SMP Mon Jan 26 01:36:05 UTC 2009
<ogra_> but the expander still does nothing
<seb128> ogra_: can you open a bug on bugzilla.gnome.org?
<cjwatson> hardy did have an update, but not "just" - it was back in October
<apw> ivoks, can you get the whole output of /proc/version for me
<apw> that matches my findings too ...
<ogra_> seb128, will do ... do you also need something in LP to track it ?
<ivoks> but on the other machine:
<apw> so need to confirm that the kernel was miss compiled or not
<seb128> ogra_: no
<ivoks> Linux version 2.6.24-23-server (buildd@palmer) (gcc version 4.2.4 (Ubuntu 4.2.4-1ubuntu3)) #1 SMP Thu Nov 27 19:19:15 UTC 2008
<ogra_> ok
<seb128> ogra_: it's not important enough for me to track
<ogra_> hmm
<seb128> I don't want to track every upstream bug which happens to one user
<ogra_> right :/
<apw> ivoks, ok on the 'broken' one whats in /proc/version_signature
 * ogra_ is sad he's the only one
<seb128> or we could import the zillions bugzilla bug to launchpad
<ivoks> apw: Ubuntu 2.6.24-23.48-server
<seb128> and make the buglists impossible to work on
<ivoks> hm
<ogra_> yeah, indeed
<apw> ivoks, and the working one?
<ivoks> apw: 46-server
<ivoks> i have kernel from the future? :)
<TheMuso> tjaalton: it happens to the best of us. :p
<apw> oh, thats a security kernel
<apw> ivoks that looks broke to me, could you file a bug against the linux package please
<ivoks> apw: sure
<apw> and in the description put the cat /proc/version and /proc/version_signature
<apw> for both the bad and good machines for me
<apw> it smells like we have a build environment out of sync.  if you could paste me the bug# once its done i'll have a poke
<tjaalton> TheMuso: heh.. *headdesk* :)
<ivoks> apw: we have that bug opened for 3 months: bug 292381
<ubottu> Launchpad bug 292381 in linux "[hardy] kernel 2.6.24-21-generic and gcc version mismatch" [High,Triaged] https://launchpad.net/bugs/292381
<apw> ivoks, thanks ...
<pitti> tseliot: do you think xorg-options-editor will make it for FF? (if not, no big harm, but I'm reviewing the jaunty spec list)
<pitti> Riddell: most kubuntu-jaunty-* specs are "not started"; I guess they are, could you please update their status?
<tseliot> pitti: bryce will review my changes soon and if we make it available in Jaunty, it will be in universe
<ogra> tjaalton, geeez, i just noticed that evdev started to drive my touchscreen with the lates updates ... (totally miscalibrated though)
<pitti> tseliot: I know, but it's still covered by FF
<apw> ivoks, ok could you add the -23 ones from your experience, and include both /proc/version and /proc/version_signature
<ivoks> apw: it's a gcc thing
<pitti> tseliot: so there is a working version? great
<tjaalton> ogra: good or bad?-)
<ivoks> apw: updates have gcc 4.2.4, but the security has 4.2.3
<apw> ivoks, yes i know, but the evidence is in your kernel strings which reported the gcc used
<apw> those are therefore what i need
<ivoks> ok
<apw> shove gcc -v in with each machine too
<apw> yours is a nice clear example of what is wrong
<tseliot> pitti: yes, but the UI does not follow the usability guidelines. Other that this, it works well
<ogra> tjaalton, well, good as in motion events and clicks are recognized, bad as in miscalibrated (i can only use the middle of the screen, like the size of a touchpad ... it behaves slightly similar to the touchpad)
<pitti> tseliot: cool, so it sounds it could well make it into universe by FF, and get UI cleanup by UIF?
<pitti> tseliot: would you mind updating the spec status and set it to "good progress"?
<pitti> (and say which bits are done and which are missing)
<tseliot> pitti: I doubt the UI cleanup will be done in time for jaunty
<tseliot> pitti: but yes, I'll update the blueprint
<tjaalton> ogra: ok, I don't know if it should autocalibrate somehow
<pitti> tseliot: ah, ok; do you think that' a blocker for getting it into universe?
<ogra> tjaalton, i doubt that and we need a calibration tool ... i somewhat lost my trust in upstream getting that support done since it took so long, i'll try to package the cairo calibration tool on the weekend, so we'll have it in for FF
<tseliot> pitti: no, I don't. While the UI cleanup could take place in time for Jaunty+1 the program works well, therefore it should be ok for universe
<pitti> tseliot: yay
<tjaalton> ogra: ok, good
<apw> ivoks, let me know when its in there
<ivoks> apw: there
<ivoks> apw: 64bit buildd is out of sync
<apw> ivoks, and i assume you get some kind of missmatch error when you try and build and external module?
<ivoks> apw: yes
<apw> can you paste one of those in too for me
<apw> also can you add the /etc/apt/sources.list for both machines if possible
<tseliot> pitti: spec updated
<danimo_> is there an ftp master around?
<danimo_>  /ubuntu/dists/feisty/ is missing on archive.ubuntu.com and all the mirrors I checked
<elmo> danimo_: feisty is end of life; it moved to old-releases.ubuntu.com
<elmo> danimo: https://lists.ubuntu.com/archives/ubuntu-announce/2008-September/000113.html
<danimo_> elmo: ok, just surprised that the other links are still around
<elmo> danimo_: I agree; that's a bug
<danimo_> anyway, thanls for the clarification
<danimo_> er, thanks :)
<slytherin> what could be the reason that a build that was given back yesterday is not yet started?
<cjwatson> slytherin: give-backs unfortunately default to a very low score
<cjwatson> (well, perhaps unfortunately, perhaps not)
<cjwatson> it does mean that it's harder to DoS the buildd with give-backs
<apw> ivoks, i suspect your 32 bit machine will suffer the same fate once rebooted
<ivoks> apw: you think? :)
<apw> sadly so :)
<apw> i think we know why this is occuring, just need to work out what the right way out of the maze of twisty pockets is
<slytherin> cjwatson: didn't know that. I was wondering why buildd are picking news uploaded packages when an old one given-back is pending.
<ivoks> well, it's obvious... -security and -updates don't have same gcc version
<ivoks> so, there's no easy way out of this
<cjwatson> ivoks: the easy way out is to copy gcc-4.2 from -updates to -security
<ivoks> right :)
<ivoks> and rebuild kernel
<apw> ivoks, right ... two solutions copy gcc to -security, or have two kernel builds one per pocket
<apw> and someone other than i needs to make that call.. will start the discussion
<cjwatson> two kernel builds => distasteful, IMO
<apw> cjwatson, i am with you, though its lower risk probabally
<cjwatson> personally I reckon we've already taken most of the risk having incorporated 4.2.4 into -updates
<ivoks> so, if ever gcc gets updated again, kernel rebuild is needed
<apw> ivoks, yes, and we need to put that on our proceedures to catch it too
<ivoks> or not change gcc version during release
<apw> yep.  or that.
<apw> i guess unless its a security issue, which is ok
<ivoks> not even in -backports :)
<apw> nnnng
<apw> only backporting higher releases is ok
<apw> as the packages are prefixd
<ivoks> right
<cjwatson> doko: this all looks like a reason to be cautious about gcc version bumps in stable releases in future :-/
<cjwatson> apw: so the kernel build literally looks at the upstream gcc version and encodes that in its ABI?
<cjwatson> apw: as opposed to the ABI bump being a result of a change in gcc code generation?
<apw> i don't think its quite that rigid, but there is clear issues with different compilers generating incompatible code across boundaries
<apw> so they have stated 'you should use the same' and people have coded that in their tools for those modules
<apw> and it is a bit frightening, its not like they are libraries with clean interfaces, they are really .o's munged together at run time
<apw> its wholy scarey the thought htat they might be at different compiler versions
<cjwatson> apw: so in that case backports are surely risky too?
<doko> well, the conservative approach would be not to change the compiler at all and tell people: "broken code with the default optimizations, please work around". or is this caused by -security/-updates divergencies?
<cjwatson> apw: I would have thought that if different versions of gcc were behaving as you say, that would be a serious problem for userspace too
<cjwatson> apw: after all userspace static linking is little different, but we don't have these problems
<apw> apps don't talk to other apps so tightly
<apw> we don't static link half a program
<cjwatson> true
<apw> we make a whole package or none of it
<apw> thats where the nasty fear comes in
<apw> and i suspect its not reasonable, but its there
<cjwatson> doko: right, this is because -security and -updates are different; my suggestion here is to copy 4.2.4 into -security
<apw> i think in paranoid builds we do insert the compiler version into the symbols somehow
<cjwatson> apw: so the nasty fear has resulted in people checking the upstream gcc version in their module build system, and if the versions were identical we would dodge that check?
<apw> right, we would be fine
<broonie> The kernel is also doing things like packing stuff aggressively and using ABI-relevant GCC features.
<apw> yeah i don't think i've ever seen quite so many options passed to gcc by anything else
<Adri2000> slangasek: bug #328874 is the samba bug I want to fix in hardy; you'll find there all the references. now for jaunty, can we hope for 3.2.8 to be uploaded to debian before our FF? or should we rather start working on it ourselves?
<ubottu> Launchpad bug 328874 in samba "getent group crashes winbindd on domain controller" [Medium,Confirmed] https://launchpad.net/bugs/328874
<pitti> doko, cjwatson: WDYT about dropping belocs-locales-bin and moving back to building locale-gen etc. from glibc? belocs is basically dead upstream, and patching locales to still work with our belocs-locales-bin version becomes painful
<doko> pitti: sure, sounds fine
<StevenK> pitti: Belocs died? I thought they were more active ...
<cjwatson> pitti: if belocs is dead, I don't have a problem with it; is this like kbd and console-tools, they oscillate in terms of levels of activity?
<pitti> cjwatson: seems so; right now, glibc upstream is pretty good at updating locales and such..
<cjwatson> Denis Barbier got fed up with something in Debian (I forget what) and left, which probably didn't help belocs
<pitti> cjwatson: I'm still fine with keeping the locales themselves separate
<pitti> it's easier to update them that way
<cjwatson> pitti: as long as all the locale-gen stuff keeps on working the same way, I don't really care :)
<pitti> okay, then I'll look into that
<pitti> makes more sense than spending two hours on adding workaround patches
<StevenK> cjwatson: Denis Barbier left? Hm. I missed that.
 * pitti -> lunch and appointment, will be back for release team meeting
<pitti> slangasek: I might miss the first couple of minutes of the release meeting; Rick should be there, but could you move the desktop team report down the agenda?
<doko> pitti, cjwatson: please accept python2.6 in NEW
<jdstrand> Keybuk: hi! I'm developing a dhclient apparmor profile. I'm running into a race condition with udev bringing up dhcp auto interfaces before apparmor is started, which means dhclient is started before apparmor and thus unconfined. I have a way solve this by utilizing /etc/network/if-pre-up.d and checking for a few things. Ie, is apparmor available/enabled in the kernel and if so, sleep for a bit until apparmor starts
<jdstrand> Keybuk: ifup is called via start-stop-daemon, so the sleep doesn't affect boot time
<jdstrand> Keybuk: it works great in almost all cases but one-- a system with apparmor enabled where the user disabled its initscript
<apw> how long after a PPA package is marked published should i expect it to show up in an apt-get update/upgrade ?
<jdstrand> Keybuk: I'd ideally like to skip the checks after rcS completes
<jdstrand> Keybuk: a) does my method make sense and b) is there a reliable way to see if rcS is completed (perhaps upstart's 'status' command)?
<apw> jdstrand, runlevel perhaps?
<slytherin> apw: #launchpad is the right channel to ask that question
<apw> slytherin, ta
<ogra> jdstrand, does that take NM into account ? :)
<jdstrand> ogra: works great with nm, and resolvconf :)
<jdstrand> apw: I thought about runlevel, but didn't think it would report 'S'. its manpage says it does, so that should work great
<jdstrand> ogra: it should work fine for anything that drops stuff into the various hooks directories too
<ogra> sounds good
<jdstrand> ogra: actually, while I've got you here-- dhcpd also has a profile. I scoured the LTSP docs to make sure it would work out of the box there. would you mind perusing /etc/apparmor.d/usr.sbin.dhcpd3 and make sure I didn't miss anything?
<jdstrand> ogra: or if grabbing the source see debian/apparmor-profile
<soren> jdstrand: Is there a debhelper thing to install apparmour profiles?
 * soren wonders if he could get irssi to s/apparmour/apparmor/ for him.
<jdstrand> soren: no, not yet. some could possibly be automated-- I'd have to think about it
<soren> jdstrand: It could be quite like the dh_installudev helper, I imagine.
<jdstrand> soren: the more I think about it, the more I think it is a good idea
 * soren takes a break
<soren> jdstrand: It's very convenient, especially if the paths should change at some point or they need particular permissions or whatever.
 * jdstrand nods
<jdstrand> soren: of course, it's still on my todo like to have a dh_ufw :)
<EagleScreen> hello
<EagleScreen> the upstream Debian maintainer disagree with to split 'menu' and su-to-root script, becouse using of su-to-root for .desktop files make them Debian-specific, but may be this is not a problem in Ubuntu.
<pochu> is he aware that people use su-to-root in desktop files anyway?
<cjwatson> perhaps there should be a special syntax for this in .desktop files that doesn't involve an explicit auxiliary command
<cjwatson> and have the desktop figure out how to escalate privileges - that seems more elegant
<pochu> or perhaps the freedesktop folks could resurrect xdgsu and say in the desktop standard that is the official way to gain su priviledges
<pochu> but that is much to ask, I guess... :)
<cjwatson> or that, yes
<EagleScreen> i am not sure, but may be polycikit will fix this kind of issues in a near future..
<jdstrand> apw, Keybuk: fyi, runlevel doesn't have enough info yet to report 'S', but it will exit non-zero, which I can test for
<jdstrand> apw: thanks for the suggestion
<ogra> cjwatson, hmm, after being asked about automatic updates in d-i i always see "running kdesudo" before it switches to pkgsel, is that intentional (that message seems a bit weird especially on a gnome install)
<soren> ogra: ...and server, IIRC.
<cjwatson> ogra: it's cosmetic, it's just a script called "kdesudo" that happened to get inherited and that does nothing
<cjwatson> you can ignore it
<ogra> ok
<cjwatson> ogra: I'll remove it since it does nothing for Ubuntu
<superm1> slangasek, mythbuntu's dailies got a weird mirror syncing issue in the log (http://people.ubuntu.com/~ubuntu-archive/cd-build-logs/mythbuntu/jaunty/daily-live-20090213.log) can you queue up another attempt? all other build problems should have been resolved with many of the uploads i did yesterday
<rtg> I need an archive admin to promote wireless-crda to main per this MIR: https://bugs.edge.launchpad.net/ubuntu/+bug/325801
<ubottu> Ubuntu bug 325801 in ubuntu "Main inclusion request: wireless-crda" [Undecided,In progress]
<devfil2> Keybuk: can I work on uswsusp merge?
<slangasek> savvas: 232469 - exactly what cjwatson replied in the bug
<slangasek> Adri2000: I think in fact that we'll have samba 3.3.0 in before FF
<slangasek> pitti: shuffling> ack, will do
<slangasek> superm1: rerunning mythbuntu cronjob
<superm1> slangasek, thanks
<apw> pitti, how do i find the errors from the backend of apport
<apw> from the thing behing the (!)
<apw> or how do i run the backend by hand or ...
<EagleScreen> networkmanager-gnome sometimes fail to connect to a WPA-Entrepise net
<pitti> apw: behind the "!"?
<apw> the ! appears on the gnome task bar you hit that, it dies horribly without telling your logging anywhere i can find
<pitti> ah
<pitti> apw: the ! is from update-notifier
<apw> how does one do the same thing either getting a log, or from the command line or anything other than blind fixing
<pitti> apw: you can run /usr/share/apport/apport-gtk -c /path/to/crashfile
<apw> but that has #!no at the top
<pitti> ?
<apw> hmmm perhaps i fecked that up somehow
 * apw reinstalls
<pitti> apw: so is update-notifier itself dying, or is /usr/share/apport/apport-gtk not starting?
<pitti> $ head /usr/share/apport/apport-gtk
<pitti> #!/usr/bin/python
<apw> well hard to say of course
<apw> ok then somehow thats me thats typed it, doh
 * apw will retest
<soren> Could a friendly AA please accept the axis2c binaries?
<soren> libapache2-mod-axis2c, libaxis2c-bin, libaxis2c-dev, libaxis2c-doc, and libaxis2c0.
<seb128> soren: to universe?
<soren> seb128: universe is fine (for now).
<seb128> soren: done
 * soren hugs seb128 
 * seb128 hugs soren back
<shtylman_> evand: I am told you are working on the gtk side of ubiquity installer. I am dabbing a bit with the kde side. What are the major changes you plan to implement, so I can think about making the two similar in usability. Currently, I am working on making the timezone graph behave in a similar manner. Thanks
<evand> shtylman_: https://wiki.ubuntu.com/JauntyUbiquityUsability - should give you a pretty good idea of what I'm up to
<shtylman_> evand: noted, thanks...on a side note..I did an implementation for the kde side of the timezone map that lets you click on a band instead of the cities. I dunno if you have done that yet, but I was able to do it pretty easily after I figured out a way to use the actual images to help me
<shtylman_> evand: also, some of the things say done, but I really don't see them in the launchpad repo...do you keep a separate copy of the unmerged changes you have made, and if so where? thanks
<evand> shtylman_: The timezone map is implemented (there's a version in the archive, but you'll want to build from bzr), but do note that just the timezone band is insufficient information.  You need to ultimately be clicking on a city as you need DST information.
<evand> shtylman_: Everything that's done should be in the ubiquity bzr repository (lp:~ubuntu-installer/ubiquity/trunk)
<cjwatson> DST information> also country for the purposes of locale
<shtylman_> evand: gotcha, ok..I will check bzr, I might have just thought it was a carryover from previous versions and not a new feature so I might have missed it. And right, I tried the gtk one current in there and found that my biggest annoyance was that it gets the city closest to where you click versus the city closest to where you clicked in that timezone
<shtylman_> evand: my goal is to first be able to click on the timezone on the map, and then get the city closest to that in that zone, but it should be easy for me to implement it either way if I need to be consistent
<evand> shtylman_: that's fixed in bzr.
<shtylman_> evand: ok, cool
<evand> a simple debuild in the bzr root, then scp the resulting debs into a live CD environment and install ubiquity, ubiquity-ubuntu-artwork, and ubiquity-frontend-gtk
<shtylman_> is that the test procedure?
<evand> depends on the size of the change.  More often I'll just edit the files on the live CD and copy them out.
<shtylman_> gotcha...ive been editing on my machine and just not doing the actual final isntall step...although for testing I have to change some of the paths for it to work when its not installed globally
<evand> I'd do all testing inside the live CD, you don't want to get bit and accidentally lose a partition.
<shtylman_> true, but thats why I have external harddrives to take the pain for me :), but I will do some more testing inside the livecd environment now that you suggested it
<evand> If you don't already have a preferred virtualization environment, allow me to suggest KVM
<evand> good deal
<evand> shtylman_: by the way, you might want to hang out in #ubuntu-installer, and let us know what your bzr branches are so we can follow the progress
<soren> If something is in dep-wait, it should automatically be rebuilt once the package in question is available, shouldn't it?
<shtylman_> evand: will do
<ScottK> soren: Yes it will.
<ScottK> It takes some time to cycle through, so it's not immediate.
<soren> ScottK: Ah, I thought it was done as part of the ACCEPTing script or whatever type of magic wand is involved.
<ScottK> No, depwait packages get revisited on some periodic and then kicked to needs buiding of the dep is satisfied.
<soren> ScottK: Thanks. I'll just click the rebuild button myself.
<soren> Patience has never been a thing of mine.
<ScottK> You may not want to do that.
<cjwatson> rebuild => score 0
<ScottK> There's a soyuz bug where manual retries get scored to 0
<ScottK> Yep.
<cjwatson> I can't decide whether that's actually a bug
<cjwatson> it has the useful effect of preventing people DoSing the buildds with repeated retries
<ScottK> I filed a bug on soyuz earlier in the week and they accept it.
<cjwatson> since any developer can do that, and it's a lot less visible than repeated uploads
<ScottK> accept/accepted.
<cjwatson> their problem, then :)
<apw> pitti, perhaps you could cast an eye over https://code.launchpad.net/~apw/apport/suspend-resume-pt3 and see if that seems a resonable solution to the showing sensible text problem for suspend/resume
<ScottK> cjwatson: It's been a major hindrance for me getting the ports archs resurrected for KDE since there is a sequence things have to get built in.
<PecisDarbs> pitti: can be python be used in init.d script? one-liner for example?
<pitti> PecisDarbs: in principle yes, but you really shouldn't; it's horribly expensive
<pitti> PecisDarbs: also, you need to account for systems which have /usr on a separate partition, so you can't use it for rcS.d
<PecisDarbs> ok, then I have to try to do it in bash anyway
<pitti> PecisDarbs: what do you want to do?
<pitti> apw: will do after the meeting
<PecisDarbs> pitti: about that sl-modem-daemon init.d script - it has code which detects if there is standalone modem as ALSA device in system, but it doesn't detect for subdevice - which I have. Subdevice doesn't appear in /proc/asound/cards and it has harder to grep device number and subdevice number.
<pitti> PecisDarbs: hm, that seems like something which could also be done in postinst?
<pitti> it doesn't matter much if postinst is slow, but init script bites you on every boot
<cjwatson> hardware detection should be at run-time, surely
<pitti> (it's a little less tolerant to hardware changes, though)
<ScottK> TheMuso: Congratulations on a successful kernel build for hppa.
<PecisDarbs> I try to extract two numbers for such line - http://pastebin.ca/1336122
<Riddell> doko: I don't suppose you know anything about building apps with maven?
<PecisDarbs> number after card and number after device
<pitti> PecisDarbs: use awk or sed, they are much faster than calling python or perl
<cjwatson> if that format is reliable then you don't even have to use a subprocess at all
<pitti> PecisDarbs: first iteration:
<pitti> echo 'card 0: Intel [HDA Intel], device 6: Si3054 Modem [Si3054 Modem]' | sed -r 's/^card ([[:digit:]]+).*device ([[:digit:]]+).*$/\1 \2/'
<PecisDarbs> wow
<cjwatson> $ line='card 0: Intel [HDA Intel], device 6: Si3054 Modem [Si3054 Modem]'
<cjwatson> $ card="${line#card }"; card="${card%%: *}"
<cjwatson> $ device="${line#*, device }"; device="${device%%: *}"
<cjwatson> $ echo "$card $device"
<cjwatson> 0 6
<PecisDarbs> shell gurus :)
<PecisDarbs> thanks
<pitti> PecisDarbs: one thing, please call aplay -l with LC_ALL=C
<PecisDarbs> right, localization issues...
<pitti> mine says "Karte" and "GerÃ¤t" :)
<PecisDarbs> lol
<PecisDarbs> users in mine language sometimes want us, translators punch in the head because of translating command line stuff :)
<doko> Riddell: please ask Koon. I think our current advice for packaging apps using maven: don't use maven.
<Koon> Riddell: you want to build something or package something ?
<cjwatson> doko: *laugh*
<doko> cjwatson: ?
<cjwatson> "advice for using maven: don't use maven"
<lamont> Keybuk: fixing the git tree now - I was tired last night when I wrote the email...
<walters> doko: in fedora we have maven patches which cause it to work entirely offline and just look at local patches  (mvn-jpp); i think the debian java layout is unfortunately not the same as the jpackage one, but the patches are probably adaptable
<Koon> walters: we have our own effort under way
<Koon> http://wiki.debian.org/Java/MavenBuilder
<ScottK> pitti and slangasek: Can we do out Dx bugs in Universe discussion now?
<walters> Koon: yay, a cdbs plugin
<slangasek> ScottK: if you can tolerate some latency due to my attempts to acquire breakfast
<pitti> ScottK: sure; so you have some concern with applying patches?
<ScottK> OK
<Koon> walters: it's a slightly different design, with the same kind of problems in the end
<ScottK> pitti: My concern is that if we created a long term divergence from upstream we have a maintenance burden that MOTU is ill equipped to accept.
<walters> Koon: yeah
<ScottK> To the extent these things are incorporated in Universe packages, I think it should be upstream.
<jdstrand> mathiaz, slangasek: I figured I would review/handle the gnutls portion of the openldap regression. However, if it makes more sense for just mathiaz to handle it, I'll help in whatever way is needed
<ScottK> Alternatively if Canonical Dx will commit to maintain the packages, then I think my concern would be resolved.
<pitti> ScottK: they should indeed go upstream, no doubt
<Koon> walters: maven is orthogonal to the concept of linux distributions. we can hack around it, but in the end it could still fail.
<walters> Koon: yeah
<pitti> ScottK: in fact, the condition for applying those (to main as well) is that they are sent upstream and aren't Ubuntu specific
<Koon> Death to Maven!
<ScottK> pitti: So I don't see a point in having a bunch of "bugs" against packages.
<walters> Koon: i have hopes the modularity effort upstream will result in at least filesystem-level standardization of these things
<ScottK> These aren't actually defects, but a difference in design.
<pitti> ScottK: it's for having a place to discuss, track, and attach them, as well as xref with upstream bugs
<pitti> and it's still (arguably) an usability defect
<ScottK> pitti: It's even more arguable that aspects of the proposed Dx design are a usability defect.
<ScottK> If you want to start that conversation ....
<pitti> ScottK: sure :)
 * ScottK doesn't
 * pitti doesn't either
<ScottK> I think the most appropriate status is the Ubuntu task wontfix since it that's generally what will happen.
<ScottK> That doesn't stop some developer who feels motivated taking it on.
<slangasek> jdstrand: uploading the SRUs is easy, sorting the patch is the hard (and first) part :-)  I'm happy to see it fixed, whoever does the work
<pitti> ScottK: having the bug with a patch doesn't mean that we have to upload it immediately
<ScottK> It does, however, keep the expectation correct about where change will happen.
<pitti> ScottK: if upstream takes teh patch, then we can close it once we got a new upstream version, for example
<persia> pitti, There are a number of people who troll universe bugs looking for patches to upload: if a patch should not be uploaded, this ought be indicated.
<pitti> persia: well, if there are MOTUs uploading patches just because they are there, without reading the bug, then we have a bigger problem
<ScottK> I think linkage to a upstream bug task with the Ubuntu task wontfix expresses the general approach correctly.
<slangasek> in that case, it sounds appropriate to un-tag them patch if that tag is currently set?
<seb128> confirmed and wishlist would make sense
<slangasek> or is there a concern that people will find the patches anyway?
<ScottK> seb128: It's not a bug.
<ScottK> I actually haven't seen any with a patch.
<seb128> wishlist = change request
<persia> pitti, Not usually MOTU: it's more that it's one of the targets at which new contributors are pointed (go find some patches, test them, propose for upload).
<seb128> persia: well they ought to read the comments in a bug before uploading no?
<seb128> persia: should be easy to state there if something should not be uploaded
<ScottK> I didn't see anything so far in the bugs about this ought to be done upstream.
<seb128> or do we have people who upload without reading bug comments?
<pitti> persia: I see
<persia> seb128, Yes, they ought.  A comment saying "This bug is for upstream tracking" would cover my concern.
<ScottK> persia: I agree.
<mathiaz> jdstrand: I don't have the time in the next few days to sort out the regression
<pitti> and we shouldn't upload them straight away without the bug being filed upstream anyway
<persia> seb128, It's not upload, it's testing the patch, preparing a new candidate revision, pushing into the sponsors queue, etc.
<mathiaz> jdstrand: however I do hope to update openldap to 2.4.13 before FF
<jdstrand> mathiaz: well, it makes sense that I would do it, I'm fairly familiar with it. upstream seems to have settled on a solution
<Laney> Who's to say that upstreams will accept the philiosophy behind these notification changes?
<ScottK> pitti: I would also not want these bugs/patches upstreamed to Debian.
<slangasek> mathiaz: does 2.4.13 include changes to the gnutls code to bring parity with the openssl implementation?
<slangasek> mathiaz: I.e., explicitly enabling V1 sigs?
<slangasek> s/sigs/certs/
<ScottK> Laney: No one.  That's why we don't want to take on the possible long term maintenance of them in MOTU.
<jdstrand> mathiaz: honestly, it'll be a struggle for me to get it sorted out in the next few days too
<pitti> ScottK: seems you are very fond of actions in notifications :)
<seb128> what is this discussion about exactly?
<Laney> ScottK: Good. So do we go with each upstream's wishes then?
<seb128> refusing to do ubuntu changes to ubuntu packages to avoid work?
<slangasek> mathiaz, jdstrand: I don't think "next few days" is necessarily the expectation either, fwiw
<rtg> slangasek: a followup on bug #317270. For some reason it didn't get pushed to the git repo, so I missed it when I uploaded yesterday. I need to upload again to fix an armel FTBS, so it'll appear then. It ought to fix bug #320632.
<ScottK> seb128: It's about Dx filing bugs against Universe packages for their pet project.
<ubottu> Launchpad bug 317270 in linux "[Studio XPS 16] touchpad doesn't return from resume" [Medium,In progress] https://launchpad.net/bugs/317270
<ubottu> Launchpad bug 320632 in xfree86-driver-synaptics "tap-to-click and edge-scrolling broken in Jaunty" [Medium,Confirmed] https://launchpad.net/bugs/320632
<seb128> which are valid requests for ubuntu
<jdstrand> slangasek, mathiaz: rest assured it hasn't dropped off for me-- I'll get to it
<slangasek> seb128: er, if it's agreed that the patches should go upstream first, then such a refusal should be a no-op?
<seb128> if you don't want to work on those feel free to not
<ScottK> seb128: It's about not pushing maintenance work onto community developers that they are not resourced to handle.
<seb128> nobody force community people to do anything
<cody-somerville> pitti, The new notification system is pretty but it is difficult to see if your screen is black where it shows up (ie. console) and I often find that I move my mouse over it not to click through it but to find out *more* information.
<mathiaz> slangasek: I don't know if .13 has the gnutls fixes - .14 has them though.
<cody-somerville> pitti, It isn't clear where the notification originates from
<seb128> cody-somerville: those are bugs and should be channeled to the correct media which is not there
<mathiaz> slangasek: and IIUC upstream is in the process of pushing .14 out of the door
<ScottK> seb128: We have plenty of pointless diff in Universe already without making it work.
<slangasek> seb128: but increasing the number of deltas for universe packages increases the merge workload; I think it's legitimate to be concerned about who's taking responsibility for this
<ScottK> work/worse
<mathiaz> slangasek: I don't know it if that will be done before FF though.
<seb128> slangasek: whoever is doing the change is responsible for it usually
<jdstrand> mathiaz: if we are talking about jaunty, don't we already have the new gnutls patches from debian already?
<jdstrand> I haven't looked too closely, but thought I saw some patches
<slangasek> seb128: in reality, I don't think that's the case over the long term
<slangasek> mathiaz: well, we're talking about a major regression (bug), that doesn't need a freeze exception to get it fixed
<persia> seb128, That's often not the case in universe, where there is more significant turnover, and much less sense of ownership of packages.
<slangasek> mathiaz: but this is the first I've heard about the bug being fixed upstream - you've heard specifically that upstream is force-enabling V1 cert checking in gnutls in .14?
<seb128> there is only a bunch of those packages and a team of people paid to work on that, I fail to see what is such of an issue
<seb128> that's not like there was hundred of changes
<slangasek> seb128: who's paid to take responsibility for the packages in universe?
<ScottK> seb128: There is no team paid to work on these packages.
<slangasek> that's the open question here
<primes2h> pitti: Sorry about build-time stuff on debdiff.
<mathiaz> slangasek: no. I haven't heard anything that specific
<slangasek> mathiaz: ok; then .14 might be orthogonal...
<seb128> slangasek: the dx team said they would provide patches, they will probably maintain those too no?
<seb128> and if they don't that's only a couple of changes to maintain
<pitti> primes2h: don't worry, I figured it out :)
<seb128> we do that for lot of other things
<pitti> seb128: well, provide -> send to and argue with upstream
<seb128> people add random .desktop without translations to universe packages for example
<primes2h> pitti: Next time I'll check it better before posting...
<seb128> if you really want to discuss MOTU efficiency better to start on real unrequired efforts
<ScottK> seb128: AFAIK there are no Ubuntu developers in Dx, so even if they do all the patch work, it still afftect the sponsorship queue.
<persia> seb128, Well, yes, but that's because I like to launch apps.
<slangasek> seb128: hum, that sounds like an unfounded assertion to me - I think everyone would be satisfied if the DX team was committed to maintaining patches applied to universe packages for as long as necessary, but this is the first I've heard that such a committment might exist
<ScottK> seb128: IMO I am.
<seb128> persia: and you don't care about non english users
<seb128> come on, we are speaking about 15 packages or so
<ScottK> seb128: One can't add a non-existant translation.
<seb128> if you want 0 delta to universe just say it
<seb128> but that's not really such of an issue
<persia> seb128, I just have a different opinion than you about whether it's better to not have a menu item or have an untranslated menu item.  We've debated this before: let's not do it again now.
<ScottK> seb128: If Canonical will commit to maintaining the Universe diff for their Dx initiative, then I have no problem with it.
<ScottK> So far, Canonical has not agreed to do so.
<seb128> there is nothing canonical specific there
<seb128> those changes are for ubuntu consistency
<seb128> if there is MOTU who want to work on that why do you want to stop them? just because you are not interested in the changes?
<seb128> should I stop people to upload .desktop changes because I think those are wrong
<seb128> etc
<cody-somerville> I don't think ScottK is trying to stop anyone from doing anything.
<seb128> cody-somerville: it seems that he doesn't want of such changes in universe package because it means extra work
<cody-somerville> I don't think he is saying that either. I think he is asking a question: "Who will be responsible for the extra work?".
<seb128> who is responsive for any ubuntu change?
<ScottK-palm> Apparently I only get 2 hours of wifi @ McDonalds.
<seb128> the people contributing to ubuntu ...
<cody-somerville> seb128, and thats probably what will happen. However, it could very well mean that now because those packages require a merge, it might not get done as a lot of packages in universe don't get done in a cycle (just way too much to do).
<LaserJock> seb128: ultimately though MOTU is responsible
<seb128> right as for any change
<LaserJock> so we do need some concern about how things are going to be maintained, and commitments
<seb128> should we declare a 0 change to universe rule to minimize work?
<cody-somerville> No
<seb128> lol
<LaserJock> no, nobody said that
<seb128> who is commiting for all the changes people are randomly doing now?
<LaserJock> sometimes nobody
<LaserJock> and that sucks
<seb128> I can give you a list of change which add for no real win
<cody-somerville> But if someone was going to make a change to a universe package like the dx proposes, I'd expect to get some sort of commitment from them to maintain it.
<seb128> so how is that case different?
<slangasek> seb128: there have been ongoing conversations about this exact issue among MOTU before now
<LaserJock> because, I think, that we are trying *not* to do that
<seb128> I just think you pick the wrong target for this discussion
<seb128> those changes are for look and feel consistency
<seb128> and concern a small number of sources
<LaserJock> I would feel much better with the Dx team making some commitment to the Universe changes
<ScottK-palm> seb128: If Canonical wants a global design change implemented in Universe, they should maintain it.
<seb128> nothing to do with canonical
<LaserJock> I personally don't care either way on the change, so I'm not against the changes by any means
<LaserJock> sure it is
<seb128> the ubuntu team has decided to change the ubuntu desktop look
<ScottK-palm> Frankly the communication between Dx and the community has been and IME continues to be very poor.
<LaserJock> it's Canonical's team from what I can see
<seb128> canonical is not revelant there
<seb128> how is that revelant?
<seb128> it could be a community spec
<ScottK-palm> seb128: Where is the spec that approved this?
<LaserJock> because none of them are Ubuntu developers
<seb128> discussed at uds
<LaserJock> which means volunteers have to take care of it
<LaserJock> which can lead to more work and bitrot that we'd rather not have
<seb128> ubuntu members will decide to use those changes or not
<ScottK-palm> seb128: Discussed, but not in any regular session.
<seb128> if they do it will go to ubuntu
<seb128> right, and we will ship GNOME 2.26 too
<seb128> but there was no session about it
<seb128> and we didn't get specs about lpi changes either
<seb128> etc
<ScottK-palm> Yes, Gnome updates happen every time.
<seb128> don't try to make it looks like this is different of whatever has been made before or not an ubuntu change
<seb128> that's the same sort of changes as lpi
<ScottK-palm> I think it is very different.
<seb128> brb
<pitti> well, since this now seems miles away from the original discussion -- is it okay for everyone to open bugs for those, attach patches and upstream bugs, and decide this on a per-patch basis?
<seb128> re
<pochu> will those changes be forwarded upstream?
<seb128> yes
<pitti> pochu: absolutely
<pitti> pochu: I consider this as a precondition for applying them at all
<ScottK-palm> pitti and slangasek: I need to go and I think I've made my points.  Is wontfix in Ubuntu linked to an upstream task OK?
<seb128> no
<pitti> ScottK-palm: I object to this generality
<seb128> why wontfix in ubuntu?
<pitti> ScottK-palm: unconditionally marking all of them as wontfix is pretty pointless and not really justifiable
<seb128> ubuntu desktop will use the new notification for consistency having those changes would be nice
<pochu> for the couple of bugs I've seen, at least for one they provided a rationale on why the change is good for usability, so I think it wouldn't be too strange if upstream would accept the change if it was forwarded
<ScottK-palm> Because it's not the kind of change we should be doing.
<seb128> no reason to wontfix if somebody wants to work on this
<pitti> marking one as wontfix is okay if upstream rejects it, and it doesn't impact usability too much (or we don't care)
<seb128> it's not up to you to decide what other people want to work on
<pochu> that would mean there's no need to maintain anything
<pochu> seb128: pitti: cool
<ScottK-palm> seb128: wontfix doesn't stop people working on anything.
<pitti> but if upstream accepts the patch, then I don't see why it should be marked wontfix in ubuntu
<seb128> it gives the messages than change will not be accepted
<seb128> which is wrong
<LaserJock>  the point of wontfix on an Ubuntu task is to signify that we want it to go upstream first, then sync
<seb128> no
<pitti> since then we'd actively had to patch it out again, which would be nonsense
<seb128> that's not what wontfix means
<pitti> LaserJock: no, it isn't; it means that we don't want the change at all
<ScottK-palm> What it does is set an appropriate expectation that this is not something we would likely do.
<LaserJock> I think that's how it's being used
<seb128> or we can start wontfix 90% of the bugs on launchpad
<seb128> but that's something we want to do
<pitti> LaserJock: we have hundreds of open bugs with an upstream task which just wait for a fix trickling through upstream, after all
<seb128> you want universe application to not work nicely on the ubuntu desktop?
<pochu> LaserJock: not really, I use it as saying "we won't implement it"
<pochu> LaserJock: e.g. upstream disagrees, and we don't want to change behaviour, so we wontfix it
<pitti> pochu: but "we won't do the work" != "we won't change it when upstream does"
<ScottK-palm> seb128: If we ar
<pochu> pitti: right right
<ScottK-palm> urgh.
<LaserJock> pochu: I can see that if there's no Debian task
<pochu> pitti: I see "wontfix" as "wontfix upstream & in ubuntu", otherwise triaged forever sounds good
<pochu> pitti: so I'm fine with leaving the Ubuntu tasks opened
<seb128> wontfix = we will not accept such changes
<pochu> right
<LaserJock> no
<LaserJock> not exactly
<ScottK-palm> seb128: Not at all.
<seb128> that's how we use it for desktop right now
<LaserJock> so?
<seb128> well you can't say no
<LaserJock> desktop != MOTU
<ScottK-palm> It's not how it's generally ised in MOTU.
<LaserJock> we all have different triage/status rules
<ScottK-palm> used ...
<seb128> how do you use it?
<seb128> wontfix = ubuntu will not work on that?
<seb128> ie any bug sent upstream where you will wait for an upstream fix is wontfix?
<LaserJock> if there are multiple tasks then won'tfix directs where the work is appropriate
<ScottK-palm> seb128: For wouldn't accept the change, I'd use invalid.
<LaserJock> so an open Debian task and a won'tfix Ubuntu task means "do it in Debian"
 * ScottK-palm needs to go.
<persia> seb128, Rather, a bug which won't be changed in variance to upstream is set that way.
<seb128> LaserJock: so we should wontfix all the bugs forwarded upstream now?
<LaserJock> seb128: if we're just waiting for a sync, I think that would be appropriate
<seb128> ok
<LaserJock> but not a big deal as most of the time people get it
<persia> seb128, It's not the forwarding, it's forwarding with a statement that the Ubuntu behaviour won't vary from upstream.
<seb128> cool, can close some ten thousand bugs
<ScottK-palm> If you won't fix it in Ubuntu, then say so.
<pitti> that sounds like an entirely uncovered state, like "Waiting for upstream"
<LaserJock> but in the case where you're specifically trying to say "don't do this in Ubuntu, wait for Debian" then I think won'tfix is accurate and appropriate
<seb128> so basically you suggest keeping any bug we don't intend to fix in an ubuntu specific way as wontfix?
<persia> No.
<pitti> LaserJock: well, I disagree heavily, but it's also an entirely separate discussion
<seb128> ie close 99% of the bugs since we rely on upstream to fix most of the bugs
<LaserJock> pitti: no doubt :-)
<LaserJock> seb128: right, and we don't
<persia> The practice is that when we won't apply some change (even with a patch) until/unless upstream accepts that change, it gets set "Won't Fix".
<seb128> LaserJock: but you are suggesting that we should?
<LaserJock> seb128: heavens no
<persia> This is different from the set of bugs that are forwarded upstream, but for which we would accept a patch.
<LaserJock> you guys do what you want with your bugs
<LaserJock> but let us do what we want with our bugs
<seb128> persia: why wouldn't we accept a patch to make notification consistent on the desktop?
<LaserJock> seb128: if upstream rejects it I can see doing that
<seb128> LaserJock: I'm a MOTU too and can upload to universe, that's as much my bugs than yours
<persia> seb128, I'm specifically not arguing that: I'm only trying to define the practice.
<LaserJock> seb128: right ...
<seb128> LaserJock: upstream will not accept lpi changes should we not use that in ubuntu either then?
<LaserJock> seb128: and desktop bugs are as much mine as yours, but I respect your bug practices
<seb128> seems you are trying to enforce a "ubuntu should have no distro specific changes" rule
<LaserJock> no
<LaserJock> I'm saying let the people who are responsible for the changes decide what they feel they should take
<pitti> LaserJock: sounds again like the case-by-case basis :)
<pitti> (which I feel good about)
<pitti> much less abstract discussion
<seb128> right, me too
<seb128> wontfix is just wrong there
<seb128> it means "we will not accept patches to make this work"
<seb128> and there is no reason we should refuse patches than make things work correctly on ubuntu if they don't
<LaserJock> it makes sense to me anyway
<LaserJock> but I'm unlikely to be the person uploading it so ... :-)
<warren_> hi
<pochu> I don't think we should close those as wontfix
<pochu> waiting for upstream comments would be nice though
<LaserJock> it really doesn't matter
<pochu> I can imagine in many cases they will integrate the change
<LaserJock> I assume the Dx people will track how things are going and set appropriate statuses with MOTu
<LaserJock> the point of the won'tfix stuff would be to direct people to Debian
<LaserJock> so we don't get duplicative work or conflicts
<pochu> how is Debian related here?
<seb128> LaserJock: what debian has to do with that?
<pochu> Debian is not changing notification-daemon :)
<seb128> LaserJock: the notification daemon will be jaunty specific
<LaserJock> this stuff isn't going to Debian at all?
<pochu> LaserJock: it's not. it can go upstream though
<LaserJock> umm
<pochu> for "disable actions in notifications" changes
<LaserJock> but don't we usually get upstream through Debian?
<pochu> no
<LaserJock> so wouldn't it be appropriate to discuss such a change with them?
<cjwatson> we often send things directly as well, or instead
<cjwatson> in cases where it's really just more efficient to talk directly with upstream
<LaserJock> sure, if there's good relationships there, that makes sense
<persia> And in the case of things like GNOME, we often have a different integration cycle than Debian.
<LaserJock> sure
<pochu> or even when there are not. You just need to report a bug usually
<LaserJock> but generally in Universe we work tighter with Debian
<LaserJock> perhaps it's just the packages that are being changed
<pochu> well yes
<shankhs> does creating themes in ubuntu come under ubuntu development?
<pochu> but I don't like when people think that "forward upstream" means "forward to Debian"
<pochu> I mean, I prefer that you forward upstream or both upstream&Debian when it makes sense the latter
<slangasek> persia, ScottK: this idea of setting a task 'wontfix' to mean 'will not diverge from upstream' is alien to me as well; is this interpretation promulgated in the community documentation somewhere?
<persia> slangasek, It was for a while.  I'll try to track down a current location.
<LaserJock> it just makes sense to me
<seb128> to me wontfix = not something that should go to ubuntu
<LaserJock> right
<seb128> I let things I don't intend to work on open so anybody else pick those
<LaserJock> so it should be done upstream
<seb128> or by a contributor
<LaserJock> no
<LaserJock> that's the point of won'tfix
<LaserJock> would be to say, "this is what we'd like to do as a team"
<seb128> well why should not we let people who want to work on those changes do it?
<LaserJock> because it should go upstream
<persia> slangasek, https://wiki.ubuntu.com/Bugs/Status : The usage described is part of the first bullet, where something needs upstream confirmation.  Whether that is true in the case of this class of bugs is a separate discussion from this usage.
<seb128> what you want to do is universe applications no work correctly on the ubuntu desktop, that seems weird
<seb128> LaserJock: the notification deamon is ubuntu specific
<seb128> for now
<seb128> it will be suggest as a freedesktop project but nobody else will use it this cycle
<slangasek> seb128: which people are you referring to, and what is their long-term committment to maintaining this delta?  Fire-and-forget changes to universe packages are a real concern, MOTU have been struggling to keep this under control by encouraging good upstreaming practices, and the DX stuff is just one instance in the larger picture
<seb128> slangasek: I'm not referring to any people
<seb128> slangasek: but if there is 15 applications to patch so they work correctly on the ubuntu desktop I think there is no reason to not do it for maintainship cost
<slangasek> seb128: if there were a clear committment from the uploaders to maintain the delta, then I don't think there would be any issue here
<LaserJock> slangasek: exactly, thanks for putting it better than I could have
<slangasek> seb128: that's not the same thing as saying there's a committment to *shoulder* the maintenance cost
<seb128> welcome to open source, we don't have any committment
<persia> Or even from the patch authors, if they cannot upload today.  Doesn't really matter who, as long as someone claims they will either maintain it, or ensure it gets applied upstream.
<seb128> we ship lot of softwares which have unactive upstream, if you want to get a commitment that volunter will be there for ever doing the same job you can wait
<persia> seb128, Indeed, and there are a number of us who have packages like that.
<seb128> well that's not a reason to refuse changes which are useful
<slangasek> seb128: I think that's a poor excuse for endorsing the same kind of behavior within our own community.  "It's open source, there's no committments" is not exactly the motto the millions of users who depend on Ubuntu are looking for.
<seb128> again we are speaking about making ubuntu applications work correctly on the ubuntu desktop
<seb128> so you say you prefer having those not work correctly just because volunteer might not keep updating changes?
<LaserJock> I'd say yes
<seb128> ie, you opt for having things not working because it could create work
<persia> For a few months now, most of the universe sponsors have been rejecting any patches which don't include active submission upstream in an effort to reduce the volume of Ubuntu-specific patches.  I suspect the raised concern is a growth of that effort.
<pitti> that's a good policy indeed
<pitti> and nobody questioned that, AFAICS?
<pitti> (in fact, I do the same for main patches)
<persia> There's been a couple minor quibbles, and some stuff gets through, but there seems to be broad consensus.
<slangasek> seb128: also, a committment is not the same thing as a contractual guarantee
<seb128> well, there is a difference between useless changes
<seb128> and having ubuntu softwares working correctly on ubuntu
<seb128> I puzzled that you guys suggest just letting things broken because carrying fix has a maintainship cost
<persia> seb128, This is for *all* changes, regardless of perceived utility.  We don't currently have kvm on lpia and ia64 mostly because the person who was maintaining the patch stopped.
<seb128> well, if nobody is there to maintain the change and  that's an issue drop those
<seb128> but why refusing correct fix because they might be extra work later?
<slangasek> seb128: I don't think there's a consensus that "broken" and "fix" are the correct terms here; aren't we talking about consistent user experience, not about programs failing to function?
<persia> seb128, Refusing if the fix is not also pushed to other interested parties: not refusing because of the patch itself, and not requiring the fix to be applied upstream first.
<LaserJock> seb128: why is it hard to expect some commitment from the Dx team to maintain this stuff?
<pitti> slangasek: some might work pretty bad, for cases where programs spawn a lot of notifications with actions, which you then need to click away (since they turn into dialogs)
<seb128> LaserJock: because you will not get those
<pitti> the bar should at least be set to filing the patch upstream and discussing it there
<seb128> slangasek: those are easy changes in a few packages, I'm really surprised that you argue that those applications should go to an ugly fallback mode rather than work correctly just to avoid to maintain some distro changes
<LaserJock> seb128: why not? it's their changes
<seb128> LaserJock: because they don't have the ressources for that
<cjwatson> the DX team ought to at least be on the hook to discuss their change, although not necessarily to maintain them; we don't necessarily expect people who submit patches upstream to maintain them forever either
<LaserJock> seb128: they shouldn't make changes they can't maintain/support!
<cjwatson> but we do expect them to justify them upstream and make adjustments as request
<cjwatson> ed
<cjwatson> LaserJock: see my comparison with any other kind of patch submission upstream
<pochu> I see a problem with packages that are currently in sync with Debian being patched solely for this purpose; then they won't be autosynced anymore and somebody will need to merge them
<cjwatson> we do not, in general, expect patch submitters to maintain the change once it is accepted
<cjwatson> (upstream)
<pochu> otherwise, for packages that have Ubuntu delta, I don't think this is a major problem
<seb128> pochu: again we are speaking about a few applications, we do it for lpi already for example
<cjwatson> I think it's entirely reasonable to ask the DX team to submit upstream, but what I've been hearing is that that's what they're going to do?
<seb128> what is the point of doing a distro if you can't make distro changes to have things working nicely and be consitant on your distro
<slangasek> seb128: I'm not arguing that; I'm trying to get you to understand the other side of this argument, which is that little changes turn into a big unmanageable pile of work if there's no corresponding committment of resources from the people who want these changes
<pochu> seb128: right, but for lpi changes we already have a delta or are ahead of Debian
<pochu> at least AFAIK
<seb128> pochu: in fact the lpi changes are higher in number than the notification ones will be
<cjwatson> anyway, I suppose I shouldn't dive into a debate when I have to run; bye ...
<pochu> seb128: but we don't have lpi patches in universe packages that would otherwise be in sync with Debian, do we?
 * slangasek waves to the back of cjwatson's retreating head ;)
<seb128> pochu: no, but we have those for packages in main that would be in sync otherwise, how is that different?
 * pitti is off for today, too
<pochu> seb128: do we?
 * seb128 should go too, that's a pointless discussion
<pochu> seb128: I'm not opposing the patches. but I understand concerns about "fire & forget"
<pochu> OTOH "fire & forget" is what we do a lot of times in Ubuntu...
<slangasek> seb128: I think the difference is that there's an expectation that when Canonical makes changes to packages in main, Canonical will provide manpower to maintain these packages on an ongoing basis
<pitti> it seems that people are discussing about the extreme ends of "immediatly apply" vs. "mark as wontfix and reject"
<seb128> pochu: yes, look at the GNOME packages, there is quite some ones where the current version is 2.24 and that we could sync, file-roller, gedit, etc
<pitti> why can't we at least have the patches in our bug tracker, and have maintainers decide for themselves?
<seb128> slangasek: how canonical is revelant there?
<pochu> pitti: agreed
<seb128> slangasek: that's only one contributor
<seb128> the contributor could be whatever loco team writting patches
<slangasek> seb128: frame it as "core-dev", then; whichever way you split it, the per-package resources available for main are significantly greater than for universe, so deltas are more tolerable in main
 * seb128 waits for archive reorganisation
<persia> pitti, Main issue is that we don't really have maintainers.  Personally speaking, I'd rather not have patches in the bug tracker that weren't expected to be either applied or rejected as soon as someone got around to looking at them.
<seb128> I can list you some packages in main which have nobody looking at them and some actively maintained in universe
<seb128> I don't think the component argument is revelant there
<LaserJock> seb128: well, you're a MOTU, you maintain it then
<LaserJock> hmm, that could sound snotty
<LaserJock> I didn't mean it that way
<jdong> snooty?
<LaserJock> I meant snotty
<LaserJock> but since it's essentially a Desktop team change, perhaps the Desktop Team could commit to maintaining it?
<highvoltage> heh. Ferris Beuler joke!
<seb128> LaserJock: why do you need somebody to commit to maintain it?
<seb128> we have lpi changes in several packages and nobody commited to maintain anything
<LaserJock> seb128: well, because it's an Ubuntu specific change
<LaserJock> and that's bad, IMO
<pochu> I think it's been already mentioned, but how many packages are we talking about?
<seb128> same for random desktop files motus keep adding
<seb128> LaserJock: what is the purpose of a distro if you can't make distro changes to have your distro be consistent
<LaserJock> just because it *has* been done doesn't mean that's the way we'd like it
<LaserJock> you *can* make distro changes
<persia> seb128, Well, in the case of those, most of them are submitted upstream and to Debian (and the majority are now carried in Debian).
<seb128> no you can't
<LaserJock> but you need to be responsibel for them!
<seb128> wake up that's not how opensource work
<LaserJock> whatever
<seb128> look at upstream project, people come contribute, get busy, and move to other things
<LaserJock> sure
<seb128> that's not a reason to reject contributions
<seb128> just because they might get busy one day
<LaserJock> yes, it is
<persia> No, it's not.
<LaserJock> if the team says "we're not sure we can maintain that"
<seb128> welcome to the "do no change ever"
<LaserJock> they have every right to reject the change
<slangasek> seb128: "might get busy one day" - that's a mischaracterization of the issue
<seb128> LaserJock: that's not like motu was having universe under control
<seb128> there is too much work to do for the number of people
<persia> The question isn't about rejecting contributions.  It's about avoiding distro delta where possible by integrating with mainline development.  Some delta is inevitable.
<seb128> well, delta to having thing work on our distro is useful
<LaserJock> seb128: right, so we try to be smart about what work we make for ourselves
<seb128> ok, forget about that
<seb128> I'm going to apply those changes and to maintain those, happy?
<seb128> where maintain means I will probably have time every 3 years to reply to emails about it
<LaserJock> well, I would prefer the Dx team did it because you are so busy
<seb128> that was an ironic comment
<LaserJock> that's why I asked if there's any commitment from them
<LaserJock> they shouldn't be making changes they can't maintian, IMO
<seb128> you don't have anybody in motu who declare to be responsive for the changes done
<seb128> motu should never do any change either
<slangasek> MOTU collectively are responsible for them
<seb128> and they will be responsive for those as for any other change
<LaserJock> I take responsibility for every upload I make
<seb128> and what if you run away next week or get a new job or for whatever reason stop contributing?
<slangasek> which is why, when it appears that someone is making a change and expecting the rest of the MOTU to take responsibility for the ongoing work, there's resistance
<seb128> that's life
<LaserJock> then I will step down right
<seb128> does it mean you should stop you doing changes?
<LaserJock> and hand my responsibilties off
<persia> seb128, That'd be a violation of the Code of Conduct, unless there was a transition effort.
<seb128> persia: what do you mean?
<slangasek> seb128: again, you're mischaracterizing the problem.  There's a difference between not being committed, and being unable to fulfill the committment due to changing circumstances
<seb128> come on that's open source, people have life, they contribute when they can and sometime get busy, you want to track them down now when they do?
<LaserJock> seb128: that whole "Step down considerately" paragraph
<seb128> slangasek: we always do things in a best effort way
<pochu> looks like it's just 12 packages: https://bugs.edge.launchpad.net/ubuntu/+bugs?field.tag=dxteam
<persia> seb128, Part of the Code of Conduct is that we will step down gracefully, and hand over any resposibilities or tasks if we leave.  That includes responsibility for uploads.  Most of those who were active and have faded away have asked others to care for their packages that had significant unavoidable delta in universe.
<seb128> persia: ok, we don't live in the same opensource world
<slangasek> seb128: yes - but where has anyone agreed to make that effort?
<slangasek> for the set of changes in question
<seb128> slangasek: well, whoever writes the patch make the effort to get the thing done
<seb128> when I write a patch for GNOME I don't agree to update the changes when they reorganize their code either
<slangasek> now, if the usability is really as horrible as it sounds, then this falls under the general "bugfixes" umbrella and I'm of the opinion that it's reasonable for MOTU to collectively shoulder the additional workload
<seb128> that's not how opensource work
<seb128> I sponsor ton of changes without asking for commitment for the patch submitters
<seb128> for -> from
<slangasek> seb128: but if you write a patch and GNOME reorganizes their code before it's accepted, it's your responsibility to rewrite your patch to get it accepted, not upstream's
<seb128> slangasek: ok, that's my point
<seb128> slangasek: well, but what you ask there is for people to commit to update their fixes for ever, who is wanting to commit to do that when fixing a bug?
<seb128> when I fix a bug I usually send a patch
<seb128> and switch to something else
<persia> slangasek, Completely agreed: a bug is a bug.  I'd like to see the patches sent upstream as well, but delaying on acceptance is dependent on the bug/enhancement determination.
<seb128> persia: there is no upstream there ...
<slangasek> seb128: right; I think the disconnect here is that you've been approaching these as "bugfixes", and others have been assuming "enhancements"... :)
<seb128> persia: that's like waiting for upstream to take launchpad integration changes
<pochu> what will happen if a package isn't patched to not display actions? will the notification keep working, just without the button?
<slangasek> so instead of making the case for why these are important bugfixes that it's warranted for universe to carry a delta for, we've wound up down a rathole discussing Principles of Open Source Contribution :)
<seb128> slangasek: I was not sure of the discussion, I just disagree about MOTU wontfix useful changes just because they don't want to maintain those
<seb128> pochu: no, it will have some ugly fallback mode really annoying
<persia> I'm confused.  At the beginning of the discussion, it seemed like we were talking about patches that were sent to some upstream and waiting on discussion.  If that's not the case, then they are indeed unavoidable distro deslta.
<slangasek> seb128: maintaining the changes is a collective responsibility, so FWIW I think it's reasonable that deciding to accept the delta is also a collective decision
<seb128> persia: those changes can go upstream though upstream have no strong reason to take those since their implementation has no issue with the current way to do thing
<slangasek> which is different than saying I think the delta should not be accepted in this case
<seb128> slangasek: what struck me there is that ubuntu people argue that universe applications should look ugly on ubuntu just because they don't want the project to carry a few liners changes
<persia> seb128, Ah.  Thanks for the explanation.
<LaserJock> seb128: I don't think anybody said that
<slangasek> seb128: there's an awful lot of stuff in universe that looks ugly, for reasons unrelated to the notification spec :_)
<seb128> persia: the upstream notification daemon display action correctly, the ubuntu one will not but fallback to something annoying and ugly (ie opening dialogs for example)
<persia> seb128, At least I'm not arguing that universe applications should look ugly, but only that if someone uploads something, they should take responsibility for ensuring that the outstanding delta is ported forward in the future.
<seb128> slangasek: and we usually don't refuse patches to fix those things
<slangasek> seb128: if it meant redesigning upstream's UI, I expect we would
<LaserJock> if somebody were to port a GTK1 app to GTK2 I'd tell them to go upstream
<pochu> seb128: huh, either we fix everything or we change that to not open a dialog... I'd hate if everytime a song is played, a dialog is opened ;)
<seb128> LaserJock: did you read what I just said?
<seb128> pochu: that will open a dialog, the discussion is wether we want the few line patch to not open a dialog
<LaserJock> seb128: yes, we do sometimes refuse fixes because they aren't very maintainable and should go upstream
<seb128> which is what people are resistant to
<seb128> LaserJock: there is no upstream there, grrrr
<LaserJock> seb128: sure there is
<seb128> LaserJock: no there is not
<seb128> LaserJock: this notification daemon is new ubuntu code
<LaserJock> right
<seb128> it's different of the upstream one
<LaserJock> but the change comes from Dx and the packages we have to change have upstreams
<seb128> why should upstream change their code to work on an ubuntu specific daemon?
<LaserJock> well, frankly that's why you don't *do* stuff like that in a distro
<LaserJock> but that's somewhat beside the point
<pitti> seb128: please note that the fd.o libnotify protocol, as it is, doesn't guarantee availability of actions
<pitti> seb128: also, the change is being made for an usability argument, not just because of our daemon
<pochu> LaserJock: the problem is that upstream may not accept it as their code still works with a vanilla notification-daemon. But then if we don't patch it, it will look ugly / loose some functionality
<LaserJock> pochu: sure
<LaserJock> again, I'm *not* against the change
<pochu> then?
<LaserJock> I'm against a dump-and-forget mentality by Dx
<pochu> changes are going to be forwarded upstream
<seb128> LaserJock: there is no such mentality
<pochu> LaserJock: I see that mentality everyday in jaunty-changes
<seb128> you are the one assuming there is one
<LaserJock> seb128: you *told* me there was no commitment
<persia> pochu, That's not an excuse: that's a target for correction.
<pochu> persia: then we need specific maintainers for every package
<LaserJock> Dx is making a change that we would not have otherwise
<LaserJock> so I do expect some commitment from them on at least helping us maintain it
<LaserJock> when we need merges would they be willing to help with that?
<seb128> LaserJock: commitment is strong, we work on a best effort basis usually
<pochu> I hope so
<LaserJock> ok, so are they going to put effort into it or no?
<LaserJock> my impression was that they weren't
<seb128> that's a different question than commitment
<seb128> ask them
<pochu> if you do a merge and the upstream code has changed so much as to make the update non-trivial wrt the notification patch, I'd hope the Dx guys to lend a hand with the patch update
<seb128> I'm wanting to put some effort in it
<seb128> but I will not commit to do any work
<LaserJock> pochu: exactly
<seb128> I've enough to do
<ogra> LaserJock, so if you were the new upstream for a new notification system that required chnages to an app, would you wirte patches for all apps in the first distro that uses your system over the existing one ?
<seb128> and I work on best effort basis
<persia> pochu, I don't follow how the one leads to another.  If I make a change, I'll take responsibility for porting that change, or getting it upstream, and expect that if someone has a question about a change I made when making their change, I'll be asked.  I don't care if someone else works on a package I changed: I think that's a good thing, but the individual change is my responsibility.
<LaserJock> ogra: no, but that's not the case here
<ogra> sure it is
<seb128> pochu: we agreed to just drop the patch in such case if they don't update it
<LaserJock> not it isn't
<LaserJock> the distros would have a choice whethe to accept the notification system
<ogra> and ubuntu chose to
<LaserJock> and they are unlikely to do so until the apps support it decently well
<pochu> we do integration work all the time
<pitti> apw: the change needs some work, _("text") + self.report['FlagFile'] doesn't really work i18n wise
<LaserJock> in this case the distro *is* the upstream and we have no choice
<pochu> I really can't figure out what's wrong with patching 12 packages to work with the new system
<persia> seb128, That addresses all the concerns: adding a patch with a plan to drop it if not accepted is a committment to making sure the package continues to work long-term.
<pitti> apw: and we need to apply the same change to the qt version
<ogra> LaserJock, canonical != ubuntu
<LaserJock> so they tell me
<apw> pitti, thought you'd say that, whats the right way to fix that?
<apw> there is a qt version?
<pitti> apw: I need to run now, but unless you beat me to it I can try and look into it on Monday
<ogra> this system wasnt developed by the ubuntu distro team it has its own upstream ...
<ogra> totally distinct
<apw> pitti, will see how i get on, and sync with you on mon
<pitti> apw: I'd check the value of self.report['FlagFile'] and based on that, use two different strings
<LaserJock> ok, then can Ubuntu refuse it then?
<apw> ok
<jcastro> LaserJock: at the minimum the DX patches sent to gnome upstream (or whatever) should be linked to the lp bug filed in ubuntu. I noticed that today and ask tedg to let the DX people know to do that.
<pitti> apw: also, the label in the glade file that you changed is still marked as translatable, but now just contains markup
<LaserJock> I mean, I'm really not against the change. I think all 12 apps will end up patched
<pitti> apw: that's fine, just remove the translatable="yes"
<LaserJock> but I don't like Canonical deciding something and then expecting MOTU to "just deal with it"
<LaserJock> I'm hoping that's not what's going on
<jcastro> LaserJock: well, if the bugs are linked we can at least keep track, banshee upstream for example accepted the patch
<LaserJock> and mostly I'm happy with it
<seb128> LaserJock: again there is no canonical there but ubuntu as a project and distro
<LaserJock> whatever
<jcastro> it's an easy fix, filed in lp, filed upstream, and then we tag it and link it.
<seb128> LaserJock: who contributes should not be an issue and ubuntu is still free to accept changes or not
<LaserJock> this is Canonical's team, I don't see how you get around that
<LaserJock> but you could do s/Canonical/Ubuntu team that's not MOTU/ if you like
<pochu> pitti: do you have a link to that fdo spec?
<LaserJock> the point is about how orthogonal teams in Ubuntu should work on things
<LaserJock> and I generally feel like "deal with it" is not a great attitude
<seb128> LaserJock: that's not really team revelant, motus dump work on other motus all the time
<LaserJock> hopefully that's not what's going on, but saying that Dx has no commitment to the changes they make in Universe doesn't sound encouraging
<seb128> some upload libraries soname changes which need transitions, etc
<LaserJock> seb128: that's vastly different though
<seb128> I've for sure no commitment to rebuild the whole archive because I do a soname change
<seb128> I do try to do rebuilds though
<pochu> pitti: I think if I point upstream to it for one of the affected packages, he won't have problems in making the action conditional to whether the daemon has actions support or not
<LaserJock> that's team work, so team members are accountable to other team members
<james_w> pochu: it's a galago spec, not fdo at this point
<james_w> pochu: it is *the* notification spec though still
<LaserJock> anyway, I don't think there's much disagreement here
<directhex> galago?
<LaserJock> 12 packages isn't much work
<directhex> o_o
<pochu> james_w: ah, thanks
<james_w> http://www.galago-project.org/specs/notification/0.9/index.html
<pochu> james_w: http://www.galago-project.org/specs/notification/, right?
<pochu> :)
<james_w> you got it
<directhex> i have a maintainer who wants to RM the galago bindings for mono, due to lack of users
<pochu> ah cool
<pochu> notification-daemon's upstream wrote it
<james_w> directhex: does banshee use them?
<LaserJock> if MOTU end up having problem maintaining the diff and nock on Dx's door I hope they'd be willing to help
<pochu> so
<directhex> james_w, no. nothing does. except beagle, optionally
<pochu> these are all upstream bugs
<pochu> we can't forward them upstream and fix them in Ubuntu at the same time
<james_w> pochu: the ones currently reported are, yes
<directhex> james_w, iirc banshee uses its own notification thing, due to lack of features in the conventional gtk methods
<pochu> "This functionality may not be implemented by the notification server, conforming clients should check if it is available before using it"
<james_w> pochu: though currently minor as there is only one implementation of the daemon so far
<pochu> james_w: but bugs nevertheless :)
<persia> pochu, Why not?  I'd think that's the best way to fix a bug.  Fix it in Ubuntu, and push the patch upstream.
<Adri2000> slangasek: any change coming in debian we should wait for? or can we merge now? (do you want to do the merge?)
<pochu> persia: so we can fix all these bugs in Ubuntu
<seb128> LaserJock: it was agreed that if patches are not trivial to update and they are not responsive we would drop those
<seb128> LaserJock: meanwhile they is no real reason to refuse written patches
 * pochu files a bug to one of his upstreams
<seb128> LaserJock: that makes applications look better meanwhile and you can drop that later if required
<slangasek> Adri2000: there will be an upload to unstable soon, which will make the merge a bit easier since it will show up in MoM then :)
<persia> pochu, I've not looked at the specific bugs, but I don't see any reason why not.  I especially like your suggestion of trying to determine what sort of support is available for multiple code paths.
<james_w> pochu: if it is a C project then see the goobox bug for a patch that queries the capabilities
<Adri2000> slangasek: okay
<pochu> james_w: do you have an example for Python apps?
<james_w> pochu: not yet
<pochu> james_w: ok, let me know if/when you know of one. Will be helpful to my upstream :)
<directhex> james_w, and if banshee loses its actions in its notifications, i'll cry.
<devfil2> pochu: emesene?
<james_w> pochu: 'actions' in pynotify.get_server_caps()
<james_w> pochu: after pynotify.init(...
<pochu> devfil2: decibel-audio-player
<devfil2> pochu: ok
<pochu> james_w: thanks, I just found it too ;)
<pochu> ok, forwarded upstream
<pochu> the other one would be Liferea
 * pochu check the C patch
<savvas> are .save files in /etc/apt/sources.list.d/ ignored?
<slangasek> I wouldn't expect so
<savvas> hm.. I think Software Sources adds .save files in there, let me check again
<savvas> yep
<cody-somerville> I think only files ending in .list got parsed
<cody-somerville> *get
<savvas> http://paste.ubuntu.com/117765/
<savvas> ah .list files
<savvas> thanks cody-somerville ! :)
<lamont> Keybuk: I'm planning to push 2.14.2 to jaunty - does that make sense for the basis of your stuff?
<Keybuk> sure, that'd be good
<Keybuk> Karel hasn't made public his topic/blkid to master push
<devfil2> Keybuk: can I work on uswsusp merge? It's a new upstream release
<Keybuk> devfil2: you can do whatever you like ;)
<Keybuk> you don't need my permission
<Keybuk> obviously things may change once I'm Emperor of the World
<devfil2> Keybuk: I think it's good to ask the last uploader if you want to work on a merge/sync
<lamont> Keybuk: I thought that happened with either the udev or upstart upload
<Keybuk> devfil2: I uploaded it last?
<Keybuk> lamont: needs a util-linux-ng 2.15 upload first ;)
<devfil2> Keybuk: yes, DaD reports that you are the last uploader
<devfil2> you did a rebuild as I can see
<slytherin> can any archive admin please process sync bug 326172? I am waiting for it to process fop merge.
<ubottu> Launchpad bug 326172 in xmlgraphics-commons "Please sync xmlgraphics-commons 1.3.1 (universe) from debian experimental" [Wishlist,Confirmed] https://launchpad.net/bugs/326172
 * ScottK just got back and read the backscroll.  He thinks it's just as well he had to go ...
<ScottK> james_w: I read your changes to the Debain Import spec and I think they are a definite improvement.  Thanks.
<cody-somerville> ScottK, McDonald's kicked you out?
<ScottK> cody-somerville: Only two hours of free wifi on one arch card per day.
<ScottK> I had some other stuff to go do anyway.
<LaserJock> kees: regarding smarty MIR, you really need the full templated wiki page for something that's already in Main?
<ebroder> Hmm...jdong says he uploaded a new version of xen-meta yesterday to hardy-backports, but I don't see it at <https://launchpad.net/ubuntu/+source/xen-meta>. Where should I watch to track the progress of the package?
<kees> LaserJock: it's part of the process, and is a nice place to have a historical detail about the package, yeah.  will you have time to write it up?
<jdong> ebroder: it is in the SOURCE NEW queue awaiting archive admin approval
<jdong> ebroder: all manually uploaded backports require intervention of the archive admins
<LaserJock> kees: I guess so. I thought I was pretty thorough in the bug report but I can add the usual upstream/debian stuff
<LaserJock> kees: I'm not a PHP person so I don't think I can really audit any of the code myself
<ebroder> jdong: Ok. For my own curiosity, is that listed on a website somewhere (I do a lot of work with Debian packaging, but very little work with what the upload process looks like)
<kees> LaserJock: yeah, no audit needed.  just getting the record of CVEs, bugs, activity level, etc.
<LaserJock> kees: k, will do right now
<jdong> ebroder: is the queue, or is this process?
<ebroder> The queue
<kees> LaserJock: great, thank you!
<jdong> ebroder: I think it is supposed to show up at https://edge.launchpad.net/ubuntu/hardy/+queue?queue_state=0&queue_text=
<jdong> https://edge.launchpad.net/ubuntu/hardy/+queue?queue_state=1&queue_text=
<jdong> that one
<ebroder> Cool. Thanks
<Keybuk> gnargh! who took away Alt+F2
 * Keybuk shakes his fast
<andersk> Run ccsm and activate the Gnome Compatibility plugin.
<Keybuk> ccsm is not installed
<andersk> compizconfig-settings-manager package.
<ivoks> hoce netko firefox-3.1.xpi?
<ivoks> ups...
<ScottK> jdong and ebroder: Accepted.
<jdong> neato :)
<ScottK> jdong: Next time please Fix Committed and subscribe ubuntu-archive.
<jdong> indeed, my bad.
<LaserJock> kees: question on CVEs. There are 14 in the cve search, but most seem to just sort of indirectly mention smarty
<LaserJock> kees: do you just want the ones where they say the vulnerability is directly in smarty?
<kees> LaserJock: whatever is easiest
<kees> LaserJock: just having a pointer to it is a good start
<LaserJock> kees: well, am I supposed to be actually discussing these or is it merely informative for you?
<kees> LaserJock: in a perfect world, the MIR would describe how all CVEs against smart are closed.
<kees> e.g. if upstream has a list of fixes, etc.
 * ScottK remembers the clamav MIR "Yeah, there's a lot of them, but we ought to suck it up and do this anyway".
<calc> grr at&t can't actually install the faster internet that the tech claimed they could, i'm too far out for the other service as well
<calc> max distance is 3000ft and i am apparently at 4000ft for that service
<calc> so i will be stuck with either slow service or have to switch to comcast :\
<ScottK> No Verizon where you are?
<calc> ScottK: no verizon anywhere nearby
<calc> ScottK: i think the closest place verizon has fios is about 250mi from here
<calc> at&t is the ilec here unfortunately
 * ScottK is a big fan of FIOS.
<calc> if i moved to another house i could get 18/1.5 from at&t, but where i currently am
<calc> and comcast doesn't even have their fast speeds yet in houston aiui
<ScottK> Before I moved and had DSL, I found third party DSL providers could do faster than the telco.
<calc> but it would be a little faster than what i have now (3.0/0.5)
<calc> ScottK: this issue is a line length problem, i am 16K ft from the dsl location and 4K ft from the higher end equipment
<ScottK> If megapath dsl serves your area I highly recommend them.
<jsmidt> If I have a package which doesn't have a version number yet, it is just a git snapshot, but I would like to pakage it, what is the naming convention?  foo-git20090213?
<calc> the only way i could get higher speed is if they rerun my line from the telco building, which is very unlikely :(
<slytherin> jsmidt: foo-0+gitxxxxxx
<jsmidt> slytherin, thanks
<calc> ScottK: i'm going to call at&t and ask the sales group if there is any way to get it fixed they want to sell this new tv setup but my line is too far away
<ScottK> Good luck.
<ScottK> If there's a buildd admin about, it'd be nice to have a retry for soundtracker on hppa.  The current FTBFS predates the LP retry function and so I can't do it via the GUI.  I assume that's why anyway.
<ScottK> Being able to remove libdb4.5 is blocked on this currenlty.
<LaserJock> kees: hmm, yeah. moodle's smarty is older than our dapper version
<LaserJock> kees: I think we'll be getting rid of some vulnerabilities ;-)
<kees> LaserJock: yeah, no doubt at all.  :)
<Mithrandir> ScottK: given-back on hppa
<ScottK> Mithrandir: Thanks.
<Mithrandir> ScottK: you're aware it FTBFS on armel too?
<ScottK> Mithrandir: I wasn't.  The hppa FTBFS was the only one where the obsolete binary still depends on the old libdb version.
 * ScottK isn't particularly interested in soundtracker.  ... trying to excise cruft.
<LaserJock> kees: secunia searches suck :/
<Mithrandir> ScottK: ah, ok.
<ScottK> Now that you mention it, I looked and I suspect a retry would work now.  I'll press that button.
<ScottK> There's also something odd going on with qt4-x11 on sparc.  It was building on artigas when artigas timed out last night.  Since it came back it's built partway twice and then (AFAICT) gone immediately back to Needs Build.  I'd be interesting in the log if it's failing so we can get it fixed.
<kees> LaserJock: yeah :(
<LaserJock> kees: I tried smarty and Smarty and got nothing but I then found a link to one that had "Smarty" in the title
<LaserJock> go figure
<sbeattie> ScottK: bug 318866 verified.
<ubottu> Launchpad bug 318866 in kdeutils "printer-applet does not display when new printers get configured" [Undecided,Fix committed] https://launchpad.net/bugs/318866
<Riddell> yay!
<LaserJock> kees: all yours :-)
<kees> LaserJock: cool, thx
<ScottK> sbeattie: Great.  Thanks.
<ScottK> pitti: I believe that KDE 4.1.4 is fully verified, so we're ready to copy it to intrepid-updates.  All the bugs are tagged kde4.1.4 and have intrepid tasks open for it.
<calc> grr at&t can't do anything to fix it unless they get a lot of complaints :\
<LaserJock> calc: a shell script?
<LaserJock> :-)
<bryce> interesting; LP seems to be cutting off at displaying 80 comments
<TheMuso> ?c
<bryce> wish it was the 80 newest comments instead of the 80 oldest
<TheMuso> ScottK: thanks
<TheMuso> At least we have a kernel for all ports now. I expect sparc to build, so I can now move onto getting other bits updated.
<sistpoty> Riddell: around...? would you agree to act as delegate for motu-release for universe kde package for jaunty again?
<Riddell> sistpoty: sure
<sistpoty> Riddell: thanks a lot!
<Lure> sistpoty: you have ScottK there too...
<sistpoty> Lure: but I plan to abuse him for server again :P
<Lure> sistpoty: good plan ;-)
<sistpoty> superm1: how about you acting as delegate for mythbuntu for motu-release for jaunty?
<sistpoty> (again)
<sistpoty> cody-somerville: same question for you in regards to xubuntu?
<sistpoty> asac: and you for mozilla? I recall we had a backup... who was it again? fta? (sorry for my lacking memory)
 * calc might be able to get on a at&t test group, waiting on phone to find out
<sistpoty> ogra: up for ubuntu-mobile motu-release delegate again?
<sistpoty> ScottK: would you want to go for -server again?
<ScottK> Sure.
<sistpoty> excellent, thanks!
<sebner> sistpoty the organisation horse/talent :D
<sistpoty> sebner: haha
<calc> gah no timeline available for when they will be offering the test service
<calc> they only offer uverse with 27mbps sync speed currently, so you have to be really close to the office :-\
<calc> doesn't matter what speed you pay for they sync it at 27mbps so you can't get it past 3000ft regardless of if you want 1mbps or 18mbps internet
<ebroder> Should I subscribe...ubuntu-archive to bug #216761 to get it out of the unaccepted queue?
<ubottu> Launchpad bug 216761 in xen-3.3 "errors in xendomains init script" [Undecided,Confirmed] https://launchpad.net/bugs/216761
<ebroder> (Err...unapproved, but whatever)
<maxb> There's no mention on wiki.ubuntu.com/StableReleaseUpdates of a need to subscribe ubuntu-archive, so I suppose the fact that it's in Unapproved at all is enough for it to be on their radar.
<ebroder> One might hope as much, but it has been there for a non-trivial amount of time
 * ScottK looks
<ScottK> ebroder: The SRU team is subscribed.  That's the appropriate team for htat.
<ebroder> ScottK: Ok, thanks
<bryce> kees: I have my fglrx system up and good to go, how can I help you on 323327 now?
<Kakinho> :P
<Duff> Â»mneptokÂ«: plizzz private?
<directhex> don't you *hate* that?
<savvas> eh?
<mneptok> that's a big red "NO GO," Houston.
<savvas> oh, I thought directhex was referring to valentine's day :P
<kolby> how important is the python programming language?
<ScottK> 42
<sistpoty> heh
<slytherin> kolby: important to whom?
<kolby> really, though.  Would anyone agree that the C programming language is more valuable to the Open Source world than Python?
<ebroder> Mu
<kolby> perhaps people would be more interested in learning python before C.
<kolby> if people can quickly learn and use something when they become interested in it, that would be a valuable tool..
<ScottK> kolby: This is all rather unrelated to Ubuntu developement.
 * ScottK suggest #ubuntu-offtopic.
<kolby> I'll continue this discussion there.
<ScottK> Thanks.
<kees> bryce: yup, -> privmsg
<ion_> \o/
<ScottK> Urgh.  Artigas is on it's third or fourth try on qt4-x11.  I think it needs some buildd admin to go give it a really hard kick.
 * directhex hands ScottK a shotgun
 * ScottK hands it back since it's probably patent infested.
<directhex> ScottK, the point & click interface it provides may be covered by some xerox patents...
<ScottK> With a shotgun if it's point and click, that's a bug.
<directhex> i never said i gave you any ammo...
<ScottK> You assume I don't already have some.
<TheMuso> ScottK: Or could it just be that that sparc box is slow?
<ScottK> TheMuso: No, it's been several hours into the build and then been fewer hours into the build.
<TheMuso> right
<ScottK> I caught it needs building at one point.
<sistpoty> TheMuso: feel free to (ab)use spooky for sparc test-builds, if you're in need for a sparc box
<TheMuso> sistpoty: Whats it specs? I'd rather not throw kernels at it if its not that beefy.
 * sistpoty checks
<sistpoty> TheMuso: http://paste.ubuntu.com/117886/ (/me must admit that he's not familiar with what that actually means)
<TheMuso> Hrm me neither. :)
<sistpoty> TheMuso: but it feels fast compared to sparky *g*
<TheMuso> sistpoty: Anyway thanks for pointing that out, if I am in a jam and I need to do a build test, I will make use of it.
<TheMuso> sistpoty: Ok thats good to know.
<sistpoty> TheMuso: just ping around in #ubuntu-wire for an account then ;)
<TheMuso> Great.
 * TheMuso searches for give backs for ports on http://people.ubuntu.com/~ubuntu-archive/testing-ports/jaunty_probs.html.
<sistpoty> TheMuso: erm. #ubuntuwire even
<TheMuso> heh
<TheMuso> ScottK: the qt build on sparc is moving. I just refreshed its status page and the compilation has moved along.
<ScottK> TheMuso: Yep.  It'll do that and then later it starts over.
<ScottK> TheMuso: You can leave the KDE related ones to me.  They have an order they need to be done it.
<TheMuso> ScottK: Ok will do.
<TheMuso> ScottK: I knew you were doing them anyway, but I'm taking care of other stuff.
<Riddell> yay for ScottK, saviour of KDE on ports
<ScottK> OK.  Just don't want to waste time on slow archs ...
 * TheMuso nods.
<ScottK> Riddell: Wouldn't have been possible without TheMuso's work on kernels.
#ubuntu-devel 2009-02-14
<TheMuso> Nice to know some people care about ports around here. :)
<directhex> i care about ports
<directhex> who wants to help fix media handling in moonlight on big endian arches. anyone?
<TheMuso> directhex: Whats the problem exactly?
<Riddell> I'm sure Microsoft would be happy to help :)
<TheMuso> heh
<directhex> TheMuso, some bug in the demuxer
<TheMuso> ah
<TheMuso> Count me out. :)
<dtchen> TheMuso: what are some disadvantages of reverting PA's 0004_disable_autospawn.patch?
<sistpoty> directhex: /me would probably spot endienass problems, as he's a cause of them in a number of own-written files *g*
<TheMuso> dtchen: If people have pulseaudio installed on a {k,x,myth}(u)buntu install, and go to use an alsa app, it will start, and possibly cause them confusion when things don't behave as expected.
<directhex> sistpoty, well, feel free to take a look. there's an open upstream bug... https://bugzilla.novell.com/show_bug.cgi?id=443688
<ubottu> bugzilla.novell.com bug 443688 in media "ASF code assumes little-endian cpu" [Enhancement,Assigned]
<TheMuso> dtchen: THats one off the top of my head.,
<TheMuso> or if a user disables pulse for GNOME, but still has it installed, it will start anyway.
<sistpoty> directhex: that bug isn't saying very much? any hint to a file?
<dtchen> yeah, i was thinking of those, but i'm weighing those against the nonexistent stream/connection refused bugs
<savvas> hm..
<dtchen> ^ TheMuso
<TheMuso> dtchen: Right.
<savvas> realtek ethernet is not working in intrepid -11-generic, it worked fine in -9-generic - here's the diff: http://paste.ubuntu.com/117888/
<dtchen> TheMuso: how do you feel about setting tsched=0 in default.pa for the next upload?
<TheMuso> dtchen: Very strongly in fact.
<TheMuso> savvas: What realtek chip exactly? I am using a realtek onboard device here with no issues.
<dtchen> TheMuso: strongly opposed to or in favour of?
<directhex> sistpoty, upstream would know more. at a guess, something in src/asf/
<TheMuso> dtchen: Strongly in favour of.
<sistpoty> directhex: /me downloads...
<dtchen> TheMuso: ok
<savvas> TheMuso: I'm helping out a user, here's the working set of lspci -nnv: http://paste.ubuntu.com/117874/
<TheMuso> savvas: right thats not my chip./
<TheMuso> dtchen: If you are on a role with the pulse branch, feel free to throw those changes in yours, and I'll just mergte and upload when I next get to the audio stack, which will be Monday at the earliest.
<TheMuso> Since I am not currently working, I intend to spend time on other things that I care about as a community member.
<TheMuso> Yay, now new kernels can be on ports disks.
<dtchen> TheMuso: yep, already pushed to my branch, but i'm going to test the autospawn change more heavily before i commit it
<TheMuso> dtchen: Sure.
<sistpoty> directhex: sorry, can't help you right now... I just can't find any src/asf (or anything that might relate to it)
<sistpoty> gn8 everyone
 * calc thought xubuntu was supposed to be lighter weight than gnome but seems about the same with jaunty
<TheMuso> calc: its XFCE 4.6, so theres a chance that some optimization has not yet been done.
<calc> TheMuso: ah ok
<calc> TheMuso: well both gnome and xfce seem to take ~ 280MB after boot
<calc> TheMuso: i'm not sure if 280MB is high or low for them
<TheMuso> Right
<TheMuso> I thought you meant speed
<calc> ah ok, i thought it used less memory as well, but maybe not
<TheMuso> I don't know either.
<TheMuso> ScottK: lol qt4-11 eventually built.
<ScottK> TheMuso: Yeah.  Third time was the charm.
<cody-somerville> ScottK, Sounds good (re: motu-release delegation for Xubuntu)
<ScottK> OK.
<TheMuso> This rt package needs to be refactored a lot, and since realtime is now in git, /c
<TheMuso> woops wrong channel
<ScottK> TheMuso: Congratulations again.  All ports arch in one upload.
<ScottK> TheMuso: Have you considering getting linux-ports listed in p-a-s so it doesn't try to build on archs it's not relevant for?
<TheMuso> ScottK: Yeah, I am pleased. I got meta uploaded too, so I can now go ahead and change ports disks.
<TheMuso> ScottK: p-a-s?
<TheMuso> ScottK: considering the main kernel is not listed as such, then I don't see the need.
<TheMuso> ScottK: I.e the main kernel still is attempted on powerpc/sparc/ia64/hppa
<ScottK> TheMuso: Packages-arch-specific.  It's not critical, but it always seemed cleaner to me not to build on archs it's not needed for.
<TheMuso> ScottK: I agree. How does one get that changed?
<ScottK> There is on packages arch specifc file that is used by both Debian and Ubuntu.  It's maintained in Debian.  I don't recall (as it changed recently) the specifics, but Phil Kern mailed ubuntu-devel about it.
<TheMuso> Hrm ok.
<ScottK> TheMuso: The old procedure was "Ask lamont."
<TheMuso> heh right.
<TheMuso> Its not much of a bother really.
<TheMuso> And would be a problem if the mobile guys decided to throw a kernel or two to ports for arm.
<TheMuso> but thats speculating.
<TheMuso> or any other variant/arch in fact.
<ScottK> True.
<ScottK> I guess particularly since there may be a new port coming soonish.
<ScottK> Someone messed up and mentioned it here the other day.
<TheMuso> Right.
<StevenK> ScottK: We might end up forking P-a-s, due to stuff
<ScottK> StevenK: I'm aware of the stuff.  But until we do ....
<bimal> i cannot access my bluetooth . can any one help me
<iulian> bimal: Try #ubuntu.  This channel is not for support, it is for development only, see /topic.
<iulian> If you use Jaunty, try #ubuntu+1.
<bimal> sorry
<geser> doko: Hi, what are the chances to see python-central 0.6.8 in jaunty? Some packages from universe are in DEPWAIT as they want python-central >= 0.6.8 and jaunty has only 0.6.7ubuntu1.
 * sebner winks geser =)
 * geser winks back to sebner
<savvas> is the default security repository security.ubuntu.com or archive.ubuntu.com ?
<jpds> security.
<savvas> thanks :)
<directhex> "yes"
<savvas> jpds: I'm asking because in jaunty because the default uses archive.ubuntu.com
<jpds> savvas: I thought security. was best to point at, because the users wouldn't have to want for the mirrors to update to get the fixes.
<jpds> s/want/wait/
<savvas> good point
<Laney> savvas: security probably hasn't been opened for jaunty
<Laney> since updates are just done in the main archive
<Laney> it should be there after release I guess
<savvas> ok :)
<geser> http://security.ubuntu.com/ubuntu/dists/jaunty-security/ exists already but is of course still empty
<mok0> Any archive-admins online?
 * StevenK hides
<mok0> StevenK: heh, I would much appreciate to get bug 326172 processed, as I have watch on 2 other packages in line after that
<ubottu> Launchpad bug 326172 in xmlgraphics-commons "Please sync xmlgraphics-commons 1.3.1 (universe) from debian experimental" [Wishlist,Confirmed] https://launchpad.net/bugs/326172
<mok0> StevenK: (talking about jeuclid, and after that scitools)
<StevenK> mok0: There are no clear indications of what the Ubuntu changes are, and that the Debian package has merged them
<StevenK> mok0: Add that to the bug and I'll process the sync
<mok0> StevenK: ok, I'll look at it right away
<mok0> StevenK: hope my latest comment is satisfactory
<StevenK> mok0: Done.
<Mez> who runs the fridge nowadays? cause someones cocked up and put their own stuff in the Calendar :D
<nhandler> Mez: Anyone can add events to the calendar now. It is a Google Calendar
<nhandler> Where is the personal event?
<Mez> nhandler: only if they're given access to add events ... :D
<nhandler> Mez: Not true
<nhandler> Mez: https://wiki.ubuntu.com/Fridge/Calendar
<Mez> nhandler: 20/2 - "busy"
<Mez> nhandler: I have only read access...
<nhandler> I think I know what happened. Whoever added the Jaunty Weekly Release Meetings told gcal to "mark me as busy"
 * Mez shrugs
<Mez> nhandler: they've also changed the times that it was (it was originally the same times as the meeting, now changed to be different
<jpds> Mez: Best talk to boredandblogging.
<nhandler> You can also try pinging robbiew about it. I believe you can modify events that you add
<geser> just noticed the descriptions for events have a google map link. It's really useful if you don't know where to find e.g. #ubuntu-meeting :)
<jpds> ...who's not around at the moment.
<nhandler> geser: That just got added in the most recent gcal update
<Mez> jpds: yeah, I noticed
<mok0> StevenK: thanks! Much appreciated!
<btQuark> http://brainstorm.ubuntu.com/idea/16430/
<btQuark> has someone already seen jan-steinhoffs driver or actually brought it to wokr?
<LaserJock> anybody know of Ubuntu is likely to be a GSoC mentoring organization this year?
<Mithrandir> I'd be surprised if it wasn't
<LaserJock> it wasn't last year I don't think
<Mithrandir> hm, indeed.
<LaserJock> I've got 2 Edubuntu projects that I think would be perfect for it
<ScottK> I'm pretty sure Kubuntu would have stuff too.
<apw> pitti, ok pushed up a re-write of the suspend/resume apport support to  lp:~apw/apport/suspend-resume-pt3, this now includes a move to common messages for cli, gtk, and qt, to simplify internationlisation and has your other internationalisation concerns sorted i hope.
<davidrod`> When I use network-manager on kde all the boxes are ghosted and it is broken.  When I use it on ubuntu it forgets my setting with a reboot.  I am sure that this is a bug
<davidrod`> I wanted to change user to root but it won't let me.  I was thinking that there must be some permissions wrong, but on what files and where?  With BSD they tell you. With Ubuntu this is a mystery
<ScottK> davidrod`: What release are you using?
<davidrod`> Linux david-laptop 2.6.24-a21-generic #1 SMP Tue Oct 21 23:43:45 UTC 2008 i686 GNU/Linux
<davidrod`> It is a pain because I have no other reason to move away from ubuntu right now.  Is there some hack I can perform to write my network details into a file?
<ion_> 0) Is that really an Ubuntu kernel? I donât remember there being an âa21â in the version field. I might be wrong, of course. 1) Can you try upgrading to a newer Ubuntu release? 2) You can use ifupdown instead of network-manager by configuring /etc/network/interfaces.
<ScottK> davidrod`: Alternatively since you're using KDE, use KNetworkManager.
<davidrod`> Linux david-laptop 2.6.24-21-generic #1 SMP Tue Oct 21 23:43:45 UTC 2008 i686 GNU/Linux
<davidrod`>  I couldn't find any documentation about how to use WEP with ifup.  When I type knetworkmanager nothing happened.
<davidrod`> Is there no readme file anyway in /usr
<ScottK> davidrod`: KNetworkManager is part of the default kubuntu-desktop.  It should be a point-click thing.
<ScottK> davidrod`: Also this is not a support channel so for further help you should probably ask in #kubuntu.
<davidrod`> It has been critised with ubuntu that if it does not work out of the box, what then?  My wireless has been broken for months. There is no docs. no FAQ.  everything is aimed so low, that unless I have been developping the kernel for years I cannot find any middle ground.  I asked in #Ubuntu several times, over weeks and months.  In there they just shout "Try blackbox. NO. Fluxbox. EDuntu. Gnome. KDE. etc. etc.
<ScottK> davidrod`: I can't tell you for sure.  It worked out of the box on Hardy for me.
<shtylman_> davidrod: you don't use wep with ifup
<shtylman_> davidrod: you use wep with iwconfig, ifup and down just bring up or tear down interfaces respectively
<shtylman_> davidrod: chances are...if you can't find documentation on how to do something like that and google doesnlt help, you may be trying to pair the wrong two things and ask the question differently
<davidrod`> well ifconfig wlan0 up does exactly the same?
<davidrod`> I am thinking of abandonning ubuntu and going to Gentoo simply because of my wireless
<shtylman_> davidrod: nope, iwconfig is for configuration
<shtylman_> davidrod: ok, I mean...I think you should use what you like...but if you are abandoning ubuntu because stuff 'doesn't work out of the box' then gentoo really won't be right for you either
<davidrod`> I don't want out of the box. I want to be able to set configuration files myself. On BSD each interface has it own file. Good idea. Manuals and FAQ explain what to do.  I hope Gentoo won't think that I am unable to type
<shtylman_> davidrod: you can set configuration files all you want... I really don't see what your complaint is...and as stated before, its not development related so best ask in one of the support channels
<ion_> interfaces(5)
#ubuntu-devel 2009-02-15
<nhandler> pbuilder is really acting up. I get to " -> debootstrap finished", but then it fails to resolve "archive.ubuntu.com". This causes the rest of 'pbuilder create' to fail
<vorian> nhandler: try adding us.archive.ubuntu.com (or other mirror) to your pbuilderrc
<nhandler> vorian: I'm trying that now. It needs to go through the whole debootstrap process again, so it might take a while
<vorian> i have all night :)
<vorian> plus, i have a little background on what you've experienced thus far
<maxb> http://paste.ubuntu.com/118222/  <-- I use this wrapper script as a debootstrap replacement which bindmounts /var/cache/apt/archives into the bootstrap chroot, saving most/all of the download time
<nhandler> Still fails with us.archive.ubuntu.com: http://paste.ubuntu.com/118224/
<cody-somerville> okay....
<cody-somerville> X just segfaulted on me along with a number of other processes.
<maxb> Hmm.. I'm getting a rogue conffile prompt concerning /etc/belocs/iso-639.def on upgrade. Should I be filing a bug and if so, against what?
<cody-somerville> Actually, it was an invalid next size
<TheMuso> maxb: If this is jaunty, you may want to wait a bit as pitti has been moving some locale things around quite a lot in the last 12 hours or so, so it may not hurt to let things settle on the archive mirror you are using first.
<DBO> i am becoming increasingly worried about intel drivers in jaunty.  Is ubuntu going to really push the new drivers which are measurably worse than those in intrepid?  It would really suck for application developers such as myself...
<TheMuso> \/c
<RAOF> \m/
<jdong> TheMuso: you should get that head checked out....
<jdong> I'm no medical expert but it looks a bit out of place
<TheMuso> lol
 * ScottK notes that power pc is totally caught up and building well, so if you've got something that failed on PPC, now would be a good time for retries.
<ScottK> TheMuso: My ports rebuilding is going pretty smoothly.
<ScottK> Only one ICE so far.
<TheMuso> ScottK: Nice.
<TheMuso> ScottK: Together we have managed to get powerpc down to 15 uninstallable packages at least.
<ScottK> TheMuso: Yes.  It's in as good as ship as the supported archs.
<ScottK> I did a decent sized stack of universe retries too.
<TheMuso> Yeah. Just gotta wait till the locales stuff settles and things will be ok again.
<ScottK> TheMuso: You wouldn't happen to be in the mood to look at an IA64 build failure, would you?
<ScottK> So far I got one ICE and two portability issues.  The sparc issue I think I've got fixed and NCommander is going to test it for me on a sparc box.
<ScottK> TheMuso: If you get interested it's http://launchpadlibrarian.net/22641086/buildlog_ubuntu-jaunty-ia64.kdebindings_4%3A4.2.0-0ubuntu1_FAILEDTOBUILD.txt.gz
 * ScottK is off to bed.  Good night.
<TheMuso> ScottK: Wouldn;t know where to start fixing that FTBF sorry.
<geser> slangasek: Hi, could you please give bug #323863 another try and move now also the other binary deb and the source to universe too? thanks.
<ubottu> Launchpad bug 323863 in libjdic-java "Please move package to universe" [Wishlist,Confirmed] https://launchpad.net/bugs/323863
<pop79> hi
<ScottK> TheMuso: Thanks for looking.
<pop79> sorry, is this the developers section?
<directhex> for people developing the core of the distro
<pop79> oh
<pop79> im developing a little tour that can be put on cd, so it can show what ubuntu can do, not to do with the live cd.
<pop79> would that count?
<BUGabundo> apw: I was running a suspend test
<BUGabundo> from https://wiki.ubuntu.com/KernelTeam/SuspendResumeTesting
<BUGabundo> nd laptop failed to resume once it started the automated part of tests
<BUGabundo> pgraner: ping
<BUGabundo> ^^^^^^^^
<BUGabundo> what do you guys want me to do to collect data for bug?
<BUGabundo> I read this https://wiki.ubuntu.com/KernelTeam/SuspendResume
<BUGabundo> but apport did not fire up, nor do I know the name of the log file
<RainCT> kirkland: Hey. Another problem with screen-profiles.. Run screen in a terminal and scroll up with the mouse wheel ^^
<vadi2> After today's dpkg upgrade, I am unable to install any packages with gdebi - it just freezes. Is this known or just me?
<persia> vadi2, #ubuntu-bugs is generally a better place to ask if a bug has been reported, or to check in LP.
<vadi2> okay
<Laney> are removals from sid still automatically carried over to Jaunty, or is this part of autosync?
<RainCT> Laney: I don't think they are
<Laney> thought as much
<RainCT> Laney: you can imagine the reasons, though? eg, Debian might do some transition involving package removals and if they were removed from Ubuntu too but we didn't do the transition stuff here would break, etc.
<Laney> of course
 * RainCT wonders if the authors of all the "make Ubuntu more popular" ideas on Brainstorm are even in a LoCo team
<pochu> good question
<directhex> RainCT, no.
<directhex> RainCT, if they post ideas on the forum or brainstorm, then they don't even know proper channels exist
<RainCT> lol
<RainCT> (and then there are the "make brainstorm more popular" ideas -.-)
<jpds> RainCT: http://brainstorm.ubuntu.com/idea/12452/
<RainCT> OMG
<pochu> hahaha
 * RainCT ponders voting +1 ^^
<pochu> you know, I'd go to the cinema to watch that one
<kees> kirkland: hrm, you didn't commit your cryptsetup 2:1.0.6-7ubuntu3 changes to the bzr tree...
<kees> kirkland: also, what happened to all the autoconf files??
<kees> kirkland: please make sure you manually review your debdiff before uploading -- we need to avoid cruft.  :)
<ZippyV> I'm new to debugging in Ubuntu
<ZippyV> I have to debug some code of the hal
<ZippyV> which ide do you guys recommend?
<ScottK> TheMuso: I'm also seeing error like /usr/include/linux/byteorder.h:8:3: error: #error Fix asm/byteorder.h to define one endianness
<ScottK>  ... on sparc.
<ScottK> Google seems to indicate there are kernel patches for this, but I'm no expert.
<ScottK> http://launchpadlibrarian.net/22649785/buildlog_ubuntu-jaunty-sparc.kdemultimedia_4%3A4.2.0-0ubuntu2_FAILEDTOBUILD.txt.gz for a full build log.
<calc> anyone else notice the archive is really slow today?
<ScottK> I saw several complaints about it yesterday.
<calc> i'm downloading from it at about 4KB/s
 * calc hopes he can get a new OOo upload done before alpha5 with how slow the archive is :\
<calc> it claims it is going to take 28hr+ to download the packages i need
<ScottK> calc: FYI, there's a boost1.35 portability problem on sparc that breaks OOo currently.  I've got a patch I'm waiting for NCommander to test on a sparc box he has access to.
<calc> ScottK: ok
<ScottK> Yeah, now that TheMuso got the ports kernels fixed I've been trying to get things built on the ports archs.
<calc> oh ok
<BUGabundo> TheMuso: ping
<BUGabundo> I'm having trouble again with PA test2
 * calc bbl
 * RAOF hopes it's a bit early for TheMuso to be in here.
<BUGabundo> most of the time I have to kill it and start again just to have PA audio
<BUGabundo> and after hibernate/resume it faills 99% of the time
<BUGabundo> RAOF: I hope he reads the backlog
<BUGabundo> eheh
<IntuitiveNipple> Anyone know where the string "Comparing resolution (1280x800 1280x1024) to maximum 3D texture size" might be generated (during Xorg start-up) ? There's an error just after that looks like it is from a shell script
<RAOF> IntuitiveNipple: That's the compiz wrapper script.
<RAOF> You have two separate X screens?  Strange.
<IntuitiveNipple> Yeah it is - I just found it
<IntuitiveNipple> Why strange?
<IntuitiveNipple> It's repeated in 3 scripts it seems
<IntuitiveNipple> bug #207770 has a debdiff ready
<ubottu> Launchpad bug 207770 in compiz "compiz check_texture_size does not deal with multiple displays" [Low,Confirmed] https://launchpad.net/bugs/207770
<jeromeg> hello
<jeromeg> is there anyone in charge of abiword in main ?
<TheMuso> BUGabundo: Yes? Please just ask your question, and I'll get to it when I am around, and if you are online, you will get an answer ASAP.
<BUGabundo> TheMuso: are you here now?
<TheMuso> BUGabundo: Yes, I would not have responded if I was.
<TheMuso> s/was/wasn't/
<BUGabundo> ehehe
<BUGabundo> I'm having trouble again with PA test2
<BUGabundo> most of the time I have to kill it and start again just to have PA audio
<BUGabundo> and after hibernate/resume it faills 99% of the time
<TheMuso> BUGabundo: May I suggest you contact upstream directly? Except for a few settings changes, there is nothing different from upstrea's code.
<BUGabundo> humm I may
<BUGabundo> but I remembered there was that race condicion with the archive version
<BUGabundo> and this sounds similar (except for resume)
<BUGabundo> running pulseaudio -k ; start-pulseaudio-x11 doesn't always start PA
<BUGabundo> it fails to connect
<BUGabundo> one user on #ubuntu+1 also mentioned that PA devs where under the idea Jaunty was going to ship 9.15 and not 9.14
<TheMuso> I'll check on that, because that is certainly not the case.
<TheMuso> As for that race stuff, I'll put it into the test version later today when I get to doing audio work.
<andersk> Is there a MOTU sponsor available to review a quick fix in bug 34376? I fixed a regression introduced by the last patch.
<ubottu> Launchpad bug 34376 in debmirror "missing main/debian-installer in repo causes debmirror to fail" [Medium,Incomplete] https://launchpad.net/bugs/34376
<andersk> I think that it can then be closed, because the original problem has been addressed.
<ScottK> andersk: #ubuntu-motu is a better channel.
<mdke> what are the chances that if usb-creator doesn't work for me in Intrepid, it will work in Jaunty? Has there been intensive development in the last few months?
<geser> mdke: http://changelogs.ubuntu.com/changelogs/pool/main/u/usb-creator/usb-creator_0.1.11/changelog
<RainCT> * Default the GUI to start up centered on the screen.
 * RainCT guesses this won't work on a dual screem setup, and hopes to be corrected :P
<mdke> geser: thanks. I can't see anything obviously crucial there but I'll give it a try :)
<RAOF> RainCT: Depends on how it's implemented.  GTK will generally DTRT with screens spanning two heads.
<primes2h> May anyone have a look on this bug, please? It's a blocker for many many users, especially for newbies.... bug #255651
<ubottu> Launchpad bug 255651 in linux "floppy disk drive not detected (module not loaded) in Intrepid and Jaunty" [Undecided,New] https://launchpad.net/bugs/255651
<DevelArab> Enter text here...Hi
<RainCT> kirkland: I've just reviewed screenbin on REVU
#ubuntu-devel 2010-02-15
<owen1> bug #123775 is 'linked to a milestone later' and it 'has a patch', priority=medium, not assigned, status=won't fix.   what does all this mean? will it be fixed and when?  thanks!
<ubottu> Launchpad bug 123775 in linux "Elantech touchpad is incorrectly recogonised as a "ImPS/2 Logitech Wheel Mouse"" [Medium,In progress] https://launchpad.net/bugs/123775
<owen1> it's a big issue for many laptop users. we can't configure the touchpad.
<lifeless> owen1: well it appears to have been fixed
<lifeless> and folk are now piling onto the bug with similar but different symptoms
<owen1> lifeless: what do u mean? fixed and pushed or will be ready for 10.4?
<lifeless> according to that bug's status, fixed for over a year
<owen1> lifeless: that's wierd. i can't configure my touchpad and i have the same issue.
<lifeless> well, you have the same symptoms. Doesn't mean same issue (though it may be)
<owen1> lifeless: why does it say "in progress"
<lifeless> if there is a patch, you could try applying it and seeing if that fixes it - and if so, raise it.
<lifeless> owen1: well one task is in progress
<lifeless> and if you look at the activity log folk have been messing around with it
<owen1> how do i apply that patch?
<owen1> or better solution - how to make sure it's really fixed? i created #512192 which is the same.
<owen1> many people have this problem.
<owen1> Can't configure Elan tech touchpad on Dell Inspiron 11z, Asus K7I0C and maybe also Dell Mini 10 (not V), ASUS k40in, Asus U81A and ASUS UL80-VT.
<pitti> Good morning
<pitti> cjwatson: sorry, WI tracker failed every time on Saturday, it couldn't cope with a spec targetted to "later"; I fixed it yesterday
<pitti> bdrung: questions about syncs> shoot
<dupondje> morning everybody :)
<pitti> ev: FYI, I'm porting usb-creator to udisks now
<dholbach> good morning
<pitti> ev: hm, if I run "PYTHONPATH=. tests/run" I get all failures in TestDevkitBackend, with "The name com.ubuntu.USBCreator was not provided by any .service files", and a lot of of stale fake_devicekit-disks processes; how do I run this?
<Riddell> stgraber: what you seen bug 520767 ?
<ubottu> Launchpad bug 520767 in pkgbinarymangler "Failure during -dbgsym generation" [Critical,New] https://launchpad.net/bugs/520767
<dupondje> pitti: something went wrong generating language-pack's
<dupondje> new language packs breaks mozilla for some languages
<pitti> asac, ArneGoetje: ^ known?
<mdz> is anyone else having trouble with Google Calendar with the chromium-browser in Lucid? I get the "Aw, snap" page every time it tries to load the event editing dialog
<pitti> superm1: ah, seems you already prepared dell-recovery for udisks, great! (I'm about to remove devicekit-disks from the lucid archive); you missed a bit in 96-dell-recovery-partition.rules, you need to additionally add UDISKS_PRESENTATION_HIDE
<pitti> superm1: (or instead, if you want to drop support for DK-D)
<pitti> superm1: however, I wonder whether 96-dell-recovery-partition.rules is needed in the first place; udisks already ships a lot of standard "hide recovery partitions" rules by default, aren't they sufficient?
<pitti> (dk-d did that as well)
<pitti> superm1: would you mind uploading dell-recovery soon, so that we can remove devicekit-disks from the archive?
<ev> pitti: the test framework is woefully out of date, I wouldn't bother with it until I've found some time to bring it up to speed
<ev> thanks for doing the port, by the way
<pitti> ev: ok, understood; it looks exactly as broken as the dk-d variant :)
<pitti> ev: I tested writing an actual image to an USB stick, that worked fine
<ev> :)
<ev> cool
<ev> mvo: ubiquity-slideshow-ubuntu-upgrade is in universe.  In case you're not already aware, you have commit access to lp:ubiquity-slideshow-ubuntu via your membership in ~ubuntu-installer, should you want to make any changes.
<ogra> mdz, works fine here, are you using the chromium from the archive or from the daily build ppa ?
<mdz> ogra, archive
<ogra> (mine is the archive one in lucid)
<ogra> wierd
<ogra> *weird even
 * ogra does a dist-upgrade
<ogra> i'm out of date a few days
<pitti> hm, what's wrong with libmysqlclient16_7.0.9-1_amd64.deb ?
<ogra> still works with the latest
 * ogra restarts to be sure
<geser> pitti: bug #521815
<ubottu> Launchpad bug 521815 in mysql-cluster-7.0 "breaks all builds requiring libmysqlclient-dev" [Critical,Fix released] https://launchpad.net/bugs/521815
<pitti> geser: ah, thanks
<ogra> mdz, still all fine after upgrade and reboot
<ogra> must be on your side
<mdz> ogra, hmm. I've disabled my (two) extensions and it is 100% reproducible. is there any way to get more info than "aw snap"?
<ogra> not sure, asac ^^^^ ?
<ogra> mdz, there is the -g setting but that immediately runs it in gdb afaik
<fagan> isnt there a --debug option in terminal for chromium
<ogra> fagan, yes, -g is the short form of it
<ogra> Riddell, do you have an idea about bug 522045 ? the error message makes me suspect we are missing something in kde under armel
<ubottu> Launchpad bug 522045 in ubiquity "sip import error under oem-config-kde " [Undecided,New] https://launchpad.net/bugs/522045
<Riddell> ogra: kdebindings hasn't compiled on arm recently
<ogra> yeah, i suspected something might be out of date here
<Riddell> ogra: it's currently compiling away though so we can but hope it completes
<ogra> yeah, else i'll put NCommander on the case, he loves to debug KDE on arm :)
<ogra> Riddell, thanks a lot
<ttx> Question: I install a task through "apt-get install task^" with a PPA enabled (that provides some of the task deps): task installation just skips the package that happens to be provided by the PPA. Doesn't install the main equivalent, doesn't install the PPA version either. Any clue ?
<ttx> mvo: ^ ?
<ttx> The issue being it prevents me from netbooting/preseeding a UEC install from an alternate repository
<mdz> ogra, I guess I'll download the 400M of debug symbols then ;-)
<mdz> ttx, the packages included in the task are determined by the Task: headers in the Packages files
<mdz> ttx, the PPA one won't have a Task: and so it won't be used
<ttx> mdz: and it will not gracefully fallback to the main version, because it's not the install candidate... interesting
 * ttx digs deeper
 * xnox is upgrading to lucid - joy estimated upgrade time 3 hours
<mdz> ttx, you are probably better off just not using task^ and providing a list of the packages you want (maybe extracted from the task in main)
<ttx> mdz: Right, however I'm testing the UEC installer, which uses the task
<ttx> The idea was to allow install-testing a work-in-progress eucalyptus, without having to upload it
<mdz> ttx, ...without running a local mirror :-)
<ttx> I have a local mirror
 * ttx digs into Packages file
<mdz> ttx, you could try mirroring the PPA locally and modifying the Packages file
<ttx> mdz: I'm on it :)
<ttx> mdz: (In fact I use a local repo for that. PPA was just for sake of example/reproducing my issue)
<mdz> ttx, cjwatson and I have talked about writing a tool which takes a .changes and replaces that package into an .iso for testing
<mdz> but I don't think anyone has found the round tuits yet
<ttx> mdz: It would be interesting as an additional test option, but I kinda like our new PXE based test setup
<ttx> i'll just mangle my localrepo Packages file
<ttx> mdz: Any reason why local repositories (or PPAs) don't get "Task" headers ? Shouldn't they be generated from the package control file ?
<mdz> ttx, no, they come from overrides
 * ttx mans apt-ftparchive
<mvo> ttx: hi, that should work, does the Package have the right Task headers in the PPA?
<ttx> mvo: apparently not
<mvo> ttx: aha, I just read scrollback, mdz answered already
<ttx> mvo: i'll use a local repo with a properly-overridden Packages file
<ttx> mvo, mdz; thanks !
<asac> pitti: yes
<asac> pitti: i fixed it on macq...
<geser> pitti: have you some time to review (and sponsor) https://code.edge.launchpad.net/~geser/pkg-create-dbgsym/fix-520767/+merge/19323 (it's for bug 520767)
<ubottu> Launchpad bug 520767 in pkgbinarymangler "Failure during -dbgsym generation" [Critical,New] https://launchpad.net/bugs/520767
<asac> pitti: wanted to talk to you how to rerun the langpack generation
<pitti> ArneGoetje: ^ can you please kick off a new build?
<pitti> asac: thanks
<pitti> geser: will look, thanks!
<asac> pitti: where arne lives the whole week is public holiday
<ArneGoetje> pitti: already done and uploaded
<asac> oh
<asac> he
<pitti> ArneGoetje: ah, sweet, thanks!
<asac> ArneGoetje: you didnt compile po2xpi
<asac> not sure what you tested ;)
<ArneGoetje> asac: I know... noticed too late
<asac> heh
<asac> ok
<asac> noticed too late?
<mdz> ttx, doing this properly with apt-ftparchive requires creating several configuration files etc. unfortunately :-/
<ArneGoetje> asac: noticed after you triaged the bug.
<asac> ah
<asac> ArneGoetje:  i wanted to change the searchplugins :(
<asac> didnt know you were here
<ArneGoetje> asac: before I have just pulled your po2xpi and modified it locally. But because you didn't merge my changes yet, I pulled my own branch and symlinked it as po2xpi on the server... but forgot to run make to actually compile po2xpi. orz
<asac> but ok lets continue on mozillateam
<asac> ok
<soren> ttx: Did you get an answer yet?
<ttx> soren: yes, thanks
<soren> ttx: Wicked.
<mdz> ogra, http://pastebin.com/f6e9beda1
<mdz> ^ chromium backtrace
<mdz> it would be nice if there were a command line option to say "go ahead and dump core" so that apport would work
<mdz> ogra, asac, reported as bug 522078
<ubottu> Launchpad bug 522078 in chromium-browser "Crashes reproducibly when trying to edit events in Google Calendar" [Undecided,New] https://launchpad.net/bugs/522078
<asac> mdz: hmm. odd. the latest in archive is from the beta channel
<asac> https://edge.launchpad.net/ubuntu/+source/chromium-browser/5.0.307.7~r38400-0ubuntu1
<mdz> asac, I upgraded everything else at the same time as chromium, I guess it's possible the bug is lower in the stack
<asac> could be ... though we use only just a few system libs
<asac> maybe attach your apt log parts too then
<asac> mdz: ^
<dupondje> asac: ArneGoetje: thx
<dupondje> will check this evening if it works ;)
<asac> should
<ogra> asac, mdz, i get the same error trying to update a worpress entry here apparently
<asac> ogra: same backtrace?
<ogra> havent done one yet, one sec
<ogra> but i see th eoops page as soon as i click the update/save button
<mdz> asac, apt history attached
<asac> thanks
<mdz> asac, ogra, it's been linked to an upstream report confirming
<ogra> asac, my bt is rather empty
<asac> right
<asac> ogra: http://code.google.com/p/chromium/wiki/LinuxDebugging
 * asac wonders how to teach chromium to create .crash files for snaps
<mdz> asac, I created https://wiki.ubuntu.com/DebuggingChromium with a link to that btw
<asac> hmm. i thought we already had a wiki. but thanks.
<mdz> asac, I didn't find one, looking at DebuggingProcedures and searching
<asac> mdz: https://wiki.ubuntu.com/Chromium/Debug
 * asac updates DebuggingProcedures
<asac>  and renames that page to debugging ;)
<mdz> asac, thanks
<asac> hmm. the wiki seems to not fix all references to a page on rename
<asac> i would have expected that from a wiki for internal content
<ogra> asac, i see no mention of xml/xslt at all in my bt ... though i have about 30 tabs open i should probably retry that when i can clean out my tabs and try with a single one
<asac> ogra: did you use the renderer gdb approach?
<asac> from the wiki?
<asac> do that
<ogra> i used https://wiki.ubuntu.com/Chromium/Debug
<asac> and yes, use a single tab
<ogra> right, that has to wait then
 * ogra needs his tabs 
<asac> which doesnt exist anymore ... hmm. wasnt there a time when the wiki created a redirect?
<asac> https://wiki.ubuntu.com/Chromium/Debugging
<ogra> right, well, i used it before you moved it :)
<asac> sure
 * ogra wonders why he gets mono comments on the blog entry he just did
<ogra> tsk
<\sh> guys, what's the correct way to tell buildd admins to un-P-a-S a package?
<lool> valgrind was updated in Packages-arch-specific two days ago to add armel support; it was properly attempted two days ago in Debian sid, but not in lucid
<lool> Who can I poke to get our Pas updated?
<lool> After the last announcement from pkern, I thought it would be automatically updated from Debian's git
<lool> Hmm we seem to have an ~ubuntu-core-dev branch of it
<\sh> lool: I would say buildd admins ;) but I need to find out where I can file bugs about p-a-s
<lool> \sh: pkern's announcement requested to file them in Debian
<lool> against the buildd.debian.org pseudopackage
<\sh> lool: yes...
<lool> so lp:packages-arch-specific is lagging and didn't mirror the latest git commits from https://buildd.debian.org/git/packages-arch-specific.git/
<lool> I think I'lll go poke #launchpad at this point
<lool> cjwatson: Hmm sorry just saw the comment on the branch that I should contact you
<lool> cjwatson: Would you mind updating https://code.launchpad.net/~cjwatson/packages-arch-specific/sid ?
<lool> Except he's on leave
<lool> Ok, I think I'll update lp:~ubuntu-core-dev/packages-arch-specific/ubuntu and resync with cjwatson when he comes back
<ejat> hi guys ..
<ejat> http://paste.ubuntu.com/376824/
<ejat> why the listed package need to be remove while i try to upgrade to lucid ?
<ejat> such as ubuntu-desktop ..
<jdub> hey gang
<jdub> anyone seeing upgrades fail with
<jdub> "tar: ./md5sums: Cannot utime: Bad file descriptor"
<jdub> ?
<jdub> i'm upping from hardy to lucid (kernel version 2.6.18.8)
<jdub> looks like there are some relevant debian coreutils bugs
<jdub> eg. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=563726
<ubottu> Debian bug 563726 in tar "tar: futimens() with a bad file descriptor (AT_FDCWD)" [Important,Open]
<\sh> lool: would you adjust p-a-s in ubuntu also with the package mentioned in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=569952 ? :)
<ubottu> Debian bug 569952 in buildd.debian.org "Please let libunwind build on i386 and amd64" [Normal,Open]
<lool> \sh: done
<Riddell> ogra, NCommander: kdebindings failed on arm with "Segmentation fault
<Riddell> it's in smoke though.  the python stuff compiled fine.  so probably best to just stop smoke compiling on arm since I doubt it's used by anyone
<ev> is X intentionally on VT1 now?
<ogra> Riddell, likely a buildd hiccup
<ogra> Riddell, given back
<chrisccoulson> is there a DMB meeting scheduled for tomorrow?
<pitti> should be
<chrisccoulson> pitti - thanks
<james_w> Lucid Alpha 2 released | Archive: open (DebianImportFreeze) | MoM running (but use bzr!) | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-karmic | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<james_w> could somebody set the topic please ^
<pitti> james_w: you should be able to? (what's the difference?)
<james_w> pitti: I don't have an ubuntu/member hostmask
<james_w> that's AIUI anyway
<pitti> it already seems to be what you suggest, or it's so subtly different that I fail to see it
<james_w> I added (DebianImportFreeze) to the archive status
<dupondje> https://bugs.launchpad.net/ubuntu/+source/gnucash/+bug/521217 => who can sync this ? its already ACKed :)
<ubottu> Ubuntu bug 521217 in gnucash "Sync gnucash 2.2.9-4 from Debian sid main" [Wishlist,Confirmed]
<sebner> dupondje: archive admin
<dupondje> I think there a some around here ? ;)
<james_w> dupondje: patience my friend
<sebner> dupondje: they are processed periodically and I don't suppose your sync request is something special that needs special attention ;)
<dupondje> If its get into lucid final its all ok for me :)
<james_w> dupondje: it will be done in 20 minutes or so
<james_w> there are 130 others that need doing as well
<pitti> james_w: sorry, seems I lost my ability to set the topic; "You're not channel operator"
<dupondje> james_w: I can wait that long ;)
<james_w> pitti: you should be able to /msg chanserv op #ubuntu-devel pitti
<pitti> james_w: nope, I'm not an op for #u-devel
<pitti> (or any IRC channel for that matter)
<superm1> pitti, i've not actually tested the udisks support yet, it's all been theoretical at this point :) i've also got a few other things that i'm working on, so will upload after that
<pitti> superm1: thanks; udisks is in lucid now, and g-d-u and usb-creator got ported
<james_w> pitti: oh, sorry, it's not set up like some other channels
<Keybuk> mvo: you'd know the answer to this one
<Keybuk> is there an easy way to do an upgrade just from a PPA
<mvo> Keybuk: no trivial one, I could do a python-apt script for you if you want
 * ogra wonders how to adjust volume with cursor keys with the new horizontal volume applet 
<cjohnston> mbudde: ping
<mbudde> cjohnston: sup?
<cjohnston> nhandler is working on a script for the ubuntu classroom to help out with admin stuff.. and we wanted your feedback as the lernid dev on something
<mbudde> okay
<cjohnston> The design of the script will be to parse the class topic and instructor
<nhandler> Why not move this back to #ubuntu-classroom-backstage cjohnston and mbudde ?
<cjohnston> that works..
<ari-tczew> please sponsor fake syncs in bug 511448 ; bug 521666 ; thanks
<ubottu> Launchpad bug 511448 in libxml-security-java "Fake sync libxml-security-java 1.4.3-2 (main) from Debian testing (main)" [Undecided,Confirmed] https://launchpad.net/bugs/511448
<ubottu> Launchpad bug 521666 in libaxiom-java "Fake sync libaxiom-java 1.2.8-1 (main) from Debian testing (main)" [Undecided,Confirmed] https://launchpad.net/bugs/521666
<geser> james_w: re bug 273549: it looks like it got promoted to much. intended was to move it from multiverse to universe and not main.
<ubottu> Launchpad bug 273549 in apertium-es-ca "Move apertium-es-ca to universe" [Undecided,Fix released] https://launchpad.net/bugs/273549
<james_w> geser: oops, fixed, thanks
<sabdfl> who's the best person to ping re bluez
<Keybuk> sabdfl: mario usually
<Keybuk> what's up?
<ogra> sabdfl, persia and superm1 did some work on it in the past
<mdz> kenvandine, any guess on bug 522067? someone on identi.ca said they fixed things by removing and re-adding their account, but I don't want to do that if it would impede analysis
<ubottu> Launchpad bug 522067 in gwibber "No longer displays updates from Twitter" [Undecided,New] https://launchpad.net/bugs/522067
<ivoks> pitti: ping
<dupondje> james_w: it got synced ;)
<james_w> I know :-)
<mvo> persia: hi, you seem to have done the recent ubuntu-dev-tools uploads - any objections about me adding "edit-patch" from  https://code.edge.launchpad.net/~mvo/+junk/edit-patch ?
<dupondje> mvo: where I am on your todo list ? ;)
<mvo> dupondje: oohhhh
 * mvo gets a guilty conscience	
<dupondje> don't tell me you forgot me :P
<mvo> not as such ...
<mvo> dupondje: let me do it now
<dupondje> sweet :)
<mdz> is anyone else seeing mutt display "ï¿½" characters where it used to show line-drawing characters (e.g. displaying threads)?
<mdz> seems to happen regardless of which font I choose in lucid
<Laney> I get "error: the symbol 'grub_env_find' not found." when booting my Lucid machine now. Looks like debian bug 567582, but I can't find one on LP. Want one? Is the requested info in that bug useful?
<ubottu> Debian bug 567582 in grub-pc "boot failure: "the symbol 'grub_env_find' not found"" [Grave,Open] http://bugs.debian.org/567582
<pitti_> ivoks: pong
<ivoks> pitti_: hi
<ivoks> pitti_: i hope you aren't floded with my mirs
<pitti_> ivoks: not any more :) my server went down an hour ago, so no mails for me :)
<ivoks> pitti_: i just wanted to ask; do i need to fill in mir for every single perl module or could i just fill one with all of them :)
<pitti_> ivoks: you have to check bug status/debian maintenance for all of them
<ivoks> pitti_: of course
<pitti_> ivoks: beyond that, just use that libtest-testing-perl thing and just add new tasks
<ivoks> great! thanks
<ivoks> https://wiki.ubuntu.com/ClusterStack/MIR there's lots of them
<sladen> directhex: any idea how to get dh_clideps et al not to do the stupid exact-dependency thing for other libriaries based on those available on the buildd (x << 1.2 && x >= 1.1)
<directhex> sladen, what is the dependency you're getting, and what would you prefer it to be?
<dupondje> mvo: thx
<sladen> directhex: things like:  libtaoframework-openal1.1-cil (>= 2.1.svn20090801), libtaoframework-openal1.1-cil (<< 2.1.svn20090802)
<sladen> directhex: I'd quite like that to be just  (>= x)  so that packages don't break when the library in question gets rebuilt
<directhex> let me check
<sladen> directhex: (unless I'm completely misunderstanding the reason for some obsession reason for the paranoid CLI versioning)
<directhex> sladen, well, it won't have trouble with a rebuild, as it versions against the UPSTREAM release.  2.1.svn20090801-1ubuntu74 is still << 2.1.svn20090802
<directhex> sladen, that info is written into the lib (i.e. the lib says "my deps if you depend on me should read as follows:"), using the same parameters as with dh_makeshlibs
<sladen> directhex: so in this example, the answer is to modify 'libtaoframework-openal1.1-cil' $somehow to not ask for the exact linking?
<directhex> sladen, in tao's case, it's intentional as there's a high likelihood of bits breaking if you have partly one release and partly another.
<directhex> sladen, to do that, you'd add something like "dh_makeclilibs -plibtaoframework-openal1.1-cil -V" to debian/rules
<sladen> directhex: well stuff (upgrades) breaks *because* of it
<directhex> sladen, what's the specific breakage? can i see the console spew?
<crimsun> pitti: hi, is there an existing method to get a user's configuration files from within apport-symptoms, or do I need to do that manually using Python methods?
<slangasek> Keybuk: so I've triaged another plymouth bug, but I'm not sure what to do with it. When you boot w/o splash, plymouth doesn't change vts, I guess to display all the boot-time messages.... so when gdm sees plymouth is there and assumes that means it can use the active VT for its server, it spawns on vt1
<slangasek> Keybuk: how *should* this be fixed?
<slangasek> Keybuk: (bug #518352 is the master for this bug now)
<ubottu> Launchpad bug 518352 in plymouth "[lucid] if booting without 'splash', gdm starts X on wrong vt" [Medium,New] https://launchpad.net/bugs/518352
<slangasek> chrisccoulson: you reassigned bug #518352 based on answers from someone other than the bug submitter? :)
<ubottu> Launchpad bug 518352 in plymouth "[lucid] if booting without 'splash', gdm starts X on wrong vt" [Medium,New] https://launchpad.net/bugs/518352
<chrisccoulson> slangasek - oh, i didn't notice that the person who replied wasn't the submitter ;)
<micahg> pitti: do I need this line in the apport hook for firefox to allow for PPA submsision?  report['CrashDB'] = 'firefox'
<FP1> hello
<FP1> how do i start developing for ubuntu?
<Tm_T> FP1: by joining #ubuntu-motu (:
<FP1> do i download the ubuntu source code also? and thank you
<FP1> and can i use eclipse for developing?
<qense> FP1: A new IRC channel for developign applications has just been opened at #ubuntu-app-devel It's just a few minutes old!
<FP1> thanks :D
<FP1> can i actually help develop the os?
<qense> FP1: Yes, but it is not like there is one place all applications are written.
<FP1> do you get it on launchpad?
<qense> There are many different projects all over the internet and Ubuntu takes its pick from those and puts them together.
<qense> Some applications are written by Ubuntu self, though.
<FP1> are they developed in C++?
<qense> FP1: There are some applications on Launchpad, yes.
<qense> FP1: That varies enourmously.
<sebner> FP1: most ist in python
<FP1> ok :P
<sebner> *is
<sebner> from the *self-developed* stuff
<qense> but the graphical interface you see is mostly written in C
<qense> Whereas the office applications uses Java
<FP1> oh, cool
<FP1> is there any good developing applications out there for linux
<qense> e.g. the chat client Empathy isn't developed by us, but by other people at www.gnome.org
<qense> we do develop Update Manager
<FP1> i've heard of eclipse
<qense> Eclipse is indeed a very powerful IDE
<FP1> do you suggest using eclipse?
<FP1> im on empathy now :P
<qense> It depends on your personal preferences and what you're doing with it.
<qense> I'm using 'gedit' for developing, not Eclipse.
<qense> There is also Anjuta, MonoDevelop, NetBeans and a lot more.
<FP1> i use gedit for website developing but never new you could use it for programming also
<FP1> *knew
<qense> You don't _have_ to use a certain application for programming.
<qense> Any text editor will do.
<FP1> ok
<qense> but lets continue this conversation in the new channel
<FP1> at #ubuntu-app-devel ?
<qense> yes
<FP1> ok
<superm1> crimsun, why do i have my annoying beep back in lucid rather than the pretty ding sounds that I got from karmic for my system bell?
<superm1> is that intentional?
<crimsun> superm1: is module-x11-bell loaded? Which wm are you using? Is the beep element enumerated in your [alsa]mixer?
<superm1> crimsun, this was a fresh lucid gnome install.  how do I query if module-x11-bell is loaded?
<superm1> I do see a "PC Beep" in my alsamixer, it's set to 0 by default
<superm1> but not muted
<crimsun> superm1: pactl list |grep x11-bell
<superm1> crimsun, yeah it lists it
<crimsun> superm1: is your PC Beep also a binary toggle [mutable]?
<superm1> Yes
<crimsun> heh.
<crimsun> well, we appear to have (erroneously) dropped the patch to sound/pci/hda/hda_beep.c that disables it by default.
<superm1> crimsun, well glad it's something silly :)
<eut> is anyone aware of what version of libstdc++ the libstdc++5 and libstdc++6 packages correspond to? (i'm trying to find out which libstdc++ release i want to download and install)
<RAOF> eut: libstdc++5 is built from gcc3.3 source; everything later is libstdc++6.
<eut> RAOF, is it possible to install the older hardy package on 9.10? http://packages.ubuntu.com/hardy/amd64/libstdc++5/download
<crypt-0> it *should* possible, but i wouldn't advise it
#ubuntu-devel 2010-02-16
<blut> where do i get ubuntu support?
<blut> cant join the #ubuntu channel
<micahg> blut: try again, wfm
<blut> 16:59 -!- Cannot join to channel #ubuntu (You are banned)
<micahg> blut: well, if you were banned you're not likely to get support...
<micahg> idk what the policy is
<blut> ...
<blut> micahg: i have never been in there before!
<micahg> blut: you can file a request here: https://answers.launchpad.net/ubuntu
<micahg> blut: ah, that's a problem
<micahg> blut: hold on
<persia> mvo: ubuntu-dev-tools is the least owned package in the archive :)  If you have a useful script to share, please add it (and it's manpage) with alacrity :)
<nigelb> I'm looking for a main sponser to review a patch I have submitted :), bug 398873
<ubottu> Launchpad bug 398873 in xkeyboard-config "Typo in gnome-keyboard-properties" [Low,In progress] https://launchpad.net/bugs/398873
<Mirv> cjwatson: btw I didn't know there is also modem-modeswitch shipped in udev already... anyway, eg. Josh seems to indicate kernel developers would not want switching in the kernel code: http://www.draisberghof.de/usb_modeswitch/bb/viewtopic.php?p=1906#1906
<Mirv> and that modem-modeswitch should be removed and is obsoleted by its developer
<pitti> Good morning
<pitti> crimsun: symptoms> apport.hookutils has helpers for the common cases: getting a package's modified conffiles (attach_conffiles) and non-default gconf values (attach_gconf)
<pitti> crimsun: see python -c 'import apport.hookutils; help(apport.hookutils)'
<pitti> crimsun: we don't have functions other than that, since for general conffiles there's not much abstraction that you could do (if you have some ideas, I'm all ears)
<poet> where does the LiveCD store files?  I'm out of disk space on the LiveCD because I copied over a large file.  Deleted the file, trash is empty, disk is still full
<pitti> poet: it's all in a RAM disk
<pitti> so you can't do file operations which change more than your RAM size minus half a GB (which is necessary for ubuntu itself)
<nigelb> Can a main sponsor review a patch I have submitted :), bug 398873
<ubottu> Launchpad bug 398873 in xkeyboard-config "Typo in gnome-keyboard-properties" [Low,In progress] https://launchpad.net/bugs/398873
<dholbach> good morning
<dupondje> On 2010-02-15 19:03z (1 hours 48 minutes ago), you uploaded a translation template for aptitude in Ubuntu Lucid package "aptitude" in Launchpad. => Translation template ?!
<pitti> just ignore that, it's spam from Launchpad translation imports
<dupondje> owkej :)
<dupondje> btw, is there a bugreport about the login screen is something broken @ boot ?
<dupondje> tought it was a bug in xorg-server-core and got fixed, but still having it sometimes
<ogra> dont upload openoffice :) the langpack spam can go on for days :)
<apw> pitti, should i be expecting an archive tool to be installed by default on a lucid install?
<tkamppeter> pitti, hi
<apw> (specifically ubuntu-build)
<pitti> apw: archive as in .zip, etc.?
<dupondje> ogra: lol :) spamfiler++ :)
<apw> pitti, as in ubuntu-build ...
<pitti> apw: hm, that's not expected; that's from ubuntu-dev-tools
<pitti> hey tkamppeter
<apw> pitti, how can i tell if its my fault its installed?
<pitti> apw: ubuntu-dev-tools isn't in http://cdimage.ubuntu.com/daily-live/current/lucid-desktop-i386.manifest
<tkamppeter> pitti, I have SRUed bug 513690, can you approve the foomatic-filters package in -proposed? Thanks.
<ubottu> Launchpad bug 513690 in foomatic-filters "Xerox WorkCentre 7245 (7228) prints only first page" [Medium,Fix committed] https://launchpad.net/bugs/513690
<apw> pitti, then i guess somehow i've asked for it ... hrm
<pitti> tkamppeter: I'll process it when I do my round of SRUs this week; thanks!
<ogra> apw, there is a flag somewhere that sets it to manually installed ... (beyond the meta checks you can do in the manifest file)
<pitti> apw: it's a very useful package to have, though :)
 * ogra doesnt know where that lives exactly though
<apw> heh but its suddenly started using names of scripts i already had which is inconvienient
<persia> apw: The trick is that when you write a script to help with development, commit it to ubuntu-dev-tools before someone else steals the namespace :)
<ogra> heh
<persia> Well, that's the point of u-d-t, isn't it?  So that we all share and improve the same set of scripts?
 * apw adds  'if (ircnick == persia) { panic(); } to the kernel
 * persia limits apw's uploads to not include the kernel
 * apw takes the week off
<persia> And this is why we have the values of cooperation and mutual support :)
<mvo> ubuntu-dev-tools> can I haz edit-patch in there?
<seb128> mvo, what is edit-patch?
<mvo> seb128: a wrapper that auto-detects the patch system and DTRT
<mvo> seb128: works with cdbs-edit-patch, dpatch-edit-patch, quilt
<seb128> mvo, does it handle quilt nicely?
<seb128> ie export QUILT_PATCHES
<seb128> quilt push
<seb128> etc?
<mvo> yes
<seb128> \o/
<seb128> go go go
<mvo> even bzr add debian/patches/new_patch
<seb128> just upload!
<seb128> ;-)
<mvo> :) credits for dholbach for the idea
<jpds> mvo: Is it related to watch-patch in there?
<mvo> needs a bit of testing, but hey - this is lucid
<jpds> what*
<mvo> jpds: no, but they overlap in the auto-detection, I guess that is where they can/should share code
 * mvo was not aware of what-patch
<persia> mvo: Please do add any tools you want (sorry if my previous response was lost)
<persia> mvo: And please don't ask next time: u-d-t is for us all to share our best scripts to help make development easier.
<mvo> cool, thanks
<apw> pitti, any idea what is causeing the partial updates in our burn-down charts?  i am guessing we have only our wiki entries.  may make more sense to drop those days completely
<pitti> apw: partial updates?
<apw> pitti, http://people.canonical.com/~pitti/workitems/canonical-kernel-team.html <-- four days back and like 16
<pitti> oh
<pitti> those happen if the WI tracker crashed either all day, or in the very last run of the day
<pitti> sometimes happens if LP is down
<ogra> apw, that points out where the team was really slackish :)
<apw> heh
<pitti> or just falls over with those silly "cannot decode JSON object" stuff, etc.
<pitti> apw: the 12th was a bug in the WI tracker, not being able to cope with blueprints being milestoned to "later"
<apw> if we are usiing a single transaction i'd expect the DB to not get updated in that case
<pitti> this is fixed now
<pitti> but since it was on the weekend, I didn't fix it fast enough
<pitti> apw: right
<pitti> apw: but you'd still not get any WI data for that day if it fails all day
<apw> pitti, perhaps we should purge the wiki data for that day too, so its clear there is no data for the day
<pitti> and then there's sqlite which is apparenlty not  ... entirely compliant .. to transactions
<q0k> hi
<apw> pitti, gnote is dumping core when i run it, (core dumped) and everything, but i don't see a (!) to report it ... whats the best way to diagnose that
<apw> (the apport failure)
<dupondje> you should be able to run apport manually :)
<apw> yeah but i want it 'retraced', i don't just want to file the bug, i want the core included
<pitti> apw: do you have a /var/crash/_usr_bin_gnote.1000.crash ?
<apw> yeah i do
<apw> pitti, ok moving that aside got it to pop up and ask again.  i think i hit restart and notthing happened, so i hit cancel and it went away.  for ever
<pitti> ah, right, then it's "touched"
<Greenwill> Who has a Fujitsu s7220... please contact me... i'm out of Japan and out of USA... i can't buy a fujitsu s7220 laptop here... if i order it from japan and ubuntu doesn't run on it i'll have big troubles...i didn't find it at https://wiki.ubuntu.com/LaptopTestingTeam/Fujitsu  ... could you test it ? (take installation video)please let me know bobgreenwill@openoffice.org thanks in advance
<persia> IRC doesn't really work that way
<Tm_T> awww
<Chipzz> actually
<Chipzz> I feel like mailing this greenwill idiot and telling him the laptop works
<Chipzz> (and hope it doesn't)
<Tm_T> Chipzz: no need to call him an idiot, though
<persia> That's not best.
<persia> It probably doesn't work, and probably needs some bugs filed.
<persia> Same question was asked (with same idle time) also in other channels :(
<persia> Needs someone to send a nice mail explaining how to get support.
<Chipzz> Tm_T: failure to read channel topic and blatant violation of it -> idiot
<Tm_T> Chipzz: still no need to call him that
<Chipzz> so what do you call ppl like that then?
<Tm_T> I just don't call them loud, I keep it in myself (:
<Tm_T> keeps the atmosphere more friendly, I'd sat
<Tm_T> say
<Chipzz> persia: personnally I prefer the saying it does and having him blow money on it approach :P
<Chipzz> apparently ppl only learn the hard way
<persia> Chipzz: I don't think that approach is the one that leads to the best result in terms of Ubuntu's hardware support, and I prefer to concentrate on that (because I actually care a little), rather than on user behaviour (because there are lots of other users)
<Chipzz> persia: ubuntu hardware support is an orthogonal issue
<persia> Chipzz: Also, consider the possibility that the user is incredibly intelligent and well informed in several areas, but has never used IRC before, and is completely unaware of how it works.
<Chipzz> if he's unaware of how it works
<Chipzz> he shouldn't be using it
<Chipzz> are you driving a car if you don't have a drivers licence?
<Tm_T> Chipzz: should we say same to all users in #ubuntu too? (:
<persia> Well, except that lots of documentation indicates that one *should* use IRC to request support.
<Tm_T> persia: exactly
<persia> That users may not know how the first time is an opportunity for education (which we can take or not as we prefer, individually)
<Chipzz> then said documentation should do a better job of educating users on how to use irc
<persia> I'll agree with that :)
<Chipzz> like telling the users to read the frigging topic BEFORE asking questions
<Chipzz> and after reading it, also comprehending and obeying it
<Chipzz> persia: anyway, given that a) he uses an @openoffice.org address, which indicates he is a developer and thus fully aware of how things work in the opensource world, and b) he was doing it on multiple channels it's a pretty good guess that he was fully aware of what he was doing and wether or not it was acceptable behaviour
<Chipzz> http://answers.yahoo.com/question/index?qid=20100216041614AA3ScID
<pitti> zul: just noticed that the dhcp3-client apport package hook only attaches audit logs, related package info, etc. if you agreed to attach dhclient3.conf; that doesn't look intended?
<pitti> zul: perhaps most/all of that stuff should be done outside the "if response == True"?
<zul> pitti: agreed
 * pitti is just reviewing the existing hooks and is impressed how many we have these days
<tseliot> Keybuk: do we do something like "press this key to stop the fsck in Plymouth" already? If so, how do you call plymouth from mountall to write the "press this key..." line? Do you use "--update=" and then watch-keystroke or do you use "message" instead of "--update="?
<pitti> people use interactivity, and all that
<Keybuk> tseliot: err
<tseliot> too many questions? :-P
<Keybuk> tseliot: ply_boot_client_tell_daemon_to_display_message()
<Keybuk> then ply_boot_client_ask_daemon_to_watch_for_keystroke()
<Keybuk> with ply_boot_client_update_daemon() before both of those
<Keybuk> so all three ;)
<tseliot> Keybuk: ok, so you're using "message" to request action and "update" to update the status of fsck
<Keybuk> tseliot: right
<Keybuk> so update to update the fsck progress
<Keybuk> then message to put a message on the screen about being able to cancel
<Keybuk> then watch for keystroke to actually get told if they press that key
<tseliot> Keybuk: ok, I was asking as I'm reimplementing a few functions in the theme and I wanted to implement bug #497311
<ubottu> Launchpad bug 497311 in plymouth "Support additional separate places for messages" [Wishlist,Triaged] https://launchpad.net/bugs/497311
<Keybuk> right
<tseliot> Keybuk: so, with that feature you would have to call ply_boot_client_tell_daemon_to_display_message() twice
<Keybuk> I would?
<tseliot> if you wanted to have 2 lines
<Keybuk> that's ok ;)
<tseliot> ok
<Keybuk> it was more wanting to have a line along the bottom to put keypress information
<Keybuk> "Press C to cancel" etc.
<Keybuk> since the middle is already taken up by the theme's fsck stuff
<tseliot> ok, so the theme would have 1st line = message, 2nd line = fsck status, 3rd line = action text
<Keybuk> sure
<tseliot> Keybuk: at this point I think that implementing bug #509373 would not be trivial
<ubottu> Launchpad bug 509373 in plymouth "Plymouth doesn't wrap long messages" [Wishlist,Confirmed] https://launchpad.net/bugs/509373
<tseliot> well, doing it right, that is
<tseliot> Keybuk: do you think I can postpone that? Or do you need that feature too?
<Keybuk> tseliot: wrapping of long lines seems more of a DX issue to me ;)
<Keybuk> it's definitely "experience" related
<tseliot> Keybuk: ah, so the question would be more whether we want to have long lines or not
<tseliot> it makes sense
 * mvo is impressed by the amount of "OK" in http://people.ubuntu.com/~mvo/automatic-upgrade-testing/2010-02-16-12:16:25/
 * pitti hugs mvo, splendid!
<tseliot> :-)
<pitti> mvo: is that "default install" or "all of main"?
<pitti> mvo: does that include checks for bad "changed conffile" prompts?
<mvo> pitti: that is the default install, main-all is running still
<mvo> pitti: confile prompts do currently not cause failures, but they appear in the logs, I should make them fatal :)
<pitti> ah, I already hoped.. :)
<mvo> 2010-02-16 14:19:15,645 WARNING got a conffile-prompt from dpkg for file: '/etc/X11/app-defaults/Xedit'
<mvo> 2010-02-16 14:24:06,125 WARNING got a conffile-prompt from dpkg for file: '/etc/default/apport'
<mvo> the apport one is a false positive
<mvo> I think its caused by the upgrader itself
<pitti> right, I recently handled a bug report for that and assigned it to update-manager
<mvo>  '/etc/X11/app-defaults/Xedit' <- that one has a open (and targeted) bugreport
<pitti> perhaps we could copy the new version's file instead of just changing the value
<tkamppeter> pitti, hi
<tkamppeter> pitti, I have got a package for the "ptouch" label printer driver (http://www.openprinting.org/show_driver.cgi?driver=ptouch) and I have reviewed it and added the standard Ubuntu extensions (PPD update, Apport hook).
<tkamppeter> pitti, now I want to upload the package. Is it possible to get it in before FF?
<pitti> tkamppeter: sure, it's not Thursday yet
<frafu> Hi, onboard is the default onscreen keyboard that ships with Ubuntu. As the ubuntu developers always patch the packages that I prepare to hide the menu items of onboard, I would like to ask whether somebody can tell me, who I can contact to discuss a way to let them visible. (Maybe by moving them from the Universal Access menu to the Accessories menu.)
<pitti> everythign which is in NEW by Thursday won't need extra red tape
<tkamppeter> pitti, so I simply upload it. Is it possible to MIR it to Lucid main after FF?
<sebner> pitti: do you know by any chance when cjwatson will return?
<unimatrix> any rhythmbox developers here by chance?
<pitti> sebner: next week, he's on holiday this week
<sebner> pitti: ohh, then I need to find someone else willing to backport dpkg on the build machines :\
<pitti> tkamppeter: does it need to be in main? but yes, no big problem
<ion> Le sigh, an apparmor profile change on upgrade caused the computer to grind to a halt again, thanks to the kernel module misbehaving.
<tkamppeter> pitti, it is a printer driver, which means hardware support. Having it in main gives more Plug'n'Print already from the live CD.
<pitti> tkamppeter: adding it to the CDs is a bigger step, we have to justify CD size versus popularity
<cvincenzo> hello there
<Jeeves_> Am I allowed to ask this channel about packagebuilding issues? Or is there a more appropriate channel?
<nigelb> Jeeves_: #ubuntu-motu would be a good place
<hyperair> #ubuntu-motu for universe packages
<hyperair> for main packages, this is the right place
<Jeeves_> Yeah, well. It's a private package :)
<Jeeves_> I'm having issues with dh_shlibdeps
<cvincenzo> can someone tell me whether packages of ubuntu for NAT and firewall there, so does the server (ubuntu) as a firewall and router?
<Jeeves_> cvincenzo: This question is better for #ubuntu-server
<cvincenzo> thank you Jeeves
<Jeeves_> yw
<Riddell> what's up with libmysqlclient16 on amd64?  I get a 403 forbidden
 * Riddell eyes up zul as a potential guilty party
<persia> Riddell: There was some version issues such that it caused everything to FTBFS only on amd64.  Didn't affect other arches because the source package that provided the messy version FTBFS there.
<persia> Riddell: There's a bug about it/
<persia> bug #521815
<ubottu> Launchpad bug 521815 in mysql-cluster-7.0 "breaks all builds requiring libmysqlclient-dev" [Critical,Fix released] https://launchpad.net/bugs/521815
<zul> Riddell: yes its in middle of being fixed
<Riddell> good luck
<pitti> Riddell: you can just purge the lib from your system to be able to dist-upgrade again
<pitti> I guess it was pulled in at some point, but nothing uses it
<Riddell> I'm just impatient for my packages to build :)
<pitti> I and someone else were able to get rid of it without problems
<pitti> oh, ok
<pitti> shouldn't that already work?
<Riddell> not if libmysqlclient16 can't be installed
<Riddell> it's still the 7 version according to my apt
<ari-tczew> ttx: ping
<ttx> ari-tczew: opng
<ttx> pong
<ari-tczew> ttx: could you take a look again @ bug 515259 please?
<ubottu> Launchpad bug 515259 in libcommons-attributes-java "Please merge libcommons-attributes-java (2.2-7) from Debian Testing" [Wishlist,Incomplete] https://launchpad.net/bugs/515259
<ttx> ari-tczew: sure
<ttx> ari-tczew: would you happen to also have the Ubuntu-1/Ubuntu debdiff ?
<ttx> ari-tczew: (debdiff libcommons-attributes-java_2.2-6ubuntu1.dsc libcommons-attributes-java_2.2-7ubuntu1.dsc)
<ari-tczew> ttx: I'm not Vikram, I can make debdiff, it's should be correct ;-)
<ari-tczew> txx: debdiff libcommons-attributes-java_2.2-7.dsc libcommons-attributes-java_2.2-7ubuntu1.dsc > libcommons-attributes-java_2.2-7ubuntu1.debdiff
<ari-tczew> s/txx/ttx
<ttx> ari-tczew: that's debian/Ubuntu debdiff
<ttx> ari-tczew: both are useful for review
<ttx> ari-tczew: I need 2.2-6ubuntu1 -> 2.2-7ubuntu1
<ari-tczew> ttx: what's the different method?
<sebner> ari-tczew: about belpic: See this bug and especially the last comment. not really a reason to merge: https://bugs.edge.launchpad.net/ubuntu/+source/belpic/+bug/514174
<ubottu> Ubuntu bug 514174 in belpic "Please update belpic to the latest debian version 2.6.0-7.2" [Undecided,Incomplete]
<ttx> ari-tczew: debdiff libcommons-attributes-java_2.2-6ubuntu1.dsc libcommons-attributes-java_2.2-7ubuntu1.dsc > ubuntu-to-ubuntu.debdiff
<ari-tczew> ttx: why ubuntu-to-ubuntu? I 1st one heard about this
<ari-tczew> sebner: so this is job for coolbhavi
<sebner> ara:
<sebner> argh
<ttx> ari-tczew: see https://wiki.ubuntu.com/UbuntuDevelopment/Merging (search for "If you need sponsorship, you should generate two debdiffs")
<sebner> ari-tczew: He hasn't reported it yet (wondering if he'll do it) but until it's fixed in Debian and no new upstream version there is no reason to merge currently
<ari-tczew> ttx: so are you think. that my last attachment is not useful?
<ttx> ari-tczew: it is useful. I just prefer to have both of them.
<ari-tczew> ttx: so please just upload it. btw: please see https://merges.ubuntu.com/libc/libcommons-attributes-java/libcommons-attributes-java_2.2-6ubuntu1.patch if it will be useful for you ttx
<ari-tczew> sebner: You have searched for packages that names contain belpic in all suites, all sections, and all architectures. @ packages.debian.org :-/
<Chipzz> errr
<sebner> ari-tczew: I don't understand?!
<Chipzz> you might consider coordinating with Yoe?
<Chipzz> doesn't he maintain that package?
<ari-tczew> sebner: packages.debian.org can't found package belpic
<Chipzz> ari-tczew: then you fail at searching
<Chipzz> ari-tczew: pretty certain Yoe maintains a package for it in debian
<sebner> ari-tczew: I know, the search is b0rken somehow. You can find it on some other way
<sebner> ari-tczew: http://packages.qa.debian.org/b/belpic.html  <-- here you go ;)
<ari-tczew> Chipzz: so please @ Yoe for fix section issue
<Chipzz> ari-tczew: he's on irc, on the #debian-devel channel
<ari-tczew> [16:27] [473] ari-tczew #debian-devel Cannot join channel (+i) - you must be invited ; regards ;-)
<Chipzz> you may want to consider trying irc.debian.org? :P
<ari-tczew> sebner: if Section field will be added into debian/control, is it possible to sync package?
<ari-tczew> btw. I'm going to request bug @ debian, because coolbhavi now is on MOTU meeting
<sebner> ari-tczew: Yeah, it's syncable then.
<pitti> cr3: bonjour
<ttx> ari-tczew: uploaded
<ari-tczew> ttx: could you take a look too @ bug 521390
<ubottu> Launchpad bug 521390 in junitperf "Merge junitperf 1.9.1-7 (main) from Debian testing (main)" [Undecided,Confirmed] https://launchpad.net/bugs/521390
<pitti> cr3: you have an alpha-3 work item "provide list of types of problems that we should make symptoms for:" (https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-lucid-bug-management); is that still relevant? should we postpone/drop it? will be done this week?
<ttx> ari-tczew: not just now
<pitti> cr3: (just cleaning up teh remaining WIs and was curious about that one)
<ari-tczew> maybe pitti ?
<czajkowski> I really need to unhighligh cz :(
<cr3> pitti: I've been thinking about it and I've even been asking the support folks for suggestions, so it's on my radar
<mathiaz_> james_w: hi - could you schedule an import of the puppet package in sid in the package branch?
<mathiaz_> james_w: LP has imported the new version from sid and I'd like to merge the package via bzr
<ari-tczew> sebner: how are you think, should do I make debdiff for NMU or make debdiff which will include only debian/control changes?
<sebner> ari-tczew: I'm wondering that you are doing something for this little change
<james_w> mathiaz: it's running now
<mathiaz> james_w: o^42
<james_w> 5 minutes or so
<james_w> mathiaz: how was FOSDEM?
<mathiaz> james_w: great!
<mathiaz> james_w: it was my first time there
<mathiaz> james_w: so had to get used to the whole navigation
<mathiaz> james_w: lots of talks to choose from
<james_w> mathiaz: excellent
<mathiaz> james_w: http://fosdem.org/2010/schedule/events/dist_topgit
<mathiaz> james_w: ^^ that one was interesting wrt to package branches
<james_w> yeah
<mathiaz> james_w: nothing ground breaking though - it's similar to what we discussed with bzr looms
<mathiaz> james_w: the list of tools/helpers is interesting though
<james_w> mathiaz: yeah, it would be their implementation of it
<mathiaz> james_w: I'll publish a blog post about fosdem soon
<james_w> ace
<jibel> mvo, ping
<mvo> hello jibel
<Laney> could someone possibly rescore https://launchpad.net/ubuntu/+source/ghc6/6.12.1-9/+build/1512010 for me? I would like to know whether it builds yet...
<LaserJock> does apt-get source always tell you if a package is maintained in bzr or not?
<mathiaz> james_w: http://paste.ubuntu.com/377693/
<mathiaz> james_w: ^^ have you already seen this error?
<geser> mathiaz: know bug
<jibel> mvo, hello, I'm working on synaptic "sorting" issues of the package list.
<mathiaz> geser: is there a workaround?
<jibel> mvo, we currently can't sort by package name and I noticed there is no sort mode to change the sort order of this column. Is it intended or do you need a fix ?
<jibel> mvo, see bug 518509
<ubottu> Launchpad bug 518509 in synaptic "package manager package column header not sorting" [Low,Triaged] https://launchpad.net/bugs/518509
<geser> mathiaz: bug 515597 and the "workaround" is to modify /usr/lib/python2.6/dist-packages/bzrlib/merge.py line 153 to "return self.merge_text(params)" (remove the second self)
<ubottu> Launchpad bug 515597 in bzr "TypeError: merge_text() takes exactly 2 arguments (3 given)" [Critical,Fix released] https://launchpad.net/bugs/515597
<geser> or wait for the bzr 2.1.0 release
<mathiaz> geser: awesome! thanks
<mvo> jibel: hi, let me check the bug
<mvo> jibel: you mean that reverse sorting is not working? it would be nice to fix that
<jibel> mvo, you can only sort packages in ascending order, descending does nothing.
<jibel> mvo, in rpackagelister.cc only LIST_SORT_NAME is defined.
<mvo> jibel: right, I remember now, it should be realtively straightforward to fix I hope, the other sorting columns should give you the needed info. do you think you could work on this code? I'm happy to help with specific questions
<jibel> mvo, working on it then. I'll try to fix bug 165181 in the mean time.
<ubottu> Launchpad bug 165181 in synaptic "Order by "Supported" Column Slow" [Medium,Triaged] https://launchpad.net/bugs/165181
<mvo> nice! thanks jibel
<mvo> jibel: I will send you tee or beer (whatever you prefer) as a thank-you :)
<dupondje> how come that packages in NEW take sometimes really long before it gets into archives ? :)
<pitti> mvo: any idea why http://people.ubuntu.com/~mvo/automatic-upgrade-testing/current/ points to Feb 08?
<Keybuk> ev: you guys should totally aim for a 10s install in lucid+1
<ev> hrm, where did I put that ice pick
<mvo> pitti: yes, a bug in the script that updates the current symlink, I fix now
<pitti> mvo: you rock, thanks
<mvo> np
<dupondje> http://archive.ubuntu.com/ubuntu/pool/main/m/mysql-cluster-7.0/libmysqlclient16_7.0.9-1_amd64.deb
<dupondje> this seems broken ...
<dupondje> dunno who can fix this :)
<lucasr> jcastro, ping
<jcastro> pong!
<jcastro> lucasr, what can I do for you?
<mathiaz> zul: ^^ - argh - libmysqlclient16 got bumped
<zul> mathiaz: yeah i know im working on it
<mathiaz> zul: mysql-dfsg-5.1 will have to be fixed as well
<zul> mathiaz: it either needs to be fixed in soyuz (prefered) or i have a work around
<zul> mathiaz: http://people.canonical.com/~chucks/libmysqlclient-fix2.patch
<mathiaz> zul: why not use DEB_UPSTREAM_VERSION_MAJOR_MINOR?
<mathiaz> zul: instead of UPSTREAM_VERSION?
<mathiaz> zul: that would give: 7.0.9really5.1.41
<mathiaz> zul: well that wouldn't actually work
<mathiaz> zul: hm well - I'm not sure what's the correct answer here
<zul> mathiaz: i been discussing it with slangasek as well
<mathiaz> zul: upgrading to futur libmysqlclient16 packages should work as well
<mathiaz> zul: DEB_NOEPOCH_VERSION should give you 5.1.41-3ubuntu5
<mathiaz> zul: well - for a long time there was a  libmysqclient15off
<mathiaz> zul: I don't remember where the libmysqlclient15off was coming from
<dupondje> mathiaz: is that the reason http://archive.ubuntu.com/ubuntu/pool/main/m/mysql-cluster-7.0/libmysqlclient16_7.0.9-1_amd64.deb has permission error ?
<mathiaz> dupondje: may be
<mathiaz> mysql-cluster-7.0 ended up in main as well - which shouldn't have been the case
<YokoZar> I have a very special problem with Lucid - Gnome works, I can run calculator and everything, but entering any terminal command or creating a folder in nautilus causes an instant deadlock.  I'm not even sure how to report such a problem
<hyperair> what deadlocks?
<YokoZar> hyperair: cpu goes to 100%, I hear fans spinning, no mouse movement.
<YokoZar> I suspect maybe dbus
<hyperair> use teh conky.
<hyperair> i dont see how running some random terminal command can fry dbus
<YokoZar> It's the only thing I can think of that create folder and terminal might have in common, though I'm not too familiar on the internals
<kees> pitti: say, should I be expecting apt to remove devicekit-disks?
<james_w> kees: devicekit-disks -> udisks
<james_w> so it should be installing the latter at the same time?
<YokoZar> pitti: do I need to file a separate bug to ask for branding-ubuntu to be added to the seed or is getting in main enough?
<sebner> YokoZar: ohh, what a fortune :) Did you get my mail?
<YokoZar> Yeah one sec
<kees> james_w: okay, cool.  yeah, it installed udisks.
<kees> james_w: why are we not using Debian's devicekit-disks?
<james_w> kees: it's an upstream rename
<kees> ah-ha! ok
<james_w> http://ftp-master.debian.org/new.html
<superm1> its really annoying for downstreams too... having to update to use all the new names and keys and what not
<ccheney> ScottK: we aren't planning to transition to boost 1.41 this cycle are we?
<ScottK> ccheney: Not AFAIK, no.
<ccheney> ScottK: ok, i saw it was in the archive but still in universe atm
<ScottK> boost-defaults |   1.40.0.1 |         lucid | source
<ccheney> ah ok :)
<ScottK> I expect it to stay there.
<slangasek> phew :)
<smoser> i've a packaging question. what is the general rule for the name of 'Source'. should it be the same as upstream package name (to the extent possible) or should it be the same as the binary.
<smoser> as an example: http://sourceforge.net/projects/snoopy/
<sebner> smoser: what's the binary name?
<slangasek> smoser: I believe the general rule is to name the source package to match the upstream package name as closely as possible, unless you're packaging perl
<smoser> project is 'snoopy', but package (and in this case Source) is 'libphp-snoopy'
<slangasek> (though arguably, the perl source package naming also matches upstream "as closely as possible")
<sebner> smoser: I'd go with snoopy then
<smoser> i'm looking to package 'cloudfusion' which would have a binary named 'libcloudfusion-php'
<smoser> thanks.
 * slangasek sees multiple mentions of php and looks around for his wooden stake
<slangasek> DktrKranz: how frequently do you poll for new upstream versions of launchpadlib?
<slangasek> DktrKranz: I'm told to expect a new upstream release before FF, would you prefer that I let you package it in Debian first or shall I prep it in Ubuntu and forward you my changes?
<DktrKranz> slangasek: usually when I'm aware of them (I usually look at DEHS, but once per week I scan homepages for updates). I can prepare it quickly when it will be released, if you can give me a IRC ping if I'm late on it, I can arrange things.
<slangasek> DktrKranz: ok, cheers :)
<DktrKranz> :)
<lifeless> mvo: ping
<lifeless> mvo: just had an interesting question in -motu; do-release-upgrade won't attempt hardy->lucid yet, it goes to intrepid instead.
<lifeless> mvo: shouldn't we permit that (when -d is given) so that the ugprade path can be tested?
<kees> lvm2 merge uploaded... hold on to your hats
<lifeless> kees: nooooooo
<slangasek> <Ã´>
<kees> pitti: in talking to Debian upstream, it seems that the symlinks are correct
<kees> lifeless: ??
<lifeless> kees: I'm teasing.
<kees> pitti: (for lvm uuid and name)
<kees> lifeless: oh, whew.  okay :)
<slangasek> lifeless: and for you: <Å>
<kees> slangasek: wow, you had that art at the ready.  nice.  :)
<slangasek> kees: only in the sense that I am well versed in the extended Latin alphabet ;)
<kees> hehe
<mvo> lifeless: yes, that should actually work "do-release-upgrade -d"
<lifeless> mvo: apparently its not
<mvo> hmm
<lifeless> its selecting intrepid
 * mvo looks
<mvo> *ick*
<mvo> lifeless: I joined #motu now
<kees> lifeless: how do I upgrade a remote bzr tree?
<lifeless> bzr upgrade url
<lifeless> or ssh host bzr upgrade path
<lifeless> or rsync locally; bzr upgrade; rsync back
<kees> lifeless: bzr: ERROR: File exists: '/srv/bazaar.launchpad.net/push-branches/00/00/3c/c9/backup.bzr'
<lifeless> kees: two things; click on the button in the web ui:)
 * kees goes looking for a button
<lifeless> kees: and you can delete that file using sftp (lftp is nice - lftp sftp://bazaar.launchpad.net/~user/product/branch)
 * kees â¥ lftp
<leonardr> DktrKranz: i'm talking with slangasek on #ubuntu-release about a pre-freeze launchpadlib release. he says you're doing the packaging
<leonardr> i'm going to try to have everything released by tomorrow morning, but i wonder how much lead time you'll need to do the packaging?
<leonardr> ie. when do i lose my opportunity?
<DktrKranz> leonardr: I'll be able to package it not before tomorrow, ~20 UTC
<DktrKranz> after that, I'll be back home and can manage it
<leonardr> ok, so i can be pretty late tomorrow as long as it's done tomorrow
<DktrKranz> leonardr: I could reserve some moments during work, if that would help
<leonardr> DktrKranz: i'm just trying to find out now so i don't get into a situation where i'm causing you stress
<leonardr> unless something goes catastrophically wrong in the next hour it should be available tomorrow for you to package whenever you like
<DktrKranz> that's great then :)
<kees> lifeless: hrm, how long should the LP-button-upgrade of a branch take?
<smoser> mathiaz, your patch looks good.
<smoser> i'm happy you generally figured out how you were "supposed" to do it.
<smoser> the only suggestion i have is
<smoser> if not self.cfg.has_key('puppet'): return
<smoser> to save yourself an indentation level
<mathiaz> smoser: :) - well I know how to read python code ;)
<smoser> but thats pretty nit-picky
<smoser> so, i'm good with it as it is if you like.
<lifeless> kees: 'a while'
<mathiaz> smoser: suggestion applied. Branch updated.
<kees> lifeless: heh
<smoser> merged.
<qense> What do <placeholder>s do in glade files?
<qense> What is their function?
<lifeless> kees: it has a async queue that it churns through. no idea if there is a status page
<PlainFlavored> hey, i'm learning C, is it alright if I paste a short piece of code that's not working out very well and have someone tell me what's wrong with it?
<ccheney> is mysql going to be fixed soon? its blocking OOo
<lamont> that's very sad... I looked at the armel builders to find one I could steal, and they're all doing long builds
<ccheney> lamont: trying to put OOo on one them too ;-)
<lamont> ccheney: gcc-snapshot bootstrap for um... something
<d1b> ccheney: please no !
<ccheney> zul: ping
<mathiaz> ccheney: zul is working on it with slangasek as well
<ccheney> ah ok :)
<ccheney> zul: thanks guys (saw above from mathiaz)
<d1b> PlainFlavored: wrong channel. try #c
<PlainFlavored> d1b: okay, thanks
<slangasek> ccheney: one way or another, should be resolved by Thursday
<ccheney> slangasek: ok
<ccheney> slangasek: i guess its complicated to fix? (i don't know what is wrong other than it ftbfs)
<slangasek> ccheney: libmysqlclient16 was inadvertently taken over by the wrong source package, and bumped the binary package's version number by a decade or so; looking at whether it's possible to roll this back in soyuz, with the fallback plan being to mock up a new binary version number for all eternity
<slangasek> (and option #1 requires containing the spread of the broken package version, which means not uploading option #2 until we've ruled it out)
<ccheney> oh wow, thats painful
<\sh> time to go home
<sebner> \sh: hf!
<\sh> sebner: I had already :) now it's family time...happy to see my little son again after a 20h day at work
<sebner> \sh: 1) Don't work that much 2) your son is awake at 00:26?
<\sh> sebner: yes :) his teeth are giving him some problems :) 10 teeth at a time is much pain :)
<sebner> urgh
<sebner> \sh: wrong smilies though :P
<\sh> anyways...good night :)
<sebner> \sh: gn8
<jp--> hi guys. can somebody check my forum post? I've got problems trying to get sound work on Jaunty, I think the kernel module for my sound card gets confused with the hdmi and rca output... http://ubuntuforums.org/showthread.php?p=8836492#post8836492  thank you =)
#ubuntu-devel 2010-02-17
<timob> bazaar.canonical.com
<timob> how can I use launchpad bazaar repo behind a proxy?
<lifeless> set http_proxy appropriately
<timob> lifeless: but doesn't launchpad use the lp scheme?
<lifeless> timob: sorry I don't know what you are asking
<ari-tczew> please sponsor debdiffs for fakesyncs bug 512430
<ubottu> Launchpad bug 512430 in geronimo-jpa-3.0-spec "Fake sync geronimo packages from Debian testing (main)" [Undecided,Confirmed] https://launchpad.net/bugs/512430
<nigelb> if a package is in bzr in ubuntu, do we submit merge requests/bzr diffs or debdiffs
<nigelb> package is gnome-media... main package
<TheMuso> nigelb: Submitting bzr merge requests via code.launchpad.net is best.
<TheMuso> nigelb: Because the those who work on the packages will receive the request.
<nigelb> ah, thanks  :)
<nigelb> should I update the changelog and such in this case?
<TheMuso> nigelb: Yes, if you update the changelog, the debcommit command can help you fill out the commit log.
<nigelb> okay, thanks again :)
<TheMuso> You're welcome.
<nigelb> okay, this package uses cdbs, I'm expected to create a cdbs patch too?
<TheMuso> nigelb: Depends on what your changes are.
<nigelb> just adding a patch that gnome upstream dev uploaded to fix a memory leak
<TheMuso> nigelb: Right then you shouldn't need to touch anything cdbs related.
<nigelb> TheMuso: just make the change and request a merge ?
<TheMuso> nigelb: yes once you have committed and pushed back to launchpad.
<nigelb> okay :)
<nigelb> thanks again
<TheMuso> np
<nigelb> does the patch command have trouble with white space?
<nigelb> I keep getting the error "patch unexpectedly ends in middle of line"
<TheMuso> nigelb: You can tell patch to ignore whitespaces, but it sounds like you need to reformat the patch. Since the package uses cdbs, the cdbs-edit-patch command ifs your friend here.
<nigelb> TheMuso: just edit the patch the normal cdbs way then?
<TheMuso> nigelb: cdbs-edit-patch will put you into a new shell where you can patch/edit your changes. When you exit the shell, cdbs-edit-patch creates the patch for you.
<nigelb> TheMuso: yea.  but I wanted to work out the way I can make minimum effort in case I run into a patch with a lot of changes
<TheMuso> man cdbs-edit-patch for more info.
<pitti> Good morning
<pitti> kees: devicekit-disks> superseded by udisks, so should be  fine
<mtx_init> hello sir
<pitti> kees: Debian> mbiebl and I are co-maintaining both; Debian will get udisks soon as well; our udisks is merely a git snapshot from the Debian packaging branch
<pitti> YokoZar: it should be on the default CD, right? we are currently struggling for CD space (7 MB overflown), need to figure that out first; can you please ping the MIR bug to ask for seeding it?
<pitti> kees: mirror image symlinks> hmm; seems a matter of taste to me, and I rather don't like them, but *shrug*; did they say why they ought to be there?
<kees> pitti: my understanding (upstream was a bit terse) is that the stuff in /dev/disk/by-id is literally everything that is a device, which includes the "internal" devices that devmapper/lvm use (i.e. they each have separate uuids, names, whatever).  but that filesystems are skipped because they're not sensible, I guess.
<kees> pitti: I think lvm needs another environment variable from the kernel called "internal" or something, so that it's easy to ignore those devices, etc.
<pitti> kees: well, it already identifies those devices (they are named _mimageN and _mlog)
<pitti> so that's not hard
<pitti> kees: but anyway, I'll update the test suite; thanks for investigating!
<YokoZar> pitti: There's a way to trim it so there's no net loss in CD space if needed
<pitti> superm1: thanks for fixing dell-recovery!
<ttx> pitti: hey, what would be your take on bug 376388 (especially suggested sudo changes at last comment) ?
<ubottu> Launchpad bug 376388 in etckeeper "~/.bazaar created owned by root (when run under sudo)" [Medium,Confirmed] https://launchpad.net/bugs/376388
<pitti> ttx: we won't make -H the default; it would break other use cases which rely on having the original $HOME, and general backwards compatibliity
<ttx> pitti: that was my sentiment as well, changing well-known behavior to fix a specific use case doesn't seem warranted
<ttx> pitti: could you comment on that effect to the bug (if not already done ?)
<pitti> ttx: done
<ttx> pitti: thx !
<dholbach> good morning
<jibel> mvo, hello
<mvo> hey jibel
<jibel> mvo, I fixed the column sorting issues in synaptic but have some question anyway
<mvo> jibel: nice! did you put it in a bzr brnach? or as  a patch?
<mvo> jibel: questions> sure, fire :)
<jibel> mvo, in common/rpackagelister.cc do you remember why there is a call to qsSortByName and then stable_sort. It seems redundant ?
<mvo> that is quite possible, let me check the source
<mvo> jibel: oh, now I do - IIRC its to have the package names sorted inside e.g. the sections, otherwise it will sort by section only and the package names are more or less random
<jibel> mvo, ok got it. question 2: bug 165181
<ubottu> Launchpad bug 165181 in synaptic "Order by "Supported" Column Slow" [Medium,Triaged] https://launchpad.net/bugs/165181
<jibel> in the sort function we call isSupported which calls isTrusted which queries the package cache, ... It's rather suboptimal.
<mvo> jibel: oh, let me have a look
<jibel> mvo, there is no easy fix. Don't you think we'd better disable the sort by "supported" column ?
<mvo> jibel: hm, let me have a look
<mvo> jibel: did you push the patch for #518509 already somewhere? I will ocmmit it right away :)
<jibel> mvo, not yet. I was waiting for this discussion.
<mvo> ok
<mvo> jibel: let me do a bit of profiling to see if I can come up with a idea
<wre> I have found a post http://ubuntuforums.org/showthread.php?p=8834757#post8834757  Maybe you know where to find an answer?
<mvo> jibel: I updated the bug and added a prototipish idea
<jibel> mvo, thanks, I will have a look at it.
<mvo> thanks :)
<jibel> mvo, finally I dropped the call to qsort and replaced it by stable_sort which is superior in performance. The interface is more responsive.
<mvo> jibel: sweet
<jibel> mvo, I commit the changes and let you review it.
<jibel> mvo, one more thing
<jibel> mvo, you owe me a beer
<mvo> jibel: for tests like this i often use a quick and check "clock_t now = clock(); { code; } cerr << time << clock() - now << endl;
<mvo> jibel: heh :)
<mvo> jibel: (to see if/how much performance difference there is)
<mvo> jibel: I will pay up gladly :)
<sebner> mvo: thanks for taking care of the dpkg issue :)
<mvo> sebner: cheers, but cjwatson was quicker already it seems
<sebner> mvo: really? He's a funny guy. Merging dpkg into lucid, then going on holidays and then doing the work nevertheless ^^
<mvo> sebner: indeed :) and he enjoyed it!
<sebner> mvo: ok, I'll make a test-upload to my PPA(?) and I'll let you know what going on?!
<mvo> sebner: I'm not sure its deployed yet
<sebner> oh, I'll wait some hours then
<sebner> mvo: btw, you are fine that I sync your new scite package?
<mvo> sebner: please
<sebner> fine :)
<mvo> sebner: I meant to write a sync request, but this is much quicker :)
<wre> _I have found a post http://ubuntuforums.org/showthread.php?p=8834757#post8834757  Maybe you know where to find an answer?_
<sebner> mvo: I did write one but Riddel was faster than incomming ^^, It's still stuck in there :( If it won't make it before FF I'll just make a manual upload
<Keybuk> james_w: I keep finding new ways in which having source packages in bzr is awesome
<Keybuk> today's
<Keybuk> uncommitted/unuploaded changes in the working tree, when a new upload occurs
<Keybuk> just bzr pull :)
<james_w> \o/
<ogra> seb128, so i just wondered why in my development apps all buttons dont have icons, then i found that we apparently dropped the UI to set /desktop/gnome/interface/buttons_have_icons from the appearance applet, how are users that have set that property in the past supposed to change it back ? shouldnt we apply the default when we disable them from setting such a property ?
<seb128> why would they want to change it back?
<seb128> if they did decide to set it this way
<ogra> i wasnt even aware i had changed it, took me a while ... i had changed it when i used my laptop screen instead of the external monitor, to save screen space on the small LCD
<seb128> well we default to not having icons now
<ogra> its something *i* decide on a usecase base (no idea if others set it because they like it or something)
<seb128> so you do have the default
<ogra> on all buttons ?
<seb128> yes
<ogra> woah
<seb128> buttons and menus
<seb128> it's that way since karmic
<ogra> my app menu surely has all icons here
<seb128> waking up some 6 months after the change? ;-)
<seb128> ogra, you don't use the default then
<ogra> and usually cancel buttons have a red circle with a cross
<ogra> hmm, i cant imagine to have changed anything apart from the buttons_have_icons when we still had it in appearance ... and only when i used my LCD
<seb128> ogra, gconftool --unset /desktop/gnome/interface/buttons_have_icons
<seb128> ogra, gconftool --unset /desktop/gnome/interface/buttons_have_icons /desktop/gnome/interface/menus_have_icons
<seb128> ogra, that will give you default values for both
<seb128> then run some GNOME app, ie gedit
<ogra> my app menu still has icons
<seb128> the gnome-panel one you mean?
<ogra> ah, they are gone from system
<ogra> yeah
<seb128> only things supposed to have icons are objects
<ogra> that makes the UI so much less exciting :P
<seb128> the apps categories have been decided to keep icons
<seb128> it was really looking weird without those
<seb128> but look in an app, ie gedit
<ogra> fine then, thanks for the help, i couldnt really imagine we drop icons from buttons
<seb128> menus and buttons
<seb128> ogra, talk to our design team ;-)
<seb128> ogra, though to be fair GNOME did the change, design was just agreeing on it
<ogra> i doubt i will convince them to change it back
<seb128> no, you are 6 months late for that discussion
<ogra> so i'd just waste my breath
<ogra> i didnt see it changed
<ogra> though the system was a fresh karmic install ...
<seb128> you probably didn't do karmic desktop iso testing ;-)
<ogra> and afaik the UI applet only applied to toolbars
<seb128> ogra, you kept your user config though?
<ogra> oh, right, i kept my homedir
<seb128> ogra, the ui has both options, toolbar and buttons
<ogra> ah, k
<seb128> or menus and buttons rather
<ogra> right, i remember menus and toolbars
<didrocks> is there any documentation page about how ubiquity hook works (or a good example I can look at)?
<ari-tczew> please sponsor debdiffs for fakesync [main] bug 512430
<ubottu> Launchpad bug 512430 in geronimo-jpa-3.0-spec "Fake sync geronimo packages (main) from Debian testing (main)" [Undecided,Confirmed] https://launchpad.net/bugs/512430
<mdz> has anyone else seen bug 523176?
<ubottu> Launchpad bug 523176 in grub "update-grub hung during upgrade, blocked reading from stdin" [Undecided,New] https://launchpad.net/bugs/523176
<mdz> happened with kexec-tools
<mdz> ah, /me finds bug 518853
<ubottu> Launchpad bug 518853 in kexec-tools "package kexec-tools 1:2.0.1-1ubuntu1 failed to install/upgrade: subprocess installed post-installation script killed by signal (Interrupt)" [Undecided,Confirmed] https://launchpad.net/bugs/518853
<pitti> Keybuk: thanks for the rsyslog upload
<pitti> Keybuk: however, does that actually check for EPERM, and not drop privs in that case?
<pitti> Keybuk: (otherwise rsyslog would stop working and spin the cpu 100% during upgrades, or when booting an older kernel)
<Keybuk> pitti: we don't support booting an older kernel
<Keybuk> you'll have bigger problems before you even *get* to rsyslog ;-)
<pitti> Keybuk: but we will at least during dist-upgrade?
<pitti> Keybuk: then perhaps we should not restart rsyslog during dist-upgrade then?
<Keybuk> if there's a bug, we can fix that later
<pitti> Keybuk: I booted 2.6.32-10 with that rsyslog configuration, and it just spins the CPU
<Keybuk> pitti: feel free to fix it ;-)
<pitti> yeah, might do after alpha-3
<pitti> anyway, so now the charts should look better
<pitti> Keybuk: devicekit-power is gone now as well, FYI (I uploaded a new indicator-session)
<Keybuk> the dd won't exist for older kernels anyway?
<Keybuk> so the bug is just that it spins rather than not logging kmsg
<pitti> Keybuk: out of interest, do you alraedy know what's up with this setupcon/loadkeys/sh thing? or shall I take a look?
<pitti> Keybuk: we have the dd process in karmic
<Keybuk> pitti: yeah, have a patch I'm about to upload
<Keybuk> pitti: we don't have the dd process if you've dist-upgraded ;)
<pitti> Keybuk: it spins on EPERM, so it will just stop logging anything
<Keybuk> right, the spin on EPERM is clearly a bug
<pitti> Keybuk: why wouldn't we? it's started in karmic?
<Keybuk> if you reboot into an older kernel, it won't be there, etc.
<pitti> right, on lucid's rsyslog
<Keybuk> lucid's rsyslog is the only one that'll spin
<c_korn> can someone please enqueue scilab again ? build just takes a while. see the last comment. it took 6.5h on Debian: https://bugs.launchpad.net/ubuntu/+source/scilab/+bug/511864
<ubottu> Ubuntu bug 511864 in scilab "Sync scilab 5.2.0-7 (universe) from Debian unstable (main)" [Undecided,Incomplete]
<Laibsch> mvo: hello
<Laibsch> @all: hello
<Laibsch> mvo: I'm available for further testing of update-manager if you want
<Laibsch> things are as they were yesterday
<dholbach> rickspencer3, seb128, pitti: simple scan is seriously good stuff!
<dholbach> just tested it :)
<kirkland> cjwatson: hi there ... i have a eucalyptus sru upload for karmic-proposed ... could you accept for karmic-proposed?
<seb128> dholbach, yeah, robert_ancell rocks
<dholbach> now it just needs cropping and I'm all set :)
<sebner> dholbach: thanks for the git-core ACK :)
<Daviey> cjwatson: I want to use dh_apport, but it doesn't seem to be installed..  I'm running 1.12-0ubuntu5, but it doesn't seem to anywhere.  Am i being daft?
<geser> Keybuk: does the most recent udev upload fix the current CHROOTWAIT build problems? "E: Could not perform immediate configuration on 'udev'.Please see man 5 apt.conf under APT::Immediate-Configure for details. (2)"
<jdub> Keybuk: should #513919 (no /dev/null breaks mountall) fix booting without an initrd?
<mathiaz> james_w: hi!
<rickspencer3> dholbach, yes ... robert_ancell is impressive indeed!
<mathiaz> james_w: could you kick an import of the puppet package in lucid?
<seb128> Daviey, do you have dh-apport installed?
<rickspencer3> mvo, thanks! you are the bestest!
<mvo> rickspencer3: :) for XB-Softwarecenter-Appname: in debian/control ?
<Daviey> seb128: I didn't realise it was a seperate binary package, *doh*
<rickspencer3> mvo, I haven't even seen that yet!
<rickspencer3> I was talking about "Featured"
<pitti> dholbach: indeed, I love it
<mvo> rickspencer3: thanks!
<Keybuk> geser: I don't know what caused those chrootwait build problems
<Keybuk> and no, but lamont apparently fixed the chroots
<Keybuk> jdub: yes
<jdub> Keybuk: bonus -- will test on my linode :)
<jdub> Keybuk: woo, thanks for that fix!
<Keybuk> jdub: I'm still not quite sure why it doesn't work of course
<Keybuk> since if you're running 2.6.32 you have devtmpfs auto-mounted on /dev
<Keybuk> and mountall will just reuse that
<Keybuk> so you should never end up with no /dev/null
<jdub> Keybuk: perhaps linode's kernel config?
<Keybuk> jdub: possibly
<Keybuk> smoser: I was meaning to ask you that at some point
<smoser> Keybuk, its non-trivial for me to test now , as our kernels have devtmpfs :)
<jdub> Keybuk: http://www.gnome.org/~jdub/2010/config-2.6.32-linode23.txt
<smoser> i'd need to grab an old kernel, which would be possible.
<Keybuk> smoser: right, I was trying to remember whether it was accurate that you'd forgotten devtmpfs
<Keybuk> jdub: # CONFIG_DEVTMPFS is not set
<Keybuk> jdub: FAIL
<Keybuk> jdub: that kernel config deserves to be smothered with a pillow by some TV presenter nobody's ever heard of
<micahg> are the amd64 lucid chroots broke?
<micahg> nm
<lamont> Keybuk: I went with the "can I reproduce it in a current chroot?  ... well then, trivial fix."  OTOH, do-release-upgrade may get to understand it in full detail
<lamont> so why does my inspiron 1520 just plain not like to boot when the ipod is plugged into the USB port at boot?
<lamont> stupid firmware
<lamont> Keybuk: and I gave back everything in CHROOTWAIT on all 6 architectures
<lamont> but not ppas
<Keybuk> lamont: the question is why did they decide to break *today*?
<Keybuk> there wasn't a new udev or anything
<lamont> Keybuk: NEAT.
<lamont> le sigh
<lamont> I do have the old tarballs, if anyone wants them (for a few days anyway)
<tseliot> slangasek, Keybuk: I think we might want to include these commits in our plymouth package: http://cgit.freedesktop.org/plymouth/commit/?id=8ccb7f17549c3a6e6199420cf90c8c0a2e1af666 and http://cgit.freedesktop.org/plymouth/commit/?id=33b761ebe04e032741966afdd4058b717e96b08a
<geser> Keybuk: from the log I still had open I see a download of udev 151-3 in the upgrade part (and udev 151-3 was uploaded today by Sarvatt)
<Keybuk> geser: ah ok
<geser> Keybuk: therefore I first assumed that your upload of udev 151-4 (4 hours after the upload of -3) was meant to fix this
<Keybuk> tseliot: I saw, I'm doing a plymouth update before alpha 3 anyway
<Keybuk> geser: I don't know the cause
<tseliot> Keybuk: me too, with the new theme and (hopefully) vga16fb support
<slangasek> Keybuk: I think you probably missed my earlier ping regarding bug #518352 - architecture-wise, can you tell me what is *supposed* to be happening in this case?
<ubottu> Launchpad bug 518352 in plymouth "[lucid] if booting without 'splash', gdm starts X on wrong vt" [Medium,New] https://launchpad.net/bugs/518352
<Keybuk> plymouth is supposed to switch to vt7 and use a text plugin that keeps the screen black until passphrases are required, etc.
<Keybuk> this isn't all quite right yet
<slangasek> ok
<Keybuk> we're basically not doing things architecturally the same way as RH
<Keybuk> we always want plymouth running
<Keybuk> and always want plymouth to have an active splash screen
<Keybuk> at some point we just want to switch from that being a very plain text one to being a graphical one
<Keybuk> (when we have the graphics driver)
<Keybuk> either way, we should be always on vt7
<slangasek> oh.  are you writing that code before FF? :)
<Keybuk> no
<Keybuk> it's a bug fix ;)
<slangasek> heh
<Keybuk> it's not so much writing code, but calling the code we have in the right order
<slangasek> so plymouthd would automatically switch vt and blank screen on startup, and then look for a fb on --show-splash?
<Keybuk> slangasek: don't really know yet
<Keybuk> I think that's probably easiest and minimum effort
<slangasek> "don't really know" - that makes me nervous wrt FF, then, given how many problems users are having with plymouth today
<Keybuk> it's nothing to do with FF
<Keybuk> plymouth was in ages ago, now we just fix bugs
<cjwatson> kirkland: could you ask somebody not on holiday? :)
<slangasek> it's the kind of bug fix that is likely to have knock-on effects, and I don't even understand the set of (critical) bugs that are already outstanding
<kirkland> cjwatson: no problem
<Keybuk> cjwatson: only if you actually go *on* holiday and stop reading IRC ;-)
<kirkland> cjwatson: someone got to it already, though
<Keybuk> slangasek: fortunately we have another alpha, and two betas yet
<Keybuk> slangasek: so lots of testing
<cjwatson> Keybuk: if I don't do Debian work when on holiday, I'm not sure when I'm supposed to do it ;-)
<Keybuk> cjwatson: that sounds a lot like a modern Busman's Holiday
<cjwatson> fear not, I have had plenty of non-computer time
<cjwatson> not least due to some kind of bug confining me to bed all day yesterday
<cjwatson> (holidays, eh?)
<Keybuk> a Debian bug?
<davmor2> debiflu
<cjwatson> not unless they've learned how to jump the species barrier
<Keybuk> slangasek: I'm not trying to work around the definition of Feature Freeze, btw.
<Keybuk> I'm not saying plymouth isn't a bit buggy right now, but as a feature (and package) it is in
<Keybuk> it's just a bit buggy
<slangasek> Keybuk: right - it's just buggy to the point that I'm hearing half our own desktop team has removed it from their systems so they can get work done
<Keybuk> that seems both in the letter *and* spirit of ff
<Keybuk> slangasek: sure, but that's the case with anything critical
<Keybuk> or anything run during boot
<Keybuk> my minor bugs always have major impact to some people :p
<Keybuk> unfortunately this means that all my specs and all my bugs end up OMGCRITICALZ!
<Keybuk> which doesn't really help matters at all
<slangasek> well, we can probably expect similar ratios for testers outside the desktop team... so they aren't going to be there to actually test the other fixes to plymouth if they've written plymouth off before that
<slangasek> not that I have a solution for this - the solution would have to involve fixing the bugs which I can't reproduce
<Keybuk> slangasek: so your saying I should only get two months to do all my feature development *and* bug fixing for any given release?
<Keybuk> perhaps a boot feature freeze before UDS?
<slangasek> no, I'm expressing concern about the current state of plymouth
<Keybuk> (the same could be argued for anything the foundations team maintain)
<Keybuk> the state is pretty good
<Keybuk> there's a single bug
<Keybuk> it's just a nice juicy one
<Keybuk> (things end up on the wrong VT or inbetween VTs)
<slangasek> what would "in between VTs" look like, and what's it caused by?  (to try to confirm that's what the flood of bugs I can't make sense of is about)
<Keybuk> in between VTs would look like X drawing graphically on the VT
<Keybuk> while input seems to go to the underlying kernel VC
<Keybuk> and that input potentially crashing the X server
<Keybuk> on the wrong VT would look very similar
<Keybuk> except on the wrong VT, X would be very clearly on tty1
<Keybuk> very clearly graphical
<Keybuk> just that input is also going to getty
<Keybuk> and when getty times out and respawns, it kills X
<Keybuk> in between X looks like it's on VT7, and VT switching appears to confirm
<Keybuk> but the text ends up on tty7 under X despite nothing else being on there
<slangasek> ok
<Keybuk> a VT switch away from X and back to X may often cure the in between problem
<Keybuk> (or crash the X server :p)
<apw> with lpia not being in lucid, do i need transitional packages for those off to something else (kernel wise) or will the installer magic things
<Keybuk> it's all apw's fault really
<Keybuk> since the kernel shouldn't ever let this happen <g>
<slangasek> apw: "neither"?
<pitti> kirkland: I did an SRU round earlier today, including euca
<apw> Keybuk, hey thanks, i like being to blame, makes me feel powerful
<kirkland> pitti: rocking, thank you!
<Keybuk> slangasek: it would be a huge help if you could own any bugs related to things like cryptsetup, asking for input, etc.
<apw> slangasek, so ... the user will find out from the release notes, and i don't need to care about transitions for it ?
<Keybuk> I'll own the "plymouth kills kittens" ones
<Keybuk> since I have all three major hardware here, and should be able to test
<Keybuk> and know the problem very well anyway
<slangasek> Keybuk: I can do that; are there any input bugs that are untriaged / unclaimed right now?
<Keybuk> slangasek: I'm still ~600 bugs behind
<slangasek> (I still feel some responsibility for "kills kittens", since I did upload that reintroduced it)
<slangasek> ok
<Keybuk> I haven't dedicated much effort to my bugs folder (other than clearing the easy ones) since it was before FF :p
<slangasek> apw: must be, I think; there's no way to switch the whole install architecture
<Keybuk> and I had a spec not yet at B/A
<apw> slangasek, thanks ... makes my life pretty easy
<slangasek> apw: so there's no point in having just the kernel try to handle transitions
<apw> slangasek, figured as much, but nice to have it confirmed
<sebner> mighty cjwatson (on holiday) .. mvo told me that you already took care of the dpkg backport?! At least uploading to my PPA doesn't work yet
<ivoks> slangasek: have a minute?
<slangasek> ivoks: sure
<ivoks> slangasek: bug 315770
<ubottu> Launchpad bug 315770 in libtree-dagnode-perl "MIR for libnet-ssleay-perl and dependencies" [Undecided,Won't fix] https://launchpad.net/bugs/315770
<ivoks> slangasek: is there a reason why libio-socket-ssl-perl can't be in main?
<ivoks> i can't tell from bug comment, other than it was discussed on irs
<ivoks> irc
<cjwatson> sebner: I mailed mvo+lamont a diff; it's not within my power to get it deployed
<slangasek> ivoks: no, just the general principle that if we keep pulling everything into main without thinking about if it's really needed, we get everything in main and a burnt-out security team
<cjwatson> sebner: I assume/hope that it's on lamont's to-do list somewhere, although I didn't actually test the diff ...
<slangasek> (and my mirror gets fat, and I don't like that either)
<slangasek> ivoks: why do you need it in main?
<ivoks> slangasek: we are pushing new cluster stack in main
<ivoks> slangasek: one of stonithd features uses perl ssl
<sebner> cjwatson: oh, ok. thanks for the hint! You can attach it to the bug I made if you want too
<ivoks> slangasek: i could check which one exactly and get back to you
<cjwatson> sebner: if it isn't done by the time I get back from holiday, I will; otherwise I've done as much as I intend to do this week
<ivoks> slangasek: so that we can discuss this fruther
<apw> slangasek, can i assume you have a master todo list which includes something about lpia for the release notes or should i file a LP
<bdrung> can a core-dev sponsor the hdparm merge (bug #516249). maybe dholbach?
<ubottu> Launchpad bug 516249 in hdparm "Please merge hdparm 9.27-2 (main) from Debian unstable (main)" [Undecided,New] https://launchpad.net/bugs/516249
<cjwatson> sebner: it wouldn't particularly help anyone to have it attached anyway; lamont is the person who needs it
<dholbach> bdrung: no time, sorry
<slangasek> ivoks: no particular reason to discuss it with me, I'm not on the MIR team
<ivoks> slangasek: ok
<slangasek> apw: please file a bug on the ubuntu-release-notes project
<apw> slangasek, ack
<ivoks> slangasek: i just wanted to check if there was a special reason, thanks
<sebner> cjwatson: aye, thanks again for your work!
<apw> pitti there is something wierd about the two short bars in my burn-down chart (http://people.canonical.com/~pitti/workitems/canonical-kernel-team.html).  Note that the bar is red then green then red.  Its not at all clear that should be possible and i wonder at the veracity of the other bars as a result, are they overlapping more than they should perhaps?
<ScottK> lamont: Still need testing on postfix 2.7?
<lamont> ScottK: well, I have 2.7.0-1 ready to upload once I test it locally... you're welcome to bang on the ppa RC copy modulo known bugs there
<lamont> planning to upload -1 today sometime
<ScottK> lamont: OK.  I'll probably wait then (I'm dug out enough from last week to have a little time, but if it can wait, better)
<lamont> cjwatson: dpkg 1.15.5.6ubuntu1 build-deps xz-utils, which build-deps libtool 2.2 (>> 1.5.26-1ubuntu1 in hardy).  NFW we're backporting libtool.... can haz patch without xz-utils depends?
<Keybuk> cjwatson: I'm going out on a limb here, but have you broken man-db?
<Keybuk> this could explain the recent udev failure
<Keybuk> man-db bombed out of its trigger because the dpkg database was still locked (by, err, dpkg!)
<mpt> tremolux, hi, how's Back+Forward going?
<Keybuk> (it might be misblame, but it was the last thing to write to the console and got an update about the point things started breaking)
<tremolux> mpt: howdy, it's in progress, have a branch at lp:~gary-lasker/software-center/back-forward-nav
<mpt> cool
<mpt> tremolux, do you have Back and Forward GtkActions that the buttons hook into?
<tremolux> mpt: no, just handling the presses directly currently
<mpt> tremolux, I'm asking because I was wondering how easy it would be to add equivalent menu items and keyboard shortcuts
<tremolux> mpt: ah yes, it would be easier if I used GtkActions, indeed
<mpt> tremolux, I guess that can be left until after Feature Freeze, though
<tremolux> mpt: yes, it should be straightforward to convert to use them
<mpt> okie dokie
<tremolux> mpt: right now I have the nav history queues and management classes in place, and currently wiring in the actual navigations themself
<tremolux> themselves
<mpt> neat
<mpt> I'll let you get on with it :-)
<tremolux> mpt: alright, talk later  :)
<lamont> cjwatson: so I built dpkg 1.15.5.6ubuntu1~0.CAT.8.04 without xz-utils, and dep: base-files (>= 4.0.0)
<lamont> that actually was able to build itself
<mpt> tremolux, <https://wiki.ubuntu.com/SoftwareCenter?action=diff&rev2=336&rev1=334> reflects what we discussed last Monday, i.e. that Back/Forward covers "Get Software" and individual software sources therein, but nothing outside that.
<lamont> after installing
<pitti> lamont: should we manually retry amd64 builds which got busted by this udev thing, or will you give them back wholesale?
<seb128> lamont, the amd64 buildds are broken, known issue?
<\sh> oh you know already about the amd64 buildds ;)
<lamont> pitti: mass given back already, this would be the "so fresh chroots only fixed it temporarily" thing
<seb128> pitti, I got a build failure 5 minutes ago, is that supposed to be fixed or not?
<lamont> seb128: as of now, yeah
<pitti> https://edge.launchpad.net/ubuntu/+source/gnome-user-share/2.28.2-4ubuntu2/+build/1513922
<pitti> didn't catch this one then
<tremolux> mpt: would you be terribly upset if the navigation is within the Get Software view only, for first cut?
<pitti> nor totem
<seb128> https://edge.launchpad.net/ubuntu/+source/libubuntuone/0.2.2-0ubuntu1/+build/1514198
<mpt> tremolux, no
<seb128> ^ nor this one
<pitti> lamont: how difficult is it to do another mass give-back?
<tremolux> mpt: as I dug into it, it became much harder to include the sources items in the scope of the nav history
<lamont> mvo: you about?
<Keybuk> pitti: amd64 has *rebusted*
<lamont> pitti: without the fix? it's trivial and pointless
<pitti> ah
<seb128> should we retry builds or not?
<Keybuk> I think we need mvo to understand why APT is refusing to continue
<tremolux> mpt: it's not impossible and it shouldn't be terribly hard to expand the new nav history classes that I've added to do it
 * sebner thinks lamont is quite the workhorse where :)
<tremolux> mpt: but it added an extra level of complexity that I wanted to avoid for first cut
<tremolux> mpt: to me, it seems most useful when navigating the many screens of Get Software
<mpt> yeah
<mpt> ok, I'll revert the changes I just linked to :-)
<tremolux> mpt: oh, sorry
<mpt> np
<tremolux> mpt: don't lose them tho  ;)
<tremolux> mpt: I should have pinged you about it early yesterday when I started to realize this, my bad
<mpt> Reverted but not lost.
<mpt> https://wiki.ubuntu.com/SoftwareCenter?action=diff&rev2=337&rev1=336
<tremolux> mpt: actually, now that I look back at this, I'm a little confused by the (reverted) test case description - the test case includes navigation to the "Installed Software" section, but the section above (I thought) implies just tracking navigation within the "Get Software" screens
<tremolux> mpt: my branch currently shows the nav buttons only when in the "Get Software" section, and tracks navigation within it only
<pitti> Keybuk: do your bootcharting scripts have a hack for the wallpaper cache?
<Keybuk> pitti: no
<pitti> Keybuk: I just uploaded didrock's ubiquity hook to copy it from the live system, so if you have one, you can drop it
<Keybuk> where possible, the boot chart scripts don't have any hacks
<pitti> ah, good
<Keybuk> ie. the point is to test the actual instal
<mpt> tremolux, sorry, that was an error that I corrected at the same time as the changes, and then I reverted the correction. Re-fixed it now.
<pitti> Keybuk: right, just wanted to make sure
<Keybuk> the post-install scripts are all about adding things like the broadcom driver, bootchart, etc.
<Keybuk> lamont: the only loop I can find in that tree is the old udev -> initramfs-tools -> udev one
<Keybuk> which has been there since the DAWN OF TIME
<Keybuk> and that's only a Depends not a Pre-Depends
<mathiaz> Keybuk: pitti: I'm still confused about the MIR - should a wiki page be written or not?
<mathiaz> kees: ^^
<Keybuk> mathiaz: "the MIR" ?
<Keybuk> lamont: http://launchpadlibrarian.net/39315255/buildlog_ubuntu-lucid-i386.upstart_0.6.5-2_CHROOTWAIT.txt.gz
<mathiaz> Keybuk: sorry - completion to fast
<Keybuk> i386 busted itself again
<pitti> mathiaz: you don't need to any more, but if you want to, that's fine
<mathiaz> pitti: the first point in the notes sections refers to the report - https://wiki.ubuntu.com/MainInclusionProcess
<tremolux> mpt: ah great, thanks!
<lamont> mvo: bzr pull lp:~lamont/launchpad-buildd/chroot-scripts/; chroot-scripts/make-chroot.sh -d lucid might be faster if you have a quick archive
<lamont> s/pull/branch/
<pitti> mathiaz: right, which describes exactly that it's not required any more :)
<mathiaz> pitti: from someone *writting* a MIR request I still think it makes sense to write a wiki page
<pitti> mathiaz: that was discussed on u-devel@ a while ago; as I said, if you think it's easier for you to write the wiki page, go ahead
<mathiaz> pitti: ok - thanks
<mvo> lamont: thanks, I have it now and can reporduce
<mvo> reproduce even
<Keybuk> mvo: the only loop I can find in the dep tree is the udev -> initramfs-tools -> udev one
<Keybuk> but that's been there like, forever
<mvo> Keybuk: thanks, I have not looked in details yet, just reproduced :)
<pitti> crimsun, TheMuso`: JFYI, I committed a small change to pulseaudio bzr (so please pull before committing/uploading)
<Keybuk> mvo: anyway, feel free to upload any fixes you need ;-)
 * sebner is wondering why sparc now has chroot problems too
<mvo> Keybuk: thanks, it seems to be the new mountall dependency on udev
<mvo> well, that is causing it, next bit is to figure out how to fix it
<Keybuk> mvo: why would that cause the problem
<Keybuk> wouldn't this mean that *anything* depending on udev can cause the issue?
<sladen> Keybuk: there's is a Pre-Depends loop with  openoffice.org-filter-binfilter -> openoffice.org-core  which breaks stuff
<sladen> Keybuk: mvo: bug #516727 if you can work out how to fix that to allow smooth upgrades
<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,Triaged] https://launchpad.net/bugs/516727
<mvo> Keybuk: sort of, the problem is that something essential pulled udev in now and apt like to do immediate configuration on this stuff. to minimize the risk of breakage. but this is one of the side-effects, that is sometimes is too eager and falls over
<Keybuk> mvo: ah
<Keybuk> feel free to drop that then
<Keybuk> though mountall won't work without udev installed
<Keybuk> (or configured, in fact)
<superm1> kirkland, I think today's your archive admin day.. would you mind kicking mythtv out of binary new so that the other myth* packages can build again against it?
<kirkland> superm1: done
<mvo> Keybuk: thanks, I see what I can do (either by fiddling dependencies or hit apt with a hammer)
<superm1> kirkland, thanks (and sorry for your frontend that you just upgraded :))
<kirkland> superm1: :-P
<kirkland> superm1: my wife is ready for mythtv normalcy again
<mdeslaur> pitti: I've just uploaded a "security" symptom to apport-symptoms. Do you think we could get a new version uploaded before FF?
<cjwatson> lamont: I think ditching the xz-utils build-dep would be OK
<cjwatson> anyone have a build log for that man-db thing Keybuk was talking about?  I did sync a new upstream version of man-db, but I didn't change the trigger logic in any meaningful way AFAIK
<kees> mvo: /win 13
<kees> mvo: er, ping, about update-manager
<kees> mvo: I'd like to add a small script to it, since it ships the bulk of the update-motd scripts.
<mvo> kees: sure
<mvo> kees: /win 12
<ari-tczew> please upload 4 debdiffs for fake sync bug 512430 thanks
<mvo> kees: feel free to commit directly if its trivial
<ubottu> Launchpad bug 512430 in geronimo-jpa-3.0-spec "Fake sync geronimo packages (main) from Debian testing (main)" [Undecided,Confirmed] https://launchpad.net/bugs/512430
<mvo> kees: otherwise, just create a branch and I will merge
<kees> mvo: okay, cool
<juliank> mvo: Don't forget the python-apt upload, if you haven't done it already.
<mvo> juliank: I'm working on it, I think its fully backward compatible now, but I want to do some further tests
<juliank> mvo: Except for apt_pkg.Version which is a class now, it should be fully compatible. But I have not seen anyone complaining about apt_pkg.Version since it changed last summer.
<ari-tczew> mvo: do you will fix problem with udev/pbuilder today before FF?
<mvo> ari-tczew: the immediate-configure problem that the buidds have? or is that a different one?
<juliank> cjwatson: You have been selected for receiving the first python-apt API transition bug, for germinate. It should come tommorow, with a patch.
<mvo> juliank: right, its pretty good, when testing with the release upgrader I had some issues, it uses a lot of the p-apt code
<mvo> I think they are fixed now
<juliank> mvo: I tested gnome-app-install and software-center, and they worked (except on Debian kFreeBSD, but this is not relevant here)
<ari-tczew> mvo: pbuilder @ E: Could not perform immediate configuration on 'udev'.Please see man 5 apt.conf under APT::Immediate-Configure for details. (2)
<mvo> ari-tczew: yeah, I just uploaded a new util-linux that hopefully fixes it
<mvo> juliank: ok, my next candidate is gdebi, but I'm pretty confident that this will work
<juliank> mvo: Should I open bugs for the python-apt transition in Ubuntu as well and link them to the ones in the Debian BTS?
<juliank> mvo: I believe I already used gdebi with the new python-apt.
<mvo> (phone)
<nixternal> how can I get lp:debian/experimental/koffice updated with what is in debian experimental? really don't want to have to do this big arse merge manually
<leonardr> DktrKranz: i mentioned this to slangasek earlier, but the new launchpadlib is available for you to package at your convenience
<leonardr> i'll be staying on irc in case you have questions
<ari-tczew> please sponsor this merge before FF !! bug 523375 thanks!
<ubottu> Launchpad bug 523375 in commons-pool "Merge commons-pool 1.5.4-1 (main) from Debian testing (main)" [Undecided,Confirmed] https://launchpad.net/bugs/523375
<lamont> mvo: were you serious in that SMS? and do I need to handhold it?
<tormod> pitti, can e.g. you please bless the sync request in bug 520163 ?
<ubottu> Launchpad bug 520163 in linux-wlan-ng "please sync linux-wlan-ng 0.2.9+dfsg-4 from Debian unstable (main)" [Undecided,New] https://launchpad.net/bugs/520163
<lamont> mvo: would "apt-get dist-upgrade -o Apt::Immediate-Configure=false" in an apt.conf.d/foo file in the tarball be sufficient to get past the current pain?
<ari-tczew> main sponsors needed!!!
 * micahg just saw a blog post about that ari-tczew :)
<ari-tczew> micahg, I don't understand :>
<directhex> seb128, moonlight 2.1 packaging is mostly done, but is blocking on the mozilla team providing something resembling a xulrunner-dev 1.9.2
 * \sh just had a look on mom...and mom is again pregnant with twins
<micahg> directhex: I think it's done from my end, I think asac said something in the timeframe of 'soon' for an upload :)
<micahg> ari-tczew: I read something recently about the lack of main-sponsors
<directhex> micahg, yeah, that's what i heard a week or two ago regarding a list of Depends: for plugins. featurefreeze is *tomorrow*
<mvo> lamont: that should be enough (the tarball thing)
<lamont> ta
<mvo> lamont: if you build util-linux by hand and install it in the archive it would work as well
<lamont> mvo: except for the "install it in the archive" part
<lamont> there is no abi for that
<elmo> lamont: I think he means the chroot archive
<lamont> ah, but still requires building it
<ari-tczew> [ new upstream @ merge ] Bug 523375 please sponsor it ;-) thanks!
<ubottu> Launchpad bug 523375 in commons-pool "Merge commons-pool 1.5.4-1 (main) from Debian testing (main)" [Undecided,Confirmed] https://launchpad.net/bugs/523375
<tseliot> slangasek: shall I retry my builds? I got a "chroot problem": http://launchpadlibrarian.net/39316569/buildlog_ubuntu-lucid-i386.nvidia-graphics-drivers_195.36.03-0ubuntu1_CHROOTWAIT.txt.gz
<ivoks> everybody gets that :/
<tseliot> slangasek, lamont: ^^ this was on palmer and crested
<tseliot> oh
<lamont> tseliot: it's everywhere, and why the whole farm is on manual atm
<DktrKranz> slangasek: I'm about to upload python-launchpadlib_1.5.5-1, dinstall is running so it will take ~1,5h to be accepted, I hope it's not a problem for you.
<tseliot> lamont: ok, so (for me) it's just a matter of waiting until all is fixed, right?
<lamont> yes
<tseliot> lamont: ok, thanks. I'll retrigger the build tomorrow, I guess
<lamont> tseliot: if it's not in a ppa, it'll get requeued once the fix gets published (next publisher run, I expect)
<tseliot> lamont: no, it's not in a ppa, it's in lucid. Great news, thanks again :-)
<tormod> ari-tczew, try contacting directly a dev who has uploaded that package earlier
<lamont> so, um, when does the publisher usually run?
<lamont> there.  that ends the "ZOMG in CHROOTWAIT" queries. :-p
<slangasek> DktrKranz: sounds good to me, thanks :)
<ari-tczew> where is ttx :(
<slangasek> not in front of tty?
<lamont> dear world.  build farm back online, chewing on your NOMNOMNOM lucid builds
<ivoks> thanks
<geser> \o/
 * ogra hugs lamont 
<sebner> lamont is tehh FIXX0R!
<lamont> sebner: mvo is teh fix0r... I just get to drive sometimes
 * mvo hugs lamont
<lamont> mvo: so... it's been that way in that package for sometime, was it the whole switch to upstart that exposes it?  and is apt going to change so that's not totally fatal the next time around? or ??
<lamont> because I don't think I can drop that dep until upstart is there, right?
<lamont> (speaking of debian)
<\sh> world thanks lamont and mvo :)
<mvo> it got triggered because mountall grew a new dep on udev, and yes, it really should handle the situation more gracefully
<mvo> what its doing is not fatal
<sebner> lamont: btw, already got time to look at the dpkg fix from cjwatson?
<mvo> if the immediate-configure fails
<lamont> sebner: that's waiting for testing on dogfood prior to lobbing it into production
<lamont> fwiw, we get to ignore the FFE mess for alien-arena
<lamont> I got it blessed
<sebner> lamont: heh, it's a little bit annoying but no real problem filing and getting it approved so I don't really mind
<lamont> sebner: ok.  if you want to go the FFE route and upload, works for me. - I was planning on just signing it and stuffing it
<kirkland> lamont: are the buildd's hosed?
<kirkland> lamont: http://launchpadlibrarian.net/39320067/buildlog_ubuntu-lucid-i386.ecryptfs-utils_83-0ubuntu1_CHROOTWAIT.txt.gz
<sebner> lamont: *IF* you can sort it out before FF it's even better but don't feel any pressure. You don't *have to* do it right now if you have other stuff to do
<lamont> kirkland: that should have been given back
<\sh> kirkland: you are too late ;)
<micahg> lamont: you didn't say the chroot problem was fixed, did you?
<lamont> micahg: let me guess, it's back?
<micahg> https://launchpad.net/~mozillateam/+archive/ffox35/+build/1514312/+files/buildlog_ubuntu-lucid-i386.totem_2.29.4-0ubuntu3~ffox36~lucid1_CHROOTWAIT.txt.gz
<lamont> kirkland: you'll note that 0ubuntu2 is current.
 * ScottK thinks we have ~20 minutes until the publisher run finishes ....
<kirkland> lamont: 0ubuntu2 of what?
<lamont> ecryptfs-utils
<lamont> you know, the log you just threw at me from ages ago when the lucid chroot tarball was h0rked.
<kirkland> lamont:  82-0ubuntu2
<lamont> meh
<kirkland> lamont: i uploaded 83-0ubuntu1
<kirkland> lamont: hmm, that log file is just a few minutes old
<lamont> dear mvo.  hating you. kthx
<mvo> *weeh*
<lamont> mvo: so... you comfortable with us just running with the hack for all builds for a little while you find the real answer?
<lamont> deadlines and all that
<lamont> but you understand the hack at least 3 orders of magnitude better than me
<mvo> lamont: sure - what was it you did earlier? build util-linux manually?
<mvo> it will do no harm
<lamont> hacked tarball, uploaded, manual the world, punch util-linux to the top, let it build, restore old buildd
<lamont> oh. wait.
<lamont> let me guess... the installed util-linux needs to be the fixed one, right?
<lamont> mvo: ^^
<mvo> lamont: once util-linux (the new version) makes it into the archive all should be good again, is the new util-linux build and published?
<lamont> built and published
<lamont> OTOH, just building tarballs to make sure
<mvo> :(
<mvo> its not on archive.u.c (at least I can not see it on my system) yet
<primes2h> cr3: Hello, are you around?
<lamont> mvo: so... published != published.
 * lamont goes to scrape the internal mirror to be sure
<primes2h> cr3: Did you have a look at the translation issue ? bug #514401
<ubottu> Launchpad bug 514401 in ubuntu-translations "Several strings appear in english although translated" [High,Confirmed] https://launchpad.net/bugs/514401
<mvo> heh :) that makes it harder for me to test, it did work in my test env
<primes2h> cr3: It would be nice to have it fixed in time for Lucid.
<cr3> primes2h: thanks for the reminder, but the current trunk of the project has security issues which need to be resolved before I can push the new version
<nixternal> anyone know if the current daily installer is working? been broken the past couple of days
<cr3> primes2h: I will have that ready in time for lucid, even though I might need a ffe. I just hope this will be in time for translations to kick in
<kirkland> lamont: will builds auto retry, or do i need to push?
<lamont> autoretry for !ppa
<lamont> (already given back)
<primes2h> cr3: Ok, I hope so. Tell me if you need help for anything. :-)
<primes2h> cr3: Thanks.
<mvo> juliank: sorry, no upload today, the gdebi-gtk InstallProgressAdapter is not working, I need to debug that first (it appears something with updateInterface/waitChild is not yet ok)
<DktrKranz> mvo: need more testing hands on gdebi side?
<lamont> sigh.  that first NOMNOMNOM announcement would be the packages missing the publisher by 4 minutes.
<lamont> so given that it runs in 2 min, and takes 20+ to get past lucid, I think it's breaktime
<mvo> DktrKranz: gdebi is ok, I'm testing the new python-apt, its doing a good job of compatiblity, but its not 100% there yet
<DktrKranz> ah, ok. Don't hesitate to ask if you need help ;)
<mvo> :)
<mvo> thanks!
<lamont> right.  ;40 is too long, mvo I let them go, will verify things once the load settles out again
<DktrKranz> slangasek: python-launchpadlib accepted, all yours ;)
<slangasek> DktrKranz: cheers!
<lamont> ok.  NOW lucid is NOMNOM
<mvo> lamont: for me pbuilder update is happy, that used to fail with the pre-conf error - are the buildd chroots happy too?
<ScottK> mvo: Stuff is building
<lamont> yeah - ubuntu2 finally showed
<seb128> mvo, lamont: good work!
<mvo> nice
<lifeless> is anyone interested in ubuntu-bug accepting program names? e.g. ubuntu-bug apt-cache
<micahg> lifeless: already ubuntu-bug `which apt-cache` should work
<lifeless> it doesn't, but its not intuitive
<lifeless> ubuntu-bug has the users PATH, so it could check this itself.
<micahg> lifeless: bug 447751
<ubottu> Launchpad bug 447751 in apport "ubuntu-bug should fall back to using its argument as a command name ("ubuntu-bug ubuntu-bug" should work)" [Undecided,Confirmed] https://launchpad.net/bugs/447751
<micahg> thanks lamont, mvo for the builders :)
<lifeless> micahg: thanks
<Riddell> mysql still not fixed?  can't it just gain an epoch and be quickly sorted?
<directhex> dpkg-deb: building package `moonlight-plugin-mozilla' in `../moonlight-plugin-mozilla_2.1-0ubuntu1~pre~ppa1_amd64.deb'.
<unimatrix> what's going to happen in Lucid if ATI doesn't come up with a working fglrx driver for the new X server ?
<seb128> directhex, oh, nice moonlight
<directhex> which is preferable, whilst waiting for xulrunner-dev 1.9.2 - ship a package built against 1.9.1 with known functionality missing in ff3.6, or sit on the package & wait?
<directhex> seb128, i'm about to upload to ppa & test
<seb128> directhex, I would say check with #ubuntu-mozilla for xulrunner update
<seb128> if that's coming rsn wait
<seb128> otherwise build with 1.9.1 for now
<crimsun> pitti: noted (& pulled), thanks.
<tormod> slangasek, can you please ack this sync? bug 520163
<ubottu> Launchpad bug 520163 in linux-wlan-ng "please sync linux-wlan-ng 0.2.9+dfsg-4 from Debian unstable (main)" [Undecided,New] https://launchpad.net/bugs/520163
<leonardr> DktrKranz, have you done any work on the new launchpadlib release?
<leonardr> (ie packaging it)
<ScottK> leonardr: It was uploaded to Debian earlier today
<leonardr> ScottK, great, thank you
 * sebner looks for a core-dev sponsoring an easy merge
<sebner> before FF ;)
<sebner> https://bugs.edge.launchpad.net/ubuntu/+source/jinja2/+bug/523540
<ubottu> Ubuntu bug 523540 in jinja2 "Merge jinja2 2.3-1 from Debian(Unstable)" [Wishlist,Confirmed]
#ubuntu-devel 2010-02-18
 * stgraber still has a new ltsp, ltspfs, ldm and pastebinit to upload before FF (doing intensive testing at the moment as I'll both release and package these at the same time)
<stgraber> (probably the most tested version of LTSP ever ;))
<sebner> stgraber: as long as the topic isn't changed there is no FF :P
<stgraber> sebner: can we lock it somehow ? ;)
<sebner> stgraber: become op and kick everyone else :P
<stgraber> I'm pretty sure it's against some part of the CoC :)
<sebner> stgraber: it runs under the name "netsplit" ;D
<highvoltage> rofl
<stgraber> sebner: ok, so I need to bribe some freenode admin ? :)
<highvoltage> stgraber: what still needs to happen with pastebinit?
<stgraber> highvoltage: cyphermox is doing pre-release testing, then I'll release 1.0 and push it to Ubuntu
<sebner> stgraber: no one needs to know *psssssst*
<highvoltage> ah
<stgraber> has been a long long time since I last released and I really want the new version in Lucid (as it brings a flexible way of adding pastebin servers and a few others long awaited features)
<stgraber> I've been running it for a few months now without any issue and I guess some others too but I want to make sure everything works before releasing
<cyphermox> stgraber, i swear people feel this weird need to change the way they design pastebin sites :)
 * slangasek creates pastebin.csszengarden.com
<stgraber> cyphermox: yeah ... that sucks :) especially the ones adding some javascript "human check" ... I had to drop quite a few pastebin websites because of that
<stgraber> slangasek: as long as you use a supported pastebin engine, it's fine, it'll work ;)
<persia> stgraber: Be *really, really* fast on that release, as we're technically in FeatureFreeze (although I haven't seen the mail yet)
<stgraber> persia: yeah, for pastebinit, I'm ready to tag, just waiting on some additional testing. For LTSP, I'm waiting on LP to build PPA packages faster ;)
<stgraber> though I guess I can already go ahead and tag ldm and ltsp, as only ltspfs is having a small issue worth fixing before releasing
<persia> stgraber: I understand.  I've been CPU-limited for the past 12 hours for the same reasons :)
<crimsun> sebner: uploaded
 * sebner hugs crimsun 
<sebner> gn8 folks
 * Laibsch curses his computer (and karmic) for constantly overheating and shutting down at inopportune times since karmic
<elmo> there's an opportune time to overheat and shut down?
<Laibsch> yes
<Laibsch> just before switching off ;-)
<superm1> would something in universe Recommends'ing something in Multiverse cause it to FTBFS, or would that only happen from something in universe Depends'ing on something in Multiverse?
<lifeless> is there something we should do with merge proposals to ensure main sponsors see them ?
<Laibsch> lifeless: are they subscribed?
<lifeless> Laibsch: are you saying thats what we should do? Note that I'm not talking about bugs.
<lifeless> so the bug policies don't apply.
<Laibsch> of course
<Laibsch> ??
<Laibsch> Do you have a patch?
<Laibsch> something ready to apply?
<lifeless> A merge proposal.
<ScottK> superm1: Run time recommends can't cause FTBFS, but that would require the package to move to Multiverse.
<Laibsch> lifeless: do the merge, open a ticket, subscribe sponsors ;-)
<lifeless> Laibsch: I don't think you understand what I'm talking about.
<Laibsch> maybe not
<Laibsch> you want somebody else to do some work
<Laibsch> correct?
<lifeless> a merge proposal is a proposal to merge two branches in launchpad
<Laibsch> Oh
<lifeless> it *is* the record that the work needs to be done.
<lifeless> its not a bug.
<Laibsch> I thought you were talking about merge/sync kind of merge
<Laibsch> for a package
<lifeless> no, because for those we have procedures.
<Laibsch> well, yes
<lifeless> so I ask again, to the floor. "is there something we should do with merge proposals to ensure main sponsors see them ?
<lifeless> "
<Laibsch> I stay away from bazaar as much as possible, so I have no experience with that and can't help you
<ajmitch> it's not even obvious where merge proposals are listed for ubuntu, from what I can see
<ajmitch> I can find a few through ~ubuntu-main-sponsors
<lifeless> ajmitch: most will be on ~ubuntu-branches at this point
<lifeless> ajmitch: there is discussion on this on the udd list
<ajmitch> right, found that thread
<lifeless> [join the list ;P]
 * ajmitch is on the list
<ajmitch> but the discussion was more than 2 weeks ago :)
<lifeless> paged out already?
<ajmitch> yep
<smoser> anyone here have a some spare knowledge to share on how a seed works ?
<smoser> the reason I ask is that the uec builds have 'uec^' as a seed.
<smoser> the install process does 'apt-get install uec^'
<smoser> at this point in karmic, that is resolving to 2 different packages providing a kernel
<smoser> linux-image-2.6.31-14-virtual and linux-image-2.6.31-19-virtual
<smoser> i'm not sure when it started, but I think it might be related to a kernel being added to -updates
<smoser> hmm... digging a bit http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.karmic/uec lists the older package
<smoser> anyone happen to know how that is updated?
<superm1> kirkland now that the other two builds have caught up, could you by chance release myththemes and mythplugins so tonight's media will pick em all up?  (or some other archive admin seeing this)
 * lamont wants to stab libtool
<lamont> -version-info 61:4:1 \
<lamont> ...-Wl,-soname -Wl,libisc.so.60 -o .libs/libisc.so.60.1.4
<StevenK> superm1: I'll look at that for you in a sec
<superm1> thanks
<StevenK> superm1: myth{themes,plugins} accepted.
<superm1> awesome, thanks!
<nigelb> I'm trying to apply an upstream patch to gnome-media, which is maintained in bzr.  I applied the patch, but I have no idea how to go about building the package when its maintained in bzr.  Is there some place I can see a guide for this or could someone guide me through it?
<jdub> whoa
<jdub> this rsyslog bug is awesome
<jdub> https://bugs.launchpad.net/bugs/523610
<ubottu> Ubuntu bug 523610 in linux-ec2 "20100218 EC2 image (ami-0512fe6c): Cannot read proc file system: 1 - Operation not permitted." [Undecided,New]
<jdub> (happening for me with the linode kernel)
<pitti> Good morning
<pitti> mdeslaur: yes, I don't think anyone will object against adding apport symptoms post-FF
<pitti> mdeslaur: (FF is already in place, btw; but I'll do an upload anyway)
<micahg> pitti: do you think an apport symptom for flash would be good?
<pitti> micahg: what would it do more than just filing a bug against flashplugin-installer?
<pitti> micahg: well, it could check whether you have the proprietary plugin, and not file a bug at all then
<superm1> pitti, well good news on the gvfs/gdu pool creation crashes I was seeing... at least with the latest version it looks like it's a simple fix (bug 523634)
<ubottu> Launchpad bug 523634 in gnome-disk-utility "libgdu0 should Depends on udisks" [Undecided,New] https://launchpad.net/bugs/523634
<micahg> pitti: well, there are multiple flash plugins
<pitti> micahg: right, the symptom could figure out which one you are using, and return the correct package
<micahg> pitti: right, or ask which browser you are using if there are multiple
<micahg> and file it against the browser
<pitti> superm1: ah, that would be it
<pitti> superm1: I'm glad that the original race was fixed
<micahg> pitti: if you're ok with idea, I already filed a bug and can try to create the symptom at some point
<pitti> micahg: sure, sounds great
<pitti> superm1: thanks, committed
<micahg> pitti: how late in the cycle can we get symptoms in?
<pitti> micahg: with my release team hat on, at least until beta-2
<micahg> pitti: k, that's what I'll set it for then, thanks
<pitti> this helps us to improve quality, and won't break the actual system
<pitti> but of course we'll get lots of feedback/bugs for beta-1 and beta-2
<micahg> cool
<pitti> so the really useful symptoms should be in before that ideally
<pitti> so that we can actually make use of them :)
<micahg> pitti: I just don't know if I'll get to it before then
<micahg> there's still a lot of mozilla stuff to be done before beta 1
<DktrKranz> leonardr: yup. packaged, uploaded to Debian and then synced. thanks!
<dholbach> good morning
<jdub> aha
<jdub> hey dholbach
<dholbach> heya jdub
<jdub> #523610 <- rsyslog missing the dd trick now it's an upstart job
<dholbach> james_w: can lp:~bmillemathias/ubuntu/lucid/bluez/main and its merge proposal be marked as merged?
<pitti> zul, soren: can you guys please seed ec2-init, so that the transitional package is in main? (cleaner upgrades)
<soren> pitti: Sure.
<pitti> kees: I removed the obsolete devmapper source, FYI
<soren> pitti: I don't want to put ec2-init in the uec seed, since that is a task and I don't want to install a transitional package as part of a task. It also seems odd to put in on the dvd (again, because it's a transitional package), but the top of supported suggests that everything should go on the dvd unless it's much too large to fit there.
<pitti> soren: no no, just "supported" is enough
<pitti> no need to install that on any medium
<pitti> it just needs to be in main for a clean upgrade from karmic
<soren> Yeah, that's what I thought.
<soren> Oddly, the dvd seed has a "Transitional packages" section.
<pitti> soren: ah, perhaps if you use the DVD as a package source for dist-upgrading?
 * soren ponders
<soren> pitti: Yeah, that would make sense, I suppose.
<soren> I'll put a note in the seed explaining that use case.
<soren> dvd seed it is.
<soren> pitti: Done. Thanks for catching this.
<pitti> thanks soren
<dholbach> can somebody please sync bzr from sid? it fixes at least one ugly merge bug
<pitti> doing
 * dholbach hugs pitti
 * bryceh waves
<soren> I see rhythmbox-ubuntuone-music-store was added to the seeds, but no such package exists. Is that intentional?
<bryceh> pitti, I got the X freeze apport hook working today :-)
<pitti> hey bryceh
<pitti> bryceh: ooh! you were able to produce a freeze? great!
<bryceh> pitti, and got a *single* .crash file generated in /var/crash
<soren> Oh, I see it's in the NEW queue. Never mind.
<slangasek> RAOF: your most recent libdrm upload doesn't seem to be marked uploaded in the git repository?
<RAOF> slangasek: That would probably be because I didn't upload it; bryceh did.  I can't upload libdrm, not being in ~core-dev :)
<slangasek> RAOF: well, you have commit access to the repo at least, could you commit that?
<RAOF> Yep.
<slangasek> (I don't have commit access to the repo; request pending)
<bryceh> erf
<bryceh> we really need to decide git vs. bzr for maintaining all this stuff
<RAOF> I'd really, really like bzr.  If only everyone else used it, too :(
<highvoltage> I always assumed that core-dev's rights include those of motu, is my assumption wrong?
<bryceh> RAOF, ditto
<highvoltage> if I understand mako's comment on http://revu.ubuntuwire.com/details.py?upid=7876 correctly, he's not able to contribute to revu even though he's a core-dev
<RAOF> If someone could spend a month or so making bzr-colocated work, I could just drop git entirely.
<mtx_init> does ubuntu use dkms?
<bryceh> mtx_init, yes
<mtx_init> thx
<slangasek> bryceh: the source package has an ubuntu version number, points at a git repo, and the git repo has an ubuntu branch, so I assumed that was official?
<slangasek> if you're telling me I can ignore this in favor of lp:ubuntu/libdrm, I'll do a little dance :)
<bryceh> slangasek, no your original assumption is correct
<slangasek> drat
<slangasek> :-)
<bryceh> we started using git for maintaining the packaging before a lot of james_w's bzr stuff became available
<mtx_init> whats the best way to get into kernel level development.  Ive takes OS classes before and written system calls and stuff.  Ive added ACL's to a FS and created my own message passing ipc.  But the whole thing is incredibly intimidating.  any idea on a good point to start.
<SwedeMike> mtx_init: http://www.linuxhq.com/lkprogram.html
<pitti> bryceh: it seems that -nouveau is still in universe; can you please add it to -video-all, so that we can promote it?
<mtx_init> SwedeMike: thanks
<bryceh> pitti, before I do that, we've been waiting on lbm being updated
<RAOF> Are we getting an lbm-nouveau metapackage that x-x-v-nouveau can depend on?
<pitti> bryceh: oh, the current linux-backports-modules-nouveau-2.6.32-13-generic is not recent enough?
<pitti> RAOF: that would be wrong
<pitti> we certainly don't want to pull in lbm by default
<pitti> we need to get along with the nouveau in the default kernel
<bryceh> pitti, actually we do
<pitti> no, we don't
<pitti> seriously
<bryceh> pitti, no, the nouveau in the default kernel is not going to be good enough
<pitti> lbm ships a lot of stuff that is prone to break machines
<slangasek> pitti: no, linux-backports-modules-nouveau-2.6.32-13-generic, not "lbm" as a whole
<bryceh> pitti, we need to pull the lbm nouveau binary module (and include it on the cd)
<pitti> ah
<pitti> but why can't we just put that one into the main kernel then?
<bryceh> pitti, its complicated
<pitti> slangasek: ah, ok
<RAOF> bryceh: There *isn't* any nouveau in the default kernel :)
<bryceh> pitti, drm is hard to pull in a per-driver fashion
<pitti> ok, so it's _only_ shipped in lbm
<pitti> ok, that sounds better
<pitti> bryceh: so, current linux-backports-modules-nouveau-2.6.32-13-generic isn't recent eonugh yet?
<bryceh> pitti, there is a (short) email thread on kernel-team@ and ubuntu-x@ you may want to look at
<DktrKranz> pitti: thanks for syncing restfulclient! I thought it was in sync already, but I was wrong :)
<pitti> ok, thanks; so this is blocked on pulling a new version by the kernel team?
<RAOF> l-b-m-nouveau should be new enough; what we really need is a linux-backports-modules-nouveau metapackage that the DDX can depend on and gets updated with the kernel ABI.
 * pitti updates work items then
<pitti> thanks for the heads-up
<RAOF> That reminds me! I'll file a bug against initramfs-tools to add nouveau to the framebuffer hook.
<pitti> bryceh: ok, I updated https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-lucid-xorg-driver-selection-for-nvidia-hardware
<directhex> hm.
<directhex> i want to make an ubuntu1 upload of monodevelop, with moonlight support enabled. should i wait for the mozilla team to get their ff3.6 stuff (including moonlight) ready? it's a binary-only dep on a separate monodevelop-moonlight binary package (i.e. doesn't affect compilation).
<slangasek> RAOF: I would argue that the lbm package should provide its own hook to take care of itself
<slangasek> and presumably the in-kernel one lands in kernel/drivers/gpu like the others?
<RAOF> It might end up in staging/
<RAOF> But it will eventually end up in kernel/drivers/gpu like the others, yes.
<tjaalton> bryceh: git of course ;)
<bryceh> tjaalton: I'm thinking bzr actually
<tjaalton> of course
<bryceh> tjaalton: there's pros and cons each way, but I favor bazaar
<RAOF> The problem with shipping it in lbm is that the various ABI versions should be parallel installable.  I guess the linux-backports-modules-nouveau package could ship it.
<tjaalton> but I'm also co-maintaining it in debian, so using two toolsets to maintain stuff is suboptimal fo me
<tjaalton> for
<tjaalton> but your call
<slangasek> no problem, just convince the Debian comaintainers to use bzr ;)
<bryceh> tjaalton, yes I recognize that issue
<tjaalton> slangasek: and upstream too?
<slangasek> nah, just use bzr-git for that
<tjaalton> well, that's unlikely to happen
<slangasek> using bzr-git is?
<tjaalton> that
<RAOF> It's really pretty good, although it does suffer from bzr not having any way to refer to colocated branches.
<tjaalton> I understand that it's harder for people to touch this stuff if it's in git.d.o, but is that any different from any other team? I don't think it's a good practise for random core-devs to directly touch and upload packages "owned" by some team
<tjaalton> without discussion
<slangasek> no, it's no different than any other team, and I regularly complain at other teams too when I can't commit to their repos as a core-dev
<tjaalton> heh, well I don't count you as a "random" core-dev ;)
<slangasek> :(
<tjaalton> being the release manager and all :)
<slangasek> I don't think the release manager should be special in that regard; all core-devs should be trusted w/ commit access, and to know when to discuss before uploading
<tjaalton> in theory yes
<tjaalton> no manpage for bzr-git
<dholbach> tjaalton: bzr help <...>?
 * hypera1r is more interested in git-bzr
<dholbach> hypera1r: bzr git-import <...>?
<dholbach> (from bzr-git package)
<hypera1r> dholbach: i don't like bzr.
<hypera1r> dholbach: to put bluntly.
<dholbach> ah, I misunderstood you then
<hypera1r> ;-)
<tjaalton> yeah, it's a one-way journey, because there's no way to push
<tjaalton> so for that there would need to be two sets of the trees, one for git and one for bzr-git
<RAOF> It's not one-way; you can bzr dpush git+ssh://whatever
 * sebner waves in the round
<hypera1r> o/
<tjaalton> RAOF: ok, that's what the launchpad page claimed though
 * slangasek succeeds in pushing to libdrm on alioth
<slangasek> (the hard way though, using git)
<dholbach> slangasek: does it give you that great slightly masochistic sense of achievement? ;-)
<slangasek> dholbach: I carefully monitor my git use to ensure I don't become too comfortable with it :)
<RAOF> slangasek: Didn't I successfully push that?
<slangasek> RAOF: you successfully pushed *your* commit, I was pushing /mine/ :)
<RAOF> tjaalton: Yeah.  It technically doesn't âpushâ because it needs to do some rewriting of the local objects to keep the remote and local branch in sync.
<tjaalton> jelmer: the description on https://edge.launchpad.net/bzr-git is misleading if push has been working sinec 0.3.2
<jelmer> tjaalton, push still doesn't work
<tjaalton> jelmer, RAOF: ok, I give up :)
<jelmer> tjaalton: you can use the "bzr dpush" command, but that's not the same thing as push
<RAOF> jelmer: My description of the difference above is roughly correct, right?
<slangasek> oh, dpush wasn't a typo, heh
<jelmer> RAOF: Basically, yeah
<tjaalton> what's the equivalent of 'git show $hash'?
<pitti> tjaalton: bzr diff -c revno
<jelmer> tjaalton, "bzr log -p -r X"
<tjaalton> eww, that's hard :)
<RAOF> âbzr alias show=log -p -r -Xâ
<tjaalton> but it accepts the hash as the revno?
<RAOF> Let me check...
<jelmer> tjaalton: s/X/$hash/
<tjaalton> jelmer: ah, gotcha
<tjaalton> -r git:$hash
<jelmer> the git: bit is optional in newer versions of bzr
<tjaalton> so it detects it? ok
<pitti> meh, that's the second time that X.org freezes and goes to 100% CPU a couple of minutes after login
<pitti> bryceh: were there any X.org/intel updates yesterday?
<tjaalton> only libdrm
<sebner> pitti: better than me. I just tryed out of the gdm/plymouth whatever bug is fixed but I guess no. Gdm appears, I move my mouse and it evidently crashes because mouse and keyboard don't work anymore :( --hardreset
<pitti> I already disabled plymouht
<pitti> this now manages to break every boot
<sebner> oh
<sebner> plymouth++ then
<ttx> slangasek: should the rc-sysinit/network race bug be reopened, following up on keybuk's https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/461725/comments/15 ?
<ubottu> Ubuntu bug 461725 in upstart "rc-sysinit job might start before loopback is up" [Medium,Fix released]
<slangasek> cjwatson: hmmm, does the by-id stuff you were doing affect what will get written to /etc/crypttab by the installer?
<sebner> pitti: how to disable it? apt-get remove?
<tjaalton> hmm we already had libdrm 2.4.17 before the new merge
<pitti> sebner: boot without splash; that won't really disable it, but disable the graphical splash
<tjaalton> so no intel changes there
<pitti> which is what seems to break X
<pitti> tjaalton: currently trawling through dpkg.log to see what was new
<sebner> pitti: aye, thanks :)
<pitti> there are no kernel related messages in dmesg when it happens, and strace Xorg is silent - it's just spinning
<slangasek> ttx: no, that bug is fixed; the regression has really only been confirmed on systems with a broken network config
<ttx> slangasek: ok, just checking :)
<sebner> pitti: ehm, stupid question .. what happened to menu.lst ^_^
<pitti> sebner: menu.list is grub 1, which became obsolete in karmic
<pitti> tjaalton: right, I didn't even get a new libdrm
<slangasek> oh, would that it were actually obsolete :)
<sebner> pitti: oh right, I haven't haXX0red anything in lucid yet. so what's the new thing?
<pitti> tjaalton: so it must be between new libc6, new udev, or me dropping "splash" from kernel comand line
<tjaalton> pitti: I'll try that on mine
<pitti> tjaalton: I'll gdb X the next time it happens; thanks so far!
<slangasek> pitti: dropping splash from the kernel commandline is a near-guaranteed way to make X hang in lucid :P
<pitti> hmm
<slangasek> pitti: bug #518352
<ubottu> Launchpad bug 518352 in plymouth "[lucid] if booting without 'splash', gdm starts X on wrong vt" [Medium,New] https://launchpad.net/bugs/518352
<tjaalton> hah
<slangasek> if you don't use 'splash', then 'plymouth --show-splash' doesn't change VT
<pitti> well, X is on vt7 now
<slangasek> is that where it was at boot time, or did you restart it?
<slangasek> it's only the *first* X server after boot that winds up on the wrong VT, because gdm does - if (plymouth_is_running) { get_cur_vt_for_X_args(); kill_plymouth(); }
<pitti> I don't think I restarted it
<jussi01> !grub2 | sebner
<ubottu> sebner: GRUB2 is the default Ubuntu boot manager in Karmic. For more information and troubleshooting on GRUB2 please refer to https://wiki.ubuntu.com/Grub2
<sebner> jussi01: thx but this seem to cause even more breakage *muahahha*
<jussi01> *g*
<mpt> mvo, hi, how is ratings+reviews? Are you blocked on anything?
<cjwatson> slangasek: not to my knowledge - I didn't think crypttab had much to do with grub?
<slangasek> cjwatson: I wouldn't think so, no :)
<sebner> StevenK: regarding openal-soft, LP does support syncing .orig.bz2 now afaik?!
<slangasek> cjwatson: just an odd bug report that came in, with someone having listed their source device as /dev/disk/by-id/fwibble in /etc/crypttab
<directhex> asac, is debian/patches/mono-arm-thumb2-ftbfs.dpatch forwarded to upstream?
<cjwatson> sebner: not properly
<cjwatson> sebner: it supports the first sync.  thereafter, it is believed that subsequent syncs with the same .orig.tar.bz2 will fall over
<cjwatson> slangasek: IIRC the installer even generates crypttab before grub-installer runs
<slangasek> ok
<mvo> mpt: not blocked as such, just drowned in other stuff, I plan to work on the new approach with ubuntuone today, lets see how well that goes. the old code that use launchpad will have to be replaced in parts
<mpt> mvo, ok, best of luck :-)
<pitti> is there an existing bug report for the plymouth failure? perhaps with some hints how to debug this? I now got 7 failures in a row
<mvo> thanks :)
<slangasek> pitti: hmm? other than the one I pointed to above about booting w/o splash?
<pitti> slangasek: still the same one from the sprint
<pitti> i. e. X starts up with a mouse cursor over VT
<pitti> ctrl-alt-f1 > switches to VT
<slangasek> pitti: yes; are you booting without splash?
<pitti> crtl-alt-f7 -> back to X, but press enter -> freeze
<pitti> slangasek: no, that's with splash
<slangasek> oh, no, that sounds like the in-between-VTs case
<pitti> Keybuk said taht he can't reproduce, so I'm happy to collect some data
<pitti> but I'm afraid I don't know where to start
<pitti> it happens on both of my machines (dell mini ssd and latitude)
<slangasek> pitti: for starters, make sure you have libplymouth2 0.8.0~-10ubuntu1 installed and file a bug with apport, so we at least have a record of /proc/cmdline and /proc/fb
<pitti> ah, bug 516412
<ubottu> Launchpad bug 516412 in plymouth "Pressing <Enter> causes X to freeze" [High,Fix released] https://launchpad.net/bugs/516412
<slangasek> noooo, not that one :-P
<pitti> that's the freeze part
<pitti> once I switch to vt1 and back to 7
<pitti> slangasek: ok, so there's no existing bug with suggestions/explanations what to look out for?
<pitti> ok, I'll file a new one then
<pitti> slangasek: (I have that version)
<slangasek> nope - we have an explanation of *what* that behavior means, but no model for *why* it happens
<pitti> could it be related to fsck?
<slangasek> Keybuk might be able to give some debugging advice, but I can't
<pitti> since obviously I need to powercycle this machine every time now
<pitti> slangasek: ok, thanks
<slangasek> "obviously"?
<slangasek> Alt+SysRq+K doesn't fix it?
<pitti> No SysRQ on the mini :/
<slangasek> snerk
<slangasek> plug in a USB keyboard? :)
 * pitti will boot in rescue mode, make sure that partitions are okay
<pitti> oh, I can login/reboot from VT1
<pitti> (didn't help, though)
<slangasek> anyway, relation to fsck is only distant AFAIK, in the manner of races
<mvo> mpt: one thing we should discuss (not necessarily now) - apparently the gtk patch take make almost-fixed height mode fast is going going to be upstream and we will have a hard time getting it in as a distro patch. nzmm implemented a alternative layout that does not grow/shrink so we can have fixed_height mode
<mpt> mvo, "going going" -> "not going"?
<mvo> mpt: I would like you to look at it (I or he can do screenshots) and comment. without a patched gtk the user experience is going to be really bad
<mvo> mpt: not going to
<mvo> mpt: I'm willing to work more on the patch, but I have the feeling its a lost cause
<pitti> slangasek: right, once I put back cups, it works again
<pitti> slangasek: I think this machine is naturally avert to booting in 10 s; the closer you get, the more it acts up :)
<slangasek> pitti: bwuh? cups?
<slangasek> haha
<pitti> slangasek: (just for testing)
<mpt> mvo, so first, why will it not be upstream?
 * pitti calls that "Scott's law"
 * pitti -> supermarket
<mpt> mvo, or if you'd prefer to discuss this later, let me know
<mvo> mpt: I had no official reply yet in the bugreport, but the unoffical is that it makes the fixed_height mode case slower and that its a hack (both is true). the slowness should be really small
<slangasek> pitti: perhaps annotating the gdm upstart job to run fuser -v /dev/tty7 before starting?
<mvo> but its a hack and it does things that fixed_height is supposed to not support (namely making rows grow/shink)
<slangasek> (stabbing the dark)
<mpt> mvo, and why would it be hard as an Ubuntu patch? Is it because we'd be carrying it forever?
<mvo> mpt: we would have to carry it for the full LTS time and carrying a patch that got rejected upstream will make bugreports against gtk by us handled less favorable (because it might be a side effect of our patch(es)). seb128 is the gatekeeper for this
<mvo> (upstream reports)
<mpt> mvo, so maybe the question for upstream is, *how* in GTK should we achieve what we want to achieve (rows changing size but being fast with long lists)
<mvo> mpt: correct
<mvo> and I believe at this point the answer is "you can't" - at least not without massive amounts of gtk events that infere with the webkit rendering (and other stuff)
<mvo> but I'm happy to change my opinion if someone comes up with a good way of achieving this
<seb128> mvo, did you get any comment on this bug?
<mvo> I do think we shuld have a backup plan ready
<mpt> mvo, how does Banshee do it? Do they not use fixed-height mode?
<mpt> Or are they using a completely custom list control?
<seb128> banshee has quite some custom widgets
<mvo> mpt: someone told me they embedded a complete copy of the treeview
<mvo> but I have not verifed this
<mpt> How difficult would that be?
<mvo> well, it would be a very big hammer
<mvo> the question is not "is it possible" - the question is "is it sensible" (or "how much are we going to hack")
<mvo> alternatively: "growing row design" > pain-to-make-it-happen
<mpt> Right, that's why I was asking specifically about how difficult it would be
<mvo> not easy, but possible
<mpt> ok
<mpt> What does nzmm's layout look like?
<mvo> http://people.canonical.com/~mvo/tmp/Screenshot-Ubuntu%20Software%20Center.png
<mvo> mpt: ---^
<mpt> that looks quite odd
<mpt> I suppose it would look a bit less odd if the stars and the buttons swapped places
<seb128> crimsun, hi
<seb128> crimsun, have you seen bug #523716?
<ubottu> Launchpad bug 523716 in pulseaudio "pulseaudio version defined as UNKNOWN" [High,Confirmed] https://launchpad.net/bugs/523716
<crimsun> seb128: no, but I'll fix it
<seb128> crimsun, thanks!
<mpt> mvo, my main concern with that is if/when someone implements add-on handling for 3.0, which adds a "Choose Add-Onsâ¦" button next to the "Install" button, so we really really do need the buttons on a separate line for them to have enough room, so we fix the variable-height issue somehow then instead of fixing it now, users will have had to go through three different row layouts in three successive USC versions.
<crimsun> I'm currently working on alsa-plugins, so it will be a few minutes
<seb128> crimsun, it's blocking things I want to land today and dx weekly updates so fixing it today would be appreciate if you can ;-)
<seb128> crimsun, excellent, thank you
<mvo> mpt: agreed, I like the visual design of the expanding thing better, we should still have a backup plan
<mpt> mvo, ok, so in order of my personal preference: ;-) 1. Get the patch accepted upstream. 2. Copy and tweak the treeview code like Banshee does. 3. Use nzmm's layout but with the stars and buttons swapped around.
<mvo> mpt: ok
<zul> morning
 * slangasek waves
<slangasek> zul: so the bugs that were blocking samba conversion to upstart are now all fixed; is it still warranted to do the actual upstart conversion now that we're post-FF?
<zul> slangasek: in the long run I dont think it will hurt
<slangasek> zul: "I don't think it will hurt" isn't a FFe justification...
<zul> slangasek: i think there will be the same issue with network manager if we remove your fix for it
<slangasek> sorry, which issue?
<zul> the one where you did the SRU for,,,sorry Im still trying to wake up
<slangasek> well, I wouldn't remove the fix without adding the upstart jobs
<slangasek> but this is going to need a FFe now, so I want to be sure the server team cares about this for lucid
<zul> i know, i think we do lemme ask around a bit more
<slangasek> ok
<mdeslaur> pitti: thanks! (re: apport-symptoms)
<pitti> mdeslaur: security.py> nice FAQ!
<asac> directhex: nope. need to write a proper configure check rather than ifdef __thumb__
<pitti> slangasek: right, as expected, fuser says "plymouthd"
<slangasek> pitti: ok; that alone isn't buggy
<slangasek> gdm takes care of detaching it
<sebner> cjwatson: ah I see, I thought that is fixed alredy. nvm then
<crimsun> seb128: for pulse, 0ubuntu7 in the NEW queue is rejectable; 0ubuntu8 has already built for powerpc, amd64, i386 and is just awaiting approval
<seb128> crimsun, ok thanks, look at that now
<crimsun> mterry: thanks much for the jack approval!
<mterry> crimsun, np, sorry it took me so long
<pitti> slangasek: ok, filed as bug 523788
<pitti> I'll ask Keybuk once he's around
<ubottu> Launchpad bug 523788 in plymouth "Only see X mouse cursor on VT during boot" [Undecided,New] https://launchpad.net/bugs/523788
<\sh> hum...sun-java6 got missing for lucid? or did kees followup with his plan to remove it completly?
<c_korn> \sh: https://launchpad.net/ubuntu/lucid/+source/sun-java6/6-16-1
<\sh> c_korn: DELETED: Lucid pocket Release in component multiverse and section devel
<kklimonda> weren't there plans to move it to the -partner repository?
<\sh> kklimonda: well, if that is, a) i didn't catch it and b) someone could update all configs for upgrades from < lucid to >= lucid ;)
<\sh> but right now, it would make my production machines very unhappy with an evtl. removed package of sun-java6
<pitti> it was removed from lucid, and is meant to be moved to partner
<BenC> Good morning ubuntuers
<Tm_T> moin
<pitti> hey BenC, how are you?
<zul> hey BenC
<BenC> pitti: hey, not bad, how about yourself?
<pitti> BenC: I'm great, thanks; again in boot speed fighting mood :)
<BenC> pitti: fight the good fight :)
<Laibsch> dholbach: Has the door closed for bug 420918 due to FF?  I thought that was not the case, but persia suggested yesterday my POV may be mistaken.
<ubottu> Launchpad bug 420918 in isdnutils "please update libcapi" [Wishlist,Incomplete] https://launchpad.net/bugs/420918
<Laibsch> sistpoty|work, bdrung, ScottK: ^^
<smoser> Hi all, last night I asked about seeds (http://irclogs.ubuntu.com/2010/02/18/%23ubuntu-devel.html).  The 'uec' seed for karmic is pulling in kernel images from the release, even though there are newer ones in updates.
<smoser> is that expected behavior ? ie, if I do 'apt-get install uec^' I get 2 kernel images, the current one as in updates and the original release version.
<smoser> vmbuilder does this in the uec image builds, so my built images get 2 kernels (which i could work around, but seems senseless)
<superm1> slangasek, hmmf. according to the build log http://people.canonical.com/~ubuntu-archive/cd-build-logs/mythbuntu/lucid/daily-live-20100218.log this build was successful, yet it didnt show up on cdimage.
<superm1> doh just refreshed, there is it
<superm1> i guess the time the pieces that cron job is running got changed
<sistpoty|work> Laibsch: sorry, at work atm, need to take a deeper look this evening
<slangasek> zul: libmysqlclient16 sorted soyuz-side; barring further complications, there should be no need for the version-munging patch
<zul> slangasek: sweet!
<Laibsch> sistpoty|work: thank you for your response.  To save and the others some time, let me summarize the essence of the question.
<Laibsch> My understanding is/ that feature is about new package and new upstream versions.
<Laibsch> bug 420918 is not about a new upstream version and thus I thought I was safe.
<ubottu> Launchpad bug 420918 in isdnutils "please update libcapi" [Wishlist,Incomplete] https://launchpad.net/bugs/420918
<sistpoty|work> Laibsch: I thought you'd have incorporated parts of upstream cvs (or new version) as part of the diff?
<Laibsch> But it replaces a significant chunk of the code and I think it also introduces new functionality.  I believe it's 100% backward compatible, but would need to reconfirm with buzz.  I'm quite sure on this point, though.  The new code is a refactoring plus alpha.
<Laibsch> The question is now if the replacing and the alpha mean it falls under FF and needs an FFe
<Laibsch> plus all the other work that bitrot has necessitated now
<slangasek> Laibsch: certainly not; the feature freeze is about /features/, new upstream versions and new packages are just examples that we single out in all the announcements because it's not necessarily obvious that those are covered by the freeze
 * Laibsch is quite dissatisfied with the process of contributing to Ubuntu as an outsider
<sistpoty|work> Laibsch: new functionality is a feature, so I guess a FFe is in place (besides the code change is quite huge, from what I've quickly looked at, need to dig that further when at home though)
<slangasek> but other new features are also covered by the freeze, for sure
<Laibsch> alright
<Laibsch> Let me briefly say that this makes me furious, then (I guess I'm to blame for the misunderstanding).  Contributing to Ubuntu as an outsider with generally IMHO good patches failed in 3 out of three cases over a period that spanned two releases (since apparently we missed the boat again).  I think that is an indication that something is not going well.
<Laibsch> gjots2, isdnutils and ffgtk
<kirkland> superm1: missed your message last night
<kirkland> superm1: did someone else get them?
<superm1> kirkland, yeah they were gotten
<kirkland> superm1: cool
<pitti> kirkland: http://qa.ubuntu.com/reports/bug-fixing/lucid-fixes-report.html -> you are number #3, keep it up!
<pitti> oh, no fair
<pitti> I fix all the udev keymap bugs upstream, and scott gets the credit for it :)
<davmor2> pitti: :D
<kirkland> pitti: \o/
<pitti> kirkland: I just declared war on seb128
<kirkland> pitti: :-D
<kirkland> pitti: did the algorithm change recently?  I had a 106 a few days ago
<pitti> I don't know
<kirkland> pitti: meh
<pitti> just looked at it the first time during lucid
<kirkland> pitti: i noticed it during the sprint
<tsmithe> hi- with the latest upload of alsa-plugins, is it just me, or have libasound_module_*_pulse.so disappeared? i'm on amd64, and i've purged/reinstalled/deleted the package cache, and the disappearance persists...
<kirkland> pitti: there's one for each of the last few releases, just mangle the url
<pitti> kirkland: I know; last time I looked at the karmic one
<pitti> kirkland: I meant I looked at the lucid one the first time
<kklimonda> tsmithe: going to be fixed with the next release
<tsmithe> kklimonda, righty. what's the cause? it seems odd that just enabling jack would destroy pulse...
<kklimonda> tsmithe: I don't know details - you could ask crimsun probably
<genii> Is the python-lazr.restfulclient 0.9.11-1 or so in yet?
<tsmithe> kklimonda, i imagine he's away right now, but thanks for the info
<tsmithe> (i'm sure i had something else to ask him, but it's slipped my mind)
<sebner> crimsun: hrm, sound is gone :(
<apw> anyone else seeing this nice new missing library?
<apw> ALSA lib conf.c:3272:(snd_config_hooks_call) Cannot open shared library libasound_module_conf_pulse.so
<sebner> apw: yeah, me too
<apw> how does one find out where a file _used_ to be coming from
<sebner> apw: 1:0.9.22~0.9.21+stable-queue-32-g8478-0ubuntu6 might have br0ken it?!
 * apw cries ... pulse
<tsmithe> sebner, apw; kklimonda said "going to be fixed with the next release", but he didn't know the exact cause. for some reason the plug-in is absent from alsa-plugins..
<tsmithe> (although it's still in ia32-libs)
<apw> hrm
<jdstrand> apw: that file came from libasound2-plugins
<kklimonda> jdstrand: but it has been build against broken libpulse-dev and because of that it's missing pulse plugin
<sebner> jdstrand: it's gone ^^
<sebner> kklimonda: can you specify "next release"
<jdstrand> apw: I just filed bug #523889 on that, and then bug #523902 for the no sound. they may be dupes...
<ubottu> Launchpad bug 523889 in alsa-plugins "libasound_module_conf_pulse.so no longer available (dup-of: 523716)" [Undecided,New] https://launchpad.net/bugs/523889
<ubottu> Launchpad bug 523716 in pulseaudio "pulseaudio version defined as UNKNOWN, which breaks everything with build-dep on libpulse-dev" [High,Fix released] https://launchpad.net/bugs/523716
<ubottu> Launchpad bug 523902 in alsa-driver "no sound after recent Lucid upgrade" [Undecided,New] https://launchpad.net/bugs/523902
<apw> so we'd need to downgrade pulse and alsa-plugins to get sound back
<jdstrand> kklimonda: I see. is there a bug report about the busted libpulse-dev?
<kklimonda> seb128: I can't - it should have been fixed with the last libasound-plugins upload but I can see that it still doesn't build pulse plugin
<kklimonda> jdstrand: I know that crimsum has been working on that before he got to work
<seb128> kklimonda, wrong completion?
<jdstrand> crimsun: ^ halp with no sound :)
<sebner> seb128: I'm sorry for my nick :P
<kklimonda> seb128: right :)
<kklimonda> sebner: ^
<jdstrand> crimsun: actually, I haven't tried you new ubuntu5 yet (still have ubuntu4)-- I'll wait and see how that works
<ogra> according to the buildlog the module is there
<ogra> -rw-r--r-- root/root      5432 2010-02-18 15:07 ./usr/lib/alsa-lib/libasound_module_conf_pulse.so
<ogra> its listed in the deb content on http://launchpadlibrarian.net/39366585/buildlog_ubuntu-lucid-i386.alsa-plugins_1.0.22-0ubuntu5_FULLYBUILT.txt.gz
<sebner> ogra: yeah, I think -0ubuntu6 b0rked it
<ccheney> mvo: bug 516727, can you look at the package info, iirc you thought it was a bug in apt when i mentioned it to you at the sprint, but i may have overlooked something in the information myself
<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,Triaged] https://launchpad.net/bugs/516727
<ogra> seb128, 0ubuntu6 ?
<ogra> err sebner
<lamont> lool: valgrind - trivial workaround to the still-missing armel build would be a no-change upload of -0ubuntu3
<sebner> ogra: oh, sorry, I thought of pulse
<ogra> no, i'm looking at alsa-plugins :)
<sebner> ogra: ohh, I think it's just not mirrored yet
<ogra> ah
<mvo> ccheney: I have a look later, it appears we have this bug every cycle
<mvo> s/bug/problem/
<sebner> ogra: I installed it from LP but it doesn't fix the issue for me :(
<ogra> you still see "Cannot open shared library libasound_module_conf_pulse.so" ?
<jdstrand> sebner: do you have ubuntu8 of pulseaudio too?
<lamont> lool: OTOH, I apparently can cause it to happen without the upload, so don't bother unless you already have a need
<sebner> jdstrand: yep
<sebner> ogra: aye
<jdstrand> I'm still wating on the download...
<sebner> ogra: it's not present in /usr/lib/alsa though
<sebner> ogra: *not = ''
<ogra> should be /usr/lib/alsa-lib/libasound_module_conf_pulse.so
<sebner> ogra: it *is* now there, yes
<ccheney> mvo: ok
<sebner> ogra: nah, not conf
<sebner> ogra: libasound_module_ctl_pulse.so	
<sebner> I have
<ogra> hmm, the buildlog says its there, weird
<sebner> oh and conf too
 * sebner is confused, sorry
<sebner> ogra: it's all there but sound is still not working with the same error message
<lool> lamont: Ok; thanks
<lool> lamont: So I understand you're working on scheduling it and it will start shortly
<kklimonda> sebner: what error? I get no error messages but still no sound :/
<lamont> lool: yes
<lamont> watching the -n output of this run,  then I'll do it with anger. <-- lool
<lool> lamont: great thanks again!
<sebner> kklimonda: <ogra> you still see "Cannot open shared library libasound_module_conf_pulse.so" ?
<sebner> kklimonda: try aplay /usr/share/sounds/alsa/Noise.wav in your terminal
<kklimonda> sebner: I've tried already - I get no error but neither do I hear anything..
<sebner> hmm
<sebner> me gets
<sebner> ALSA lib conf.c:3272:(snd_config_hooks_call) Cannot open shared library libasound_module_conf_pulse.so
<sebner> ALSA lib pcm.c:2211:(snd_pcm_open_noupdate) Unknown PCM default
<sebner> aplay: main:608: audio open error: No such file or directory
<apw> ok it seems that this sound issue is meant to be fixed in libasound2-plugins 1.0.22-0ubuntu5 ... which though built is not yet available for install
<sebner> apw: at least not for me :(
<kklimonda> apw: I've installed it from launchpad already.. :/
<sebner> kklimonda: ^
<apw> kklimonda, i see so even if it were it won't help you think
<lamont> lool: though for the documentation thing, it's "wait until  ~2PM london next day, and then do your upload, or if there is a reason to _NOT_ upload, poke ubuntu-osa to deal with it"
<apw> well i guess we'll give it time till thats available in the archive and then bitch about it
<jdstrand> apw, kklimonda, sebner: doesn't work for me here either. I now have ubuntu8 pulse and ubuntu5 libasound2-plugins
<apw> bah, then you should reply on the bug that dtchen is closing you all against
<jdstrand> ubuntu5 ships the libasound_module_conf_pulse.so
<apw> and say you ahve that version and that ... nope its no better
<apw> oh ... hrm... but no sound?
<apw> ie. aplay -l works?
<jdstrand> apw: correct no sound, but still the error that it can't find it
<apw> oh hrm
<jdstrand> apw, sebner, kklimonda: crimsun responded in my bug 523902
<ubottu> Launchpad bug 523902 in alsa-driver "no sound after recent Lucid upgrade" [Undecided,Incomplete] https://launchpad.net/bugs/523902
<jdstrand> I'll be responding there-- you may want to as well
<lamont> jdstrand: once I figure out why bind9 9.7.0 is hat{ing,ed by} libtool, do we want to get that into lucid?
<lamont> the DNSSEC stuff in 9.7 is actually usable, from what I'm hearing - supporting 9.6 for 5.5 more years would suck, IMO
<jdstrand> lamont: is that how debian is able to start migrating to dnssec?
<lamont> you can migrate today, it's just that the tools to manage stuff are all roll-your-own, or crufty.  9.7 actually has tools for doing a bunch of it pretty handily, at least from the mail that's been flying by
<sebner> jdstrand: I confirme
<sebner> d
<lamont> on my todo list for march is to roll one of my zones to dnssec
<lamont> under 9.7
<lool> lamont: So the procedure is to reupload after the next London 2pm; ok, thanks!
<jdstrand> lamont: I think it sounds like a great idea to get 9.7 in-- sounds like it'll need an FFe though
<mdeslaur> lamont: personally, I would try and get it in
<lamont> who's literate enough in libtool and auto* to tell me why the 9.7 build process decides to use the wrong soname, where it didn't in 9.7rcN
<lamont> lool: unless there's a reason to not do an upload (like you added OO.o to armel, and love your life enough to not upload it just because there's no build record for it)
<lamont> mdeslaur, jdstrand: thanks - I'll push on it.  it would have landed last night if not for (1) yesterday's chroot cluster, and (2) the pesky build error
<jdstrand> lamont: sounds great, thanks :)
<mdeslaur> thanks lamont
<lamont> so I'll include that in my handwavy FFe :-)
<lool> lamont: Rough text https://wiki.ubuntu.com/PackagesArchSpecific
<lamont> lool: fwiw, the script is now finally processing lucid, on -n still
<lool> lamont: Sorry, what's "-n"?
<lool> no do?
<lamont> lool: the "don't really do this because I want to see what you're gonna do" flag
<lamont> so we're nearly 50% of the way to you having build records
<lool> Ok
<lamont> timewise
<lool> lamont: Thanks, what matters is that it's in progress; I was fearing Pas would be completely broken and take a while to fix
<lamont> buildd admins won't be able to do it.  requires shell access on the buildd master, so ubuntu osa or gsa - but how to articulate that at the moment is a good question
<lamont> "buildd admins" and having them know that it needs $PRIVS may be sufficient
<lool> Ack, I picked buildd admin as a neutral term which is likely to stay correct over time (at least the buildd admin will figure it out  ;-)
<Q-FUNK> https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/523716/comments/18
<ubottu> Ubuntu bug 523716 in pulseaudio "pulseaudio version defined as UNKNOWN, which breaks everything with build-dep on libpulse-dev" [High,Fix released]
<Q-FUNK> hi! would anyone have time to do what dtchen asks?
<mathiaz> slangasek: hi - is there a way in upstart to say that a job should be run once another job (a task) has finished running?
<mathiaz> slangasek: it seems that start on started other-job starts the job too soon
<mathiaz> smoser: ^^
<apw> jdstrand, although that update didn't make my sound work it did fix the aplay -l, looking at alsamixer all my output channels were muted, i have two Headphone and one Speaker channel ... unmuting and raising those fixed it
<apw> kklimonda, ^^
 * sebner agrees with apw
<apw> so something else is wrong with alsa handling in something something .. pulse ?
<apw> i wonder how i get that message to dtchen
<jdstrand> apw: not here: http://paste.ubuntu.com/379221/
<apw> crimsun, ^^
<jdstrand> that is even after a reboot
<apw> jdstrand, definatly sorted that out for me
<apw> didi you get the whole pulse update too?
<jdstrand> I thought so, maybe not. I can try again
<jdstrand> I have ubuntu8 pulseaudio and ubuntu5 libasound2-plugins
 * jdstrand tries again
<jdstrand> all my pulseaudio* and libpulse* files are the same version
<jdstrand> crimsun mentioned in 523716 that alsa-lib needs a change
<kklimonda> apw: yeah - that fixed sound issue for me but I don't get any missing library errors..
<apw> jdstrand, odder and odder.  mine works now, and syncs ok now
<apw> i did only just get the updates with the turning of the hour that i needed
<jdstrand> I'm totally up to date with the exception of libdrm* stuff
<smoser> mathiaz, i tried running with debug on , to see what events we could work off of, but apparently debug output of upstart does not apply to 'task' items.
<smoser> at least I see no occurense of 'cloud' in the output, but several jobs named 'cloud' obviously run
<Q-FUNK> apw: crimsun is not anywhere close to his development workstation, so he's askign someone else to apply the fix and upload.
<mathiaz> smoser: right - should the cloud-apt-update-upgrade job specifically emit an upstart event?
<mathiaz> smoser: or may be the cloud-config-puppet should start on stopped cloud-apt-update-upgrade?
<smoser> i was hoping it was not necessary
<smoser> i'm testing now if 'stopped' seems to work
<mathiaz> smoser: right
<mathiaz> smoser: IIRC once a task has run it's in stopped status
<sebner> jdstrand: apw kklimonda I have sound again but the volume is only changeable with alsamixer (Speakers)
<apw> yeah my volume control icon has three sliders on the bar, only one of which moves
<apw> and none of which change the volume
<sebner> heh
<jdstrand> alsamixer doesn't work here-- I think I'll wait until I am sure I have everything
<apw> jdstrand, if aplay -l still errors you don't  have everything me thnks
<jdstrand> zika has a similar issue in 523716
<jdstrand> apw, sebner, kklimonda: actually a number of people do as in 523716
<jdstrand> I can try crimsun's recommendation for alsa-lib and if it works I can upload
<sebner> jdstrand: please :)
<sebner> wondering if this will fix the volume issue
<smoser> mathiaz, thats definitely true, i just didn't know if you could run on its stopped
<smoser> mathiaz, it appears that works
<smoser> http://paste.ubuntu.com/379230/
<smoser> 2 jobs there, 'pre-job' and 'post-job'.  pre-job takes 10 seconds to run, post-job runs on its stopped
<smoser> and it seems to function
<mathiaz> smoser: great - I'll give a try with the cloud-config-puppet job then
<lool> lamont: wee, it's needs build now!
<mathiaz> smoser: I'll update the bug
<smoser> mathiaz, ok. i'll put a patch into cloud-init that is going to get uploaded soon. for the other 'time not defined' bug
<mathiaz> smoser: great - thanks
<sebner> jdstrand: are you building it locally or will you upload it to your PPA?
<Laibsch> mvo: If you want to get more information about that hardy-lucid update problem, I'm online
<jdstrand> sebner: I am building it locally. if it works I will upload
<sebner> jdstrand: yeah, just in case it doesn't work for you I could also test it /here and I'd not have to build it ^^
<jdstrand> sebner: if it doesn't work, I'll put it in a ppa. I am avoiding that cause I can build much faster here
<sebner> jdstrand: sure :)
<Q-FUNK> actualy, the solution is more involved than this.  first rebuild alsa-lib, then rebuild libasound-plugins with it
<smoser> mathiaz, if you'd like, to review and sponsor, a fix is available
<Q-FUNK> jdstrand: ^^
<jdstrand> Q-FUNK: I can do that. libasound2-plugins is then a no change rebuild?
<smoser> slangasek, cjwatson sorry to ping by name, but i know one or both of you have answers and haven't got responses in previous queries.
<smoser> Hi all, last night I asked about seeds (http://irclogs.ubuntu.com/2010/02/18/%23ubuntu-devel.html).  The 'uec' seed for karmic is pulling in kernel images from the release, even though there are newer ones in updates.
<smoser> anyone happen to know how that is updated?
<persia> smoser: Have you tried playing with germinate locally?
<smoser> persia, no.
<persia> smoser: That's often a useful first step to understanding why various packages are pulled into various tasks or images.
<smoser> but it would seem to me that either a.) we have ot change the seed because its working as designed, or b.) we have to re-generate its output to deal with -updates
<smoser> persia, i think its just old data
<smoser> is that not a resonable assumption?
<kees> kirkland: does this read okay for the VT-hardware feature?  https://wiki.ubuntu.com/Security/CPUFeatures
<persia> smoser: I don't happen to know offhand, but I think you would be able to use germinate to validate the assumption.
<james_w> smoser: where are the seeds actually read from by the installer? do you know?
<kirkland> kees: sure, reads well
<smoser> james_w, that i don't know. they're not explicitly read. 'apt-get install uec^'
<Q-FUNK> jdstrand: as far as I can tell, it just needs a new alsa-lib with the above change to build against.
<persia> That would be getting data from tasksel-data
<kees> kirkland: cool, thanks
<kirkland> kees: one more thing that might be useful ...
<kirkland> kees: dmesg | grep -qs "kvm: disabled by bios"
<kees> kirkland: oh, neat.  how does the kernel detect that?
<kirkland> kees: dunno, but i've seen it on enough systems that I added that to /usr/bin/kvm-ok
<james_w> smoser: ah yeah.
<james_w> smoser: I think it just needs the metapackage updating then
<smoser> the metapackage meaning the seed being re-generated, right?
<kees> kirkland: does svm|vmx show up in flags even if it's disabled in the bios?
<james_w> smoser: that will grab the newer dependency
<james_w> smoser: the seed is the input, a metapackage is an output
<smoser> right.
<james_w> smoser: germinate reads the seeds and expands the list of packages with dependencies and the like
<james_w> it will then stuff them in to Depends/Recommends of the metapackage
<james_w> which is then uploaded to the archive
<james_w> where it will be seen by apt and used when installing the uec task
<kirkland> kees: yes, it does
<smoser> so how do i request that get done ? and it seems that this will have to be done each time a kernel with new ABI is added to -updates
<kirkland> kees: which aggravates people, because it looks like they have kvm, but it just won't work
<james_w> smoser: it certainly seems like it
<kees> kirkland: ah-ha.  this is much easier to detect than NX, then.  cool.
<smoser> i would expect that this is not a new issue though
<james_w> smoser: most of the other seeds don't depend on a kernel, so it's probably not part of the process
<smoser> ok, then assuming i've found out what needs to be done, what do i need to do to have it done ?
<persia> james_w: smoser : `apt-get install uec` would be a metapackage, `apt-get install uec^` is a task.  Look at tasksel, rather than the metapackage.
<james_w> smoser: https://wiki.ubuntu.com/SeedManagement if you hadn't found it
<smoser> persia, it uses the ladder
<smoser> 'uec' is not a metapackage
<persia> Right.  SeedManagement is stil a good link, but look at tasksel, rather than metapackages for the refresh.
<persia> Well, sure, but the *format* of the commands is correct :)
<smoser> there were 2 things i didn't see in SeedManagement
<james_w> smoser: wile I remember, tasksel wants updating to not install ec2-init
<smoser> 1.) how to run 'germinate' ... my attempts fail
<smoser> 2.) how the bzr tree gets turned into something that is read by apt
<smoser> james_w, i dont think i follow
<persia> smoser: 2) exists in the source for the metapackages and tasksel
<james_w> smoser: tasksel still lists ec2-init for uec, it should change to cloud-init now presumably
<smoser> ah. i thought it had been changed.
<smoser> uec in lp:~ubuntu-core-dev/ubuntu-seeds/ubuntu.lucid has only cloud-init
<smoser> but does say
<sebner> jdstrand: can you tell already?
<smoser> Task-Key: ec2-init
<kees> kirkland: ok, I've updated the VT section: https://wiki.ubuntu.com/Security/CPUFeatures
<james_w> smoser: it seems that tasksel might need updating from the seeds then
<jdstrand> sebner: updated alsa-lib fixes the missing lib
<SWPadnos> I'm wondering if gphoto2 (and associated packages) can be bumped to rev 2.4.8 before everything gets frozen for Lucid today.  Is this the right place to ask for that?  :)
<jdstrand> sebner: still no sound, so I need to rebuild alsa-plugins against it
<sebner> jdstrand: Well, I have sound but I needed to use alsamixer and raise "Speakers" part
<sebner> *to gain sound
<smoser> james_w, so , my udnerstanding of this is that i need to open a bug against tasksel in karmic to resolve the dual kernels issue.
<smoser> but are you stating that there is a problem with lucid's seed ?
<james_w> smoser: tasksel in lucid is using the old package name still, so it needs updating to skip installing ec2-init
<persia> smoser: Try generating the task locally with tasksel first, just so that you're requesting the right thing in the bug.  It may be awkward to discover that a tasksel update is not itself sufficient.
<james_w> smoser: I believe this information is derived from the seeds so simply triggering the process that updates it would be enough
<jdstrand> sebner: ah, my front speakers were muted-- the pa mixer didn't work though
<james_w> persia: are you sure the kernel issue requires a tasksel update?
<persia> It is derived from the seeds, although there are some hints in tasksel that might need adjustment.
<jdstrand> sebner: so I'll still try with alsa-plugins to see if it fixes that
<sebner> jdstrand: yeah, the volume applet is not working
<sebner> jdstrand: aye
<smoser> so its an semi-automated process?
<persia> james_w: No, but I'm sure that any issues with `apt-get install uec^` are best investigated starting with tasksel.
<james_w> persia: sure
<james_w> but you are giving specific instructions to update tasksel
<persia> Yes.  When I have investigated these issues in the past, I update tasksel locally, as this seems the most straightforward way to identify the seed behaviour vs. other package collisions.
<persia> I don't think the right answer is to file a bug on tasksel, only that this is the best first step to understanding the issue.
<james_w> fair enough
<james_w> but given that tasksel doesn't mention the kernel anywhere related to uec that I have found so far I think it is the wrong path
<persia> The geneated uec^ task doesn't contain a kernel dependency or recommendation?
<Q-FUNK> jdstrand: actually, dtchen's suggestion simply has one extra $ that doesn't blong there
<persia> If so, then the next step would be looking at the image constructor (likely either livecd-rootfs or virtual-image-builder)
<james_w> persia: the generated might, but the source doesn't
<persia> james_w: The source just pulls from the seeds in a special way: that's why I suggest a local update.  I have not previously successfully investigated this class of issues through source inspection.
<james_w> yes, it pulls from the seeds to write the task description files, which for ec2 is just "Key: ec2-init\nPackages: task-fields" and description etc.
<persia> james_w: Yes, but it's the content of the tasks that become interesting.  Mind you, my previous investigations were things like trying to understand why Ubuntu MID had gnome-panel, which is a bit different.
<sebner> lamont: thank you very much! I'll give it a test :)
<james_w> persia: would you be so kind as to explain where the tasks are found?
<persia> james_w: I don't remember offhand, but I'll go update and let you know.
<smoser> james_w,
<smoser> /var/lib/apt/lists/us-east-1.ec2.archive.ubuntu.com_ubuntu_dists_lucid_main_binary-i386_Packages
<smoser> is where it seems to me to live
<james_w> smoser: in what aspect of the Packages file?
<james_w> the Task: lines?
<smoser> Package euca2ools has:
<smoser> Task: eucalyptus-cloud, eucalyptus-cluster, eucalyptus-node, eucalyptus-storage, eucalyptus-walrus, uec
<smoser> yeah, so i was assuming that that came from the archive with that in it
<sebner> lamont: is it already deployed? At least my PPA says no
<james_w> that's what I think too
<james_w> persia seems to imply different
 * persia remembers having local task definition files, and is currently building a karmic development chroot to dig into karmic tasksel more
<smoser> well, when you run tasksel -t, it shows its going to run
<smoser> debconf-apt-progress -- apt-get -q -y install uec^
<james_w> yep
<smoser> so it seems to me that either apt has the ability to turn 'uec^' into a package list or it reads that package list from somewhere else
<kirkland> kees: looks great, thanks!
<smoser> and i thoguth that somewhere else was Task:
<smoser> i very much appreciate both james_w and persia help here.
<persia> smoser: Yes, apt gets that information from the local Packages file.  What I think I remember is that tasksel generates something that informs that file.
<chris_n> why is mysql in the karmic repo built w/o the InnoDB engine?
<mathiaz> persia: not sure what you're trying to do, but you can modify Task file in the Package file by using an override file
<mathiaz> persia: and regenerating the archive with apt-ftparchive
<persia> mathiaz: That would be a very last resort :)
<persia> mathiaz: smoser is trying to understand why uec^ is pulling two kernels.
<mathiaz> persia: ah ok. I haven't read the backlog in great details
<mathiaz> persia: sorry for jumping into the conversation with non-related information
<persia> mathiaz: No worries :)
<jdstrand> sebner: fyi-- pavucontrol still didn't work, so I am not uploading alsa-plugins
<jdstrand> (alsa-lib is already uploaded)
<sebner> jdstrand: grr, annoying. Wondering what's causing this issue. Have you already added a bug comment about it?
<jdstrand> sebner: yes
<sebner> jdstrand: kk, nothing more we can do then :(
 * jdstrand nods
<hyperair> sebner: what's up?
<sebner> hyperair: sound is (partially) b0rken in lucid
<hyperair> broken how?
<sebner> hyperair: broken = not working, after some haXX0ring it works now but only if you adjust the volume with alsamixer
<lamont> sebner: and should have alien-arena sync'ed sometime today, I expect
<hyperair> sebner: that sound bad =\
<lamont> mind you, if it's FTBFS, totally your problem. :-p <-- sebner
<sebner> lamont: /me already prepared a FFe (I was bored) so I was just waiting for your confirmation :P
<lamont> ah, ok
<lamont> I did the "lalalala toolchain" dance with slangasek before FF and he said +1 for that package
<sebner> lamont: but PPA should also be fixed by now? /me tries again
<lamont> yes
<lamont> sebner: the only place that should have been broken was source upload processing
<lamont> if that fails, please scream at me here
<sebner> lamont: exactly
<lamont> that was deployed prior to closing the bug
<sebner> lamont: give me 2 minutes, I just reuploaded
 * sebner screams at lamont 
<persia> james_w: In the ubuntu-tasks directory.
<persia> smoser: With a local update, I now get four kernels installed installing the task :(
 * persia looks more
<smoser> persia, that is what i get
<smoser> in the official builds . 4 kernels.
<smoser> i think that the issue is that whatever process is doing this doesn't recognize that linux-image-2.6.31-304-ec2 is an update to linux-image-2.6.31-302-ec2
<smoser> because it *is* a different binary package
<smoser> but i really would have thought that the cd installer builds would have run into this.
<james_w> persia: yes, but what is in ubuntu-tasks/uec just says "install ec2-init and tell apt to install Task: uec" packages
<lamont> sebner: pastebin the error you're getting?
<sebner> lamont: the same as in the bug (PPA section)
<lamont> ah
<sebner> lamont: http://pastebin.com/m636967d6
<persia> james_w: That's what I'm seeing also: I'm guessing that the behaviour I saw before was from a very buggy task.
<persia> smoser: So, if I'm reading tasksel/README correctly, you're stuck as long as the control files contain the Task: header, which they do.
<smoser> james_w, are you able to make the trivial s/ec2-init/cloud-init/ in the lucid uec seed ?  the 'Task-Key:' is obsolete (http://bazaar.launchpad.net/%7Eubuntu-core-dev/ubuntu-seeds/ubuntu.lucid/annotate/head%3A/uec)
<persia> smoser: You may want to see if you can filter it some by fiddling with the image constructor.
<sebner> jdstrand: how do I put it ... it works magically now
<smoser> by 'control' you mean 'Packages' ?
<james_w> smoser: I don't have it checked out right now, persia may
<persia> smoser: Packages is generated from the several control files.
<lamont> sebner: can I talk you into another upload?
<smoser> persia, i most certainly can work around htis, but i would rather not
<persia> james_w: I can't commit there.
<james_w> oh yeah
<sebner> lamont: "talk"?
<sebner> ah
<sebner> lamont: sure
<james_w> smoser: stick up a merge proposal then please
 * persia plans to fix that in 2-4 weeks, but for now ...
<sebner> lamont: I'm available the next 3 hours at least
<james_w> I'm struggling to see where the Task is inserted
<lamont> sebner: yeah - talk as in "please push the car back to the top of the hill and lets see how it does this time"
<jdstrand> sebner: for me, my Front speakers were muted. If I unmute with alsamixer, all is fine. if I mute with alsamixer, I cannot unmute again
<jdstrand> sebner: (with pavucontrol)
<lamont> sebner: there are a number of machines...  and I think I hit them all this time
<smoser> james_w, i dont know htat either, but for the lucid issue, getting that fixed is a requirement, so i'll put a merge proposal
<james_w> it's surely not in the debian/CONTROL file, but Launchpad doesn't set it as an override either from what I can see
<sebner> lamont: heh, just tell me when I should do another test-upload :)
<sebner> jdstrand: weird
<james_w> unless there is some behind the scenes magic going on
<lamont> sebner: as in it just failed again, or you're waiting for me to say "go"?
 * persia has strong suspicions of magic
<lamont> because should be fixed from http://pastebin.com/m636967d6
<sebner> jdstrand: Now *everything* works here, I didn't update to your alsa-lib update yet though!
<sebner> lamont: go
<jdstrand> weird
<sebner> jdstrand: Ubuntu self-healing abilites are suprising me always and always ;)
<jdstrand> heh
<sebner> jdstrand: the only thing is that never is alright is the graphical volume slide (I usually adjust volume with my laptop keys) and the slide doesn't follow it correctly (means, I set full volume with the keyboard keys and the slide is maybe at a half)
<smoser> james_w, ok. i proposed you as a reviewer of a merge : https://code.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu.lucid/+merge/19647
<james_w> thanks
<sebner> lamont: still waiting on the mail ..
<smoser> persia, james_w just so i could track what is going wrong, and to avoid this occuring in lucid i opened https://bugs.launchpad.net/ubuntu/+bug/524020
<ubottu> Ubuntu bug 524020 in ubuntu "karmic uec builds fail to publish because of 2 intalled kernels" [High,New]
<james_w> smoser: ok, you need to get the overrides on cocoplum updated
<smoser> i'd appreciate if someone can accept my nomiation for lucid and karmic of that bug
<smoser> cocoplum is a new word to me
<james_w> it's the machine that the archive actually lives on
 * sebner hugs lamont and showers him with cookies. You are a GENIUS!
<james_w> what is happening is that LP is calling apt-ftparchive in such a way that it adds Task to all the packages as appropriate
<james_w> it does that using override files
<lamont> \o/
<james_w> these are not generated by LP as it works
<james_w> the files list "package-name Task foo" stuff
<james_w> so we need those updated based on an updated germinate run
<james_w> however, I have no idea how to do that
<james_w> the files are owned by lp_publish, but that user doesn't have a cron job to do it or anything
<james_w> so, I don't know if it is done manually on occasion, or LP handles it out of the path of publishing
<sebner> lamont: let me do the FF because I won't get the chance to do many this time ;)
<james_w> and now I must go cook dinner before I get in to trouble
<james_w> smoser: I hope that allows you to find someone who can actually fix it
<smoser> james_w, thanks. i'm much closer than before.
<james_w> smoser: unfortunately the soyuz people are all Europe-based, so aren't around to help
<smoser> it doesn't have to happen *right now*
<smoser> its been busted since the 4th.
<sebner> lamont: https://bugs.edge.launchpad.net/ubuntu/+source/alien-arena/+bug/523811/+index#New
<ubottu> Ubuntu bug 523811 in alien-arena "[FFe] Please sync alien-arena 7.33-2 from Debian(contrib)" [Wishlist,New]
<sebner> cjwatson: KUDOS to you too! .. as stated in the bug report ;)
<persia> sebner: All fixed now then?
<sebner> persia: yep, Kudos to you too for your help :)
 * persia didn't do anything 
<sebner> persia: you helped to track it down and supported my (miss)communication :)
<persia> The latter maybe :)
<sebner> heh
<tlp> hey guys. I just did a dist-upgrade of Lucid (from an earlier 'snapshot' of packages) and PulseAudio broke (no sound). Is this behavior expected? Trying to find a changelog or something.
<sebner> tlp: it's known, yes
<persia> tlp: Known issue, under investigation
<tlp> k
<tlp> oh, I see there's a 'lucid-changes' list
<sebner> jdstrand: urgh! My sound magically disappeared as magically as it appeared! xD
 * jdstrand shakes head
<sebner> jdstrand: interesting! Doing "aplay /usr/share/sounds/alsa/Noise.wav" magically brought my sound (banshee, firefox) back! xD
<jdstrand> too weird
<tlp> that magic unfortunately didn't work for me :p
<jdong> can a core-dev open the karmic task on https://bugs.edge.launchpad.net/ubuntu/+source/cryptsetup/+bug/474327 please?
<ubottu> Ubuntu bug 474327 in cryptsetup "Overwrite/destroy not-empty partition due to lack of vol_id from udev" [Medium,Confirmed]
<jdong> (*wonders if there's a way for ubuntu-sru to be able to do this*)
<NCommander_> doko: ping, I saw that you changed http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40860; is it possible that this regression is also responsible for the libuno breakage?
<ubottu> gcc.gnu.org bug 40860 in libgcj "[4.4/4.5 regression] regressions in libjava testsuite on arm-linux" [Normal,Unconfirmed]
<lifeless> mvo: do you know about --author ? (also james_w, does debcommit use --author ?)
<mvo> lifeless: no
<mvo> bzr --author?
<doko> NCommander_: maybe
<lifeless> mvo: when committing a patch from the internet, you can attribute it by doing 'commit --author 'Foo bar <foo.bar@example.com>'
<lifeless> mvo: you can supply the field multiple times to indicate multiple authors
<mvo> nice
<lifeless> mvo: this is useful when doing cherrypick merges too
<mvo> I don't know this one
<lifeless> cherrypicks?
<mdeslaur> Does anyone know why my locales are "utf8" instead of "UTF-8"?
<persia> Why should they be "UTF-8"?
<mdeslaur> well, it used to be that way, and "utf8" is causing problems with vm-builder
<lifeless> mdeslaur: they are homophones, depends on the way locales is setup
<persia> Isn't this a bug in vm-builder if it's relying on a specific value?
<lifeless> mdeslaur: also some stuff in libx11 is odd and uses UTF-8 in its compose tables
<lifeless> mdeslaur: what is the specific problem in vm-builder?
<mdeslaur> it's calling "locale-gen en_CA.utf8" and that is failing
<ogra> persia, it is
<ogra> i gues vm-builder just picks up from $LANG
<ogra> *guess
<mdeslaur> yes, it's picking it up from $LANG, and using locale-gen to validate it
 * ogra just helped fixing the same issue in ltsp
<mdeslaur> but locale-gen doesn't like utf8 it appears
<ogra> yes, its not supposed to
<ogra> make vm-builder read /etc/default/locale or translate the utf8 to UTF-8 properly
<lifeless> mdeslaur: it shouldn't call locale-gen anyway, locale -a is the right way to validate a locale
<ogra> lifeless, well, it probably also wants to generate locales :)
<lifeless> I suggest fixing locale-gen
<mdeslaur> I suspect vm-builder just want to make sure the locale specified by the user is a valid one...and it's using locale-gen to do that (which is very wrong). locale -a will only list existing locales. Does anyone have an idea to validate a locale string?
<lifeless> mdeslaur: define validate
<mdeslaur> lifeless: make sure it's a locale that could be valid
<mdeslaur> ie: not en_USS.utf8 by mistake
<lifeless> mdeslaur: under what conditions. Sorry to be picky but its actually nontrivial.
<mdeslaur> lifeless: it's a string that the user passes as an argument to pick which locale he wants his vm to be installed as
<mdeslaur> if it's non-trivial, I guess it doesn't need to be validated, it could just fail if there was a mistake.
<lifeless> so the full list of locales isn't available locally.
<lifeless> because installing a langpack makes a locale available
<persia> Could it be made available locally in some way?
<mdeslaur> oh, I see
<lifeless> e.g. look at your /var/lib/locales/supported.d/
<persia> Or does it exist as the collection of all defined langpacks?
<mdeslaur> then again, it would depend on the os being installed inside the vm, so even a local list doesn't really make sense
<lifeless> persia: the language control panel figures out the installable options some how
<lifeless> mdeslaur: and the available languages depends on the release of ubuntu - karmic doesn't have klingon
<lifeless> [for instance]
<persia> Ah, so vm-builder *could* know the set, and then just match to determine if it's valid, but that might bloat the chroot
<mdeslaur> lifeless: exactly
<mdeslaur> well, I think the sanest thing for now is to not validate the locale string supplied by the user
<lifeless> persia: but it would have to download the set, for the target distrorelease its building the vm for
<mdeslaur> thanks guys
<lifeless> mdeslaur: I think you could check its well formed
<lifeless> so not 'asdkaporqj'
<mdeslaur> yeah
<persia> lifeless: Sure, hence "bloat the chroot"
<lifeless> persia: ack
<persia> In addition to the list, it may need any number of tools to be able to assemble it.
<kees> pitti: I adjusted the apport anonymizer to leave several specific ProcFoo files alone since they never have host/user names, and it just confuses things.
<slangasek> mathiaz: 'start on stopped', I would think
<mathiaz> slangasek: right - smoser investigated and found the same result
<mathiaz> slangasek: the semantic are bit wired but in the end it works
<smoser> mathiaz, that is checked in now.
<sebner> slangasek: thanks for syncing but you are really killing the fun ;-P
<slangasek> sebner: your sense of fun frightens me
<dylanmccall> hi, everybody!
<dylanmccall> Does anyone here happen to work on the update manager?
<sebner> slangasek: heh, anyways. Thanks again :)
<persia> dylanmccall: Theoretically, most of us are supposed to care about it, but several of us actually have done stuff.  Why?
<dylanmccall> persia: I'm working on a little UI bug for it, and noticed there's both an UpdateManager.glade and UpdateManager.ui. Just wondering which one I should touch :)
<persia> Oh.  That's not a part I've worked on, so I don't know offhand.
<lifeless> dylanmccall: check which was changed most recently
<persia> dylanmccall: Give it a whijle to see if someone else answers.  If not, investigate the build scripts to make sure the .ui isn't autogenerated.
<dylanmccall> lifeless: aha, very wise
<dylanmccall> thanks :)
<LaserJock> hmm, is gtk+2.0 likely to be updated to 2.20 by release?
 * sebner waves at LaserJock :)
<LaserJock> hi sebner
<LaserJock> robbiew: awesome news on the twitter/identi.ca status accounts? how do people submit to that?
<robbiew> LaserJock: right now, I think we've simply setup a password that we can share...but haven't figured out exactly WHO to share it with
<robbiew> don't want it to become a spam site
<LaserJock> right
<LaserJock> I wondered if the current "any messaging app crashes" thing would count, etc.
<LaserJock> it's hard to know, but this is something I've wanted for a long time
<robbiew> LaserJock: the intention was to use it for disastrous type situations, like when we made the move to upstart last cycle...and the buildds went down in the middle of the package upload :/
<robbiew> there's always some inherent risk people take, who use the in-development releases....and we didn't want to have to change the status for every little thing
<alkisg> I have 2 keyboard layouts (us/gr). When I login with an English interface, I can see a language indicator in the panel. When I login with Greek UI, I can see an empty space in that place. Which package is that, so that I can seach why the icon is missing with the Greek UI?
<LaserJock> robbiew: maybe it could have a ramped meaning? like say pre-FF just for extreme cases and then say after Beta-freeze or something more low-level problems as more unexperienced people test?
<robbiew> LaserJock: hmm...that might be a good point
<LaserJock> robbiew: just a thought, maybe trying to match increasing expectations of stability
<robbiew> LaserJock: we have a larger plan to address the problem
<robbiew> https://blueprints.edge.launchpad.net/ubuntu/+spec/foundations-lucid-stop-the-line-for-update-manager
<robbiew> but could not fit that into Lucid
<robbiew> hopefully we can do something for Lucid+1
 * persia preemptively sets --break-my-system-please
<LaserJock> robbiew: ah, that would indeed be helpful
<lifeless> persia: 'fu**-me-harder' ? well known hacker slang ;>
<LaserJock> I don't regularly use IRC anymore and I find it hard to know wha tthe current state is
<LaserJock> I was thinking of having like a "don't install things that are newer than 2 days" button
<LaserJock> but then I figured everbody would do that and it would just move the break point
<robbiew> heh...yeah
<SWPadnos> hide the button, so only people who know how to look for it can postpone the breakage
<jcastro> robbiew: are these for development releases or for everything?
<LaserJock> it shouldn't be needed for other things should it?
<LaserJock> stable release I mean
<robbiew> jcastro: development...as once we release, I don't see how we could fubar the archive that much
 * sebner thinks about throwing ubottu with bad language notice onto lifeless :P
<sebner> +at
<LaserJock> I could see using it for things like buildd borkage or LP issues or something
<jcastro> robbiew: ok cool, I'll get the word out
<persia> robbiew: We can do all sorts of things to -proposed :)  Maybe it ought cover that kind of case as well.
<persia> (although this only affects some users)
<lifeless> hmm
<alkisg> Ah, got it, "gnome-settings-daemon".
<lifeless> you could do something interesting with suites
<lifeless> you know how debian does a waterfall with QA checks at each step
<lifeless> imagine lucid-0 (immediately when built), lucid-1 (one day old migration, no critical bugs, no missing deps), lucid-2 (etc)
<persia> lifeless: Don't we do that with -proposed and -updates?
<persia> lifeless: Oh, you mean for the development release?
<lifeless> persia: no, they are manual. Yes.
<persia> So a no-RC-bugs+no-broken-packages repo?
<sebner> lifeless: I thought devel release are meant to break ^_^
<lifeless> not suggesting it seriously, its a gedanken
<persia> Everyone would end up clamouring for that to get real support.
<LaserJock> sebner: but at some point they move from being meant to break to being meant to be tested in a decently stable state
<sebner> lifeless: denglish, shame on you :P
<lifeless> sebner: huh?
<sebner> LaserJock: we have FF and other freezes for that?!
<jcastro> sebner: plus people are going to end up using it anyways, might as well give them a warning if we are able to
<cjwatson> smoser: uec> I think it may be impossible to change this as stated; the Task fields in karmic's Packages file are frozen (as for all stable releases).  we'll have to think hard about this.  ask me next week ...
<LaserJock> sebner: yeah, but post FF it's nice to know when something bad happens
<cjwatson> smoser: all the stuff about tasksel is a red herring :)
<lifeless> sebner: thats not why we have freezes really; we have freezes to stop adding more defects than we take out.
<sebner> lifeless: gedanken, It thought it's only valid english with "gedanken experiment"
<persia> sebner: gedankenexperiment is a perfectly good English word.  If nothing else, the English are excellent word thieves.
<sebner> persia: I know but I don't think gedanken alone is valid, is it?!
<persia> WHy not?  There was no experiment involved.
 * persia doesn't think it's any usefully different than "sushi" in terms of word borrowing.
 * sebner just didn't found it in his dictionary standing alone so we was curious
<lifeless> if its literally 'mind' then its not very useful alone; I thought it was more 'thought' than mind, but a quick de dict check suggests 'mind' not 'thought
<cjwatson> it's the past participle of denken, to think
<sebner> cjwatson: yeah, I'm native german so I got curious
<sebner> lifeless: it's more thought imho
<cjwatson> as a noun it gets used for various related meanings, sort of like a gerund
<lifeless> sebner: not according to the dict I found :P. Anyhow I meant it as 'thought'
<sebner> lifeless: That's the reason why I got curious, you used gedanken instead of thought. /me likes seeing mixture of language :)
<sebner> lifeless: singular is "Gedanke" btw
<TheMuso`> any ocaml experts around could take a look at graphviz, and advise the best way to depend on ocaml-base-nox, as ocaml-base-nox-$bla via provides from ocaml doesn't work due to soyuz design.
#ubuntu-devel 2010-02-19
<TheMuso`> nvm my query above, I misread.
<smoser> cjwatson, thanks. I subscribed you to bug 524020 where I tried to describe the problem.  The big thing is that I don't want to face this again in lucid.
<ubottu> Launchpad bug 524020 in Ubuntu Lucid "karmic uec builds fail to publish due to 2 installed -ec2 kernels" [High,New] https://launchpad.net/bugs/524020
<jcole> just wanted to say that using yelp to popup help files in html format is extremely useful :)
<jcole> (aka gnome-help)
<crimsun> bah, I leave for work and stuff explodes.
<crimsun> sorry folks, fixing now.
<persia> Does anyone have a less ugly way to accomplish `LIB=$i; [ -h "$LIB" ] && LIB=$(ls -l $i | cut -d\  -f11); [ -z "$LIB" ] && LIB=$(ls -l $i | cut -d\  -f12); dpkg -S "$LIB" | cut -d: -f1` without awk?
 * persia is using it to try to determine the right package that provides a shared library given a string containing a path to the .so file
<jcole> persia: what could 'i' be
<jcole> persia: any .so under lib?
<persia> jcole: Yep, assuming libfoo-dev is installed.
<persia> Unfortunately, cut doesn't seem to have a "show me the last element" function, and I'm not sure of a good way to show symlink info other than ls.
<jcole> persia: readlink -f ?
<persia> I knew there was something better :)
<persia> dpkg -S $(readlink -f $i) | cut -d: -f1 works perfectly.  Thanks!
<jcole> persia: also if you delimit by directory slashes ('/') you could use basename to extract the "last" column :)
<jcole> persia: no problem
<ccheney> hmm why does onboard pull in the x headers?
<james_w> lifeless: I have no clue as to whether debcommit uses --author
<ccheney> ah i see the bug
<ccheney> 524148
<jcole> bug 524148
<ubottu> Launchpad bug 524148 in onboard "onboard has overactive dependencies" [Medium,Triaged] https://launchpad.net/bugs/524148
<persia> ccheney: Because it's *hard* to use CDLL sanely :)
<lifeless> slangasek: do you get nervous on every pam upload?
<tlp> sebner, persia: is there a bug report for this pulseaudio regression?
<crimsun> tlp: which one? The alsa-lib one is already fixed in 1.0.22-0ubuntu4
<crimsun> tlp: the "unable to change volume controls" one is known; I'll be uploading the fix after testing it locally.
<tlp> crimsun: I did a dist-upgrade this morning from an earlier set of Lucid packages and my sound broke completely, but the pulseaudio process is running
<tlp> I checked alsamixer and nothing seems to be muted
<tlp> by broke I mean there is no output, but otherwise everything seems in order
<tlp> I need to reboot here, but I'll check out syslog shortly
<superm1> crimsun, did something happen to libpulse-dev?  i had a build build against it successfully two days ago, and yesterday it appears to have not?
<superm1> the configure test for pulse seems to have failed the next day
<superm1> no code changes on my end
<superm1> seems to have broken from 1:0.9.22~0.9.21+stable-queue-32-g8478-0ubuntu5 to 1:0.9.22~0.9.21+stable-queue-32-g8478-0ubuntu6, but there is now an ubuntu8, so if I queue another rebuild, should things be fine on ubuntu8?
<LaserJock> good grief that's a nasty looking version number
<superm1> yeah i have no idea what that really is
<LaserJock> looks like at some point we said "screw it, I'm doing changelog entries in the version string" ;-)
<superm1> haha
<superm1> i should click bug links; https://bugs.edge.launchpad.net/ubuntu/+source/pulseaudio/+bug/523716
<superm1> that would appear to be the cause of problems
<ubott2> Ubuntu bug 523716 in pulseaudio "pulseaudio version defined as UNKNOWN, which breaks everything with build-dep on libpulse-dev" [High,Fix released]
<julio> hola buenas
<julio> desde argentina, necesito ayuda
<julio> alguien habla castellano?
<tlp> glad it's not just me who has trouble parsing that
<julio> hay alguien aca?
<julio> pero, pero
<crimsun> LaserJock: upstream hasn't released from the master branch, and their wishes are for us to use another branch (stable-queue). That version string is slightly modified from git-annotate output; essentially it's "32 changesets have been committed since this last tag (0.9.21), and the hash can be uniquely identified by 8478"
<julio> un monton de gente conectada y nadie contesta?
<LaserJock> julio: #ubuntu-es?
<julio> estan todos durmiendo
<julio> ok
<julio> #ubuntu-es
<LaserJock> crimsun: this is something about DVCS I've noticed now, it is much harder to version snapshot packages nicely
<LaserJock> julio: #ubuntu-ar
<LaserJock> julio: http://ubuntu-ar.org/argentina/irc
<LaserJock> julio: Lo siento, no hablo espaÃ±ol. este es el mejor que puedo hacer
 * LaserJock crosses fingers that Google didn't just say something dirty ;-)
<tlp> Feb 18 21:16:18 maya pulseaudio[16207]: module.c: Failed to load  module "module-esound-protocol-unix" (argument: ""): initialization failed.
<tlp> I wonder if that has something to do with it
<julio> gracias
<tlp> crimsun: can you give me any leads as to what might have changed to cause this problem?
<StevenK> LaserJock: Haha
<tlp> bah, something did mute ALSA.
<tlp> I didn't catch it the first time.
<tlp> disregard. Someone said earlier what I reported was a known problem, so I assumed there was a regression.
<tlp> I don't understand the relationship between PulseAudio and ALSA well enough to know why that happens, but it happens constantly.
<tlp> but I've gotta go launch alsamixer or something to even notice something is muted
<crimsun> tlp: ok, I'll repeat. There was a change that broke pulseaudio. alsa-plugins was compiled against this broken pulseaudio. I fixed pulseaudio and alsa-plugins, then realized that alsa-lib was missing a configure variable. That was fixed twice. Now the "can't (un)mute/adjust volume" issue is caused by certain alsa-mixer/paths files not being installed but still being referenced. I'm building and testing the fix to push upstr
<tlp> Perhaps it was the former. I don't have any trouble with volume controls in "Sound Preferences"
<tlp> I just know from past experience that silent output, a fair percentage of the time, means something got muted at the ALSA level. So I always check that first.
<crimsun> alsa itself is fine now; it's the mixer paths that are affecting PA
<tlp> okay. thanks for the clarification
<persia> deb-substvars has successfully confused me.  debian/substvars contains "cdll:Depends=libx11-6, libxi6", and debian/control contains "Depends: ${cdll:Depends}".  Do I need to do something else to make this just work?  Could anyone recommend an example package that does this right?
<StevenK> persia: That should be right
<persia> That's what all the documentation says.  Apparently, CDBS adds a special -T which caught me.
<StevenK> persia: An example package I can think of is fbreader, but probably Jaunty
 * persia is hoping this works this time
<persia> Thanks.  If this doesn't work, I'll look there.  That was lpia-magic?
<StevenK> Yeah, that was lpia magic that changed Depends with substvars magic
<StevenK> Too much magic ...
<persia> Indeed.  Now there is no special smoke, and we can all rejoice :)
 * cody-somerville rejoices.
<pitti> Good morning
<pitti> kees: thanks
<crimsun> to summarise: sound problems from yesterday all fixed up. Patches pushed upstream where applicable. Sorry for the delay (real life, work, yadda).
<persia> crimsun: Surely you're not really using yada!
<crimsun> oops, slid that additional 'd' in there
<superm1> pitti, re bug 523649, that code snippet that it crashed on has been there a while.  has the behavior of 'assert' changed in python? from what i gather, it's behavior is changes if __debug__ is True, but that's not manually modifiable.  so perhaps that was caused by https://lists.ubuntu.com/archives/lucid-changes/2010-February/005739.html
<ubottu> Launchpad bug 523649 in ubiquity "ubiquity crashed with RuntimeError in progress_loop()" [Undecided,New] https://launchpad.net/bugs/523649
<superm1> which makes me thing that assertion isn't correct in the first place the way it's written
<pitti> hi superm1
<pitti> superm1: I don't think assert changed recently
<superm1> http://docs.python.org/reference/simple_stmts.html#the-assert-statement .  "The current code generator emits no code for an assert statement when optimization is requested at compile time" is what put me on that thought process
<superm1> and hi pitti :)
<pitti> superm1: do you know whether one of the reported crashes is just a followup of the other one?
<pitti> I never saw two crashes at once so far
<superm1> pitti, they look like they are caused by one-another to me yes
<superm1> the important one is the one that crashed in install.py with the assertion error
<superm1> that runtime error will go away when the assertion error is fixed
<pitti> superm1: ok, please feel free to invalidate the other one then
<pitti> bryceh: oh, CD builds failed because -nouveau is uninstallable (it's still in universe)
 * pitti promotes and closes MIR
<bryceh> pitti, danke
<pitti> bryceh: so the lbm metapackage is sorted out now?
<bryceh> pitti, I believe so.
<bryceh> pitti, I haven't verified that yet though
<pitti> linux-backports-modules-nouveau-lucid-generic | 2.6.32.13.14 |         lucid | amd64, i386
<pitti> \o/
<pitti> Source: linux-meta
<pitti> Depends: linux-backports-modules-nouveau-2.6.32-13-generic
 * bryceh nods
<pitti> looks fine
<bryceh> yeah I pulled the source and checked the changelog and so on and it all looked kosher
<pitti> bryceh: want to have the pleasure of closing two work items? :-)
<bryceh> on it
<pitti> add nouveau lbm metapackage as dependency to xserver-xorg-video-nouveau: TODO
<pitti> that sounds easy now
<pitti> great, then this should be done
<pitti> well done!
 * pitti yays for KMS on nvidia
<bryceh> it was a good team effort
<bryceh> thank god for RAOF and Sarvatt
<bryceh> pitti, did you see that we now have apport collecting bugs on X freezes now too?
<pitti> bryceh: yes, I saw the WI and the upload
<pitti> \o/
<pitti> bryceh: craving for more bug reports? :-)
<bryceh> heh, heck no
<pitti> seriously, I hope this will be a huge help in tracking those down
<pitti> right now we can't do much more than just shrugging, I guess
<pitti> s/right/until/
<bryceh> actually I think it will help because before people would file bugs about freezes but it took a lot of effort to walk the user through collecting this info
<bryceh> pitti, hmm it looks like lbm is already listed as a depends for -nouveau?
<bryceh> Depends: ${shlibs:Depends},
<bryceh>  ${misc:Depends},
<bryceh>  ${xserver:Depends},
<bryceh>  linux-backports-modules-nouveau-2.6.32-12-generic | linux-backports-modules-nouveau-2.6.32-12-generic-pae | linux-backports-modules-nouveau-2.6.32-12-server
<bryceh> do we need anything beyond that?
<pitti> bryceh: no, only an (obsolete) ABI version, not the metapackage
<bryceh> oh right
<bryceh> so it's enough to just Depends on linux-backports-modules-nouveau-lucid-generic ?
<pitti> bryceh: I don't see a metapackage for -i386 or -server
<pitti> so from my POV yes
<slangasek> lifeless: generally only the ones when upstream is rewriting code :)
<pitti> bryceh: oh, incidentally this is quite urgent; lbm-n is uninstallable
<pitti> bryceh: due to the obsolete abi
<pitti> bryceh: if you could change that now, I can trigger a new CD build later today, so that we finally have buildable CDs again (also for testing)
<bryceh> doing it now
<pitti> bryceh: cheers
<bryceh> uploaded
<dholbach> good morning
<bryceh> pitti, 3 WIs closed
<pitti> \o/
<pitti> http://people.canonical.com/~pitti/workitems/canonical-desktop-team-lucid-alpha-3.html#bryceharrington
<pitti> down to 1 then, go, Bryce, go!
<pitti> Close out all -nv bug reports filed before transition as obsolete due to move
<pitti> now, that sounds like a fun one :)
<bryceh> yep
<pitti> "Status: invalid\n nv, we do not love you any more, kthxbye"
<tjaalton> we still need it for the really old chips though
<pitti> tjaalton: yes, but we still don't love it, I take it :)
<tjaalton> pitti: got that right :)
<pitti> ok, I think the Xsession.d/ scripts are really streamlined now
<bryceh> sweet
<pitti> tjaalton: I hope I didn't screw up any git with my xorg upload?
<bryceh> pitti, I fixed it
<pranith> is the UNR the choice if we want to install on ARM devices?
<pitti> bryceh: my ubuntu6 followup as well?
<tjaalton> pitti: yeah it's ok
<pitti> bryceh: thanks
<tjaalton> that one isn't there yet
<pitti> I think I'm down to exactly one external program now ("cat"), thanks to dash not having $(< file)
<bryceh> pitti, oh no I just did the first one
<pitti> sorry for the blunder of the first one
<tjaalton> bryceh: probably add -nv back to video-all as well?
<pitti> I uploaded that, went to bed, and thought "oh argh"
<bryceh> tjaalton, yep
<bryceh> tjaalton, pushed
<bryceh> pitti, how are we on disk space?
<pitti> bryceh: I don't know; we didn't have buildable CDs for several days
<pitti> I chopped some langpacks
<pitti> but each day there was something else causing uninstallability
<smoser> james_w, somehow , in my greatness, i got http://bazaar.launchpad.net/%7Eubuntu-branches/ubuntu/lucid/cloud-init/lucid/annotate/head%3A/.bzr-builddeb/default.conf commited with "native = True"
<smoser> and that is wreaking havok
<pitti> bryceh: once your -nouveau fix is pushed, I'll trigger a rebuild
<smoser> i branched from that, and worked by way to  lp:~cloud-init-dev/cloud-init/lucid
<smoser> which i believe is in a "fixed" state.
<bryceh> pitti, subject: [ubuntu/lucid] xserver-xorg-video-nouveau
<bryceh>         1:0.0.15+git20100128+2630a15-0ubuntu2 (Accepted)
<pitti> bryceh: right, it's already built; now just waiting for the next publisher to finish (in 1:20 hours)
<apw> anyone seen this on the buildds, this is on arm, /usr/bin/dpkg-deb: line 53: 15639 Segmentation fault      /usr/bin/pkgmaintainermangler $ORIGINAL_ARGUMENTS
<apw> that message implies dpkg-deb is a script, which its not on my local installs ...
<didrocks> lool: on netbook seed, I see the Germinate workaround about webfav and abrower. I would have thought that we have to list firefox before webfav so that it doesn't download abrowser (and furthemore, if I just try to install abrowser, it tries to install last firefox)
<pitti> bryceh: fun that the freeze hook works now -- there's a typo in teh udev rule: "ACTION=="change"
<pitti> bryceh: (first " before ACTION)
<bryceh> oops
<bryceh> how'd that get there?
<admiral0_wrk> hi
<admiral0_wrk> i'm posting here because it's more relevant than #ubuntu
<admiral0_wrk> where is the source for efl interface in netbook remix?
<pitti> I was just going to answer, but if you disappear after 60 seconds..
<ogra> pitti, yours to slow, really
<ogra> *you're
<apw> pitti, cjwatson, any suggestions how to debug this:
<apw> /usr/bin/dpkg-deb: line 53: 15639 Segmentation fault      /usr/bin/pkgmaintainermangler $ORIGINAL_ARGUMENTS
<apw> dh_builddeb: dpkg-deb --build debian/sata-modules-2.6.32-14-versatile-di ../sata-modules-2.6.32-14-versatile-di_2.6.32-14.19_armel.udeb returned exit code 139
<apw> seems to only occur on buildds
<ogra> apw, buildd hiccup, just give back
<apw> why the heck did it have to do it on the build which takes 6 hours ... ie. arm
 * primes2h waves tseliot
<ogra> apw, because it only does that with very long building packages ...
<ogra> apw, aks the kde guys how much fun they have with our armel buildds :)
<ogra> *ask even
<primes2h> tseliot: Did you read the last comment? https://bugs.launchpad.net/ubuntu/+source/linux/+bug/499445
<ubottu> Ubuntu bug 499445 in linux "Conflicts between Broadcom 4312 wireless driver and internal Bluetooth on HP Mini 110" [High,Invalid]
<primes2h> tseliot: I think a SRU could be worthwhile
<primes2h> tseliot: That version has just been uploaded in Lucid..
<primes2h> tseliot: as I see some days ago
<primes2h> tseliot: What do you think?
<pitti> apw: urgh, no immediate idea I'm afraid :/
<pitti> apw: maintainermangler is just pure shell
<apw> yay
<ogra> apw, itzs very likely a buildd kernel memory management issue ... and we cant replace the kernels on these machines easily
<tseliot> primes2h: yes, I did that upload. We're considering idea of an SRU
<primes2h> tseliot: That's really nice. So can I nominate it for Karmic?
<tseliot> primes2h: it's something we'll deal with if we decide to file an SRU
<primes2h> tseliot: Ok, so I'll patiently wait for it ;-)
<primes2h> Thank you.
<tseliot> np
<davidekholm> Hi. I'm the founder of Jalbum (http://jalbum.net). We've just adopted our web photo album software for Ubuntu and packaged it as a .deb package
<davidekholm> Can anyone here give me guidance on how to get Jalbum into "Ubuntu Software Center"
<davidekholm> We're true freeware, no crippleware, but Jalbum is only 50% open source - generic code under LGPL but still some core code not opened.
<davidekholm> Anyone with input on this?
<Tm_T> davidekholm: I think that falls to #ubuntu-motu (:
<davidekholm> Ok. I'll post there and see what repsonse I get.
<pitti> superm1: would you happen to know an easy workaround for the installer failure?
<pitti> superm1: oops -- it just occured to me that it didn't even ask me for partitioning
<soren> Is it intentional that onboard pulls in a whole stack of x development packages?
<soren> persia: You touched it last :) Any idea?
<wgrant> soren: He last touched it to remove those dependencies.
<soren> Oh. Heh :)
 * soren kicks his mirror around a bit
<Phurl> hi all, I have a problem with building a qt app on karmic. https://bugs.launchpad.net/ubuntu/+source/qt4-x11/+bug/524354 do I need to upgrade my qt?
<ubottu> Ubuntu bug 524354 in qt4-x11 "problem building qgis from source cannot call constructor âQVariant::QVariantâ directly" [Undecided,New]
<pitti> bryceh: yay, I just got an apport reported freeze bug!
<jdub> pitti: thanks for remotely teaching me about the type builtin today :-)
<pitti> hey jdub, how are you?
<jdub> pitti: lovely - you?
<pitti> I'm great, thanks!
<pitti> still struggling with boot speed, though
<jdub> lucid is rocking along nicely
<pitti> yeah, it is, if only plymouth would work :)
<jdub> heh
<jdub> been having issues with that on my netbook, but not my desktop
<pitti> bryceh: except that the GPU dump says "no such file or directory" :(   perhaps it doesn't get along so well with collecting infos after a reboot
<chrisccoulson> pitti - how do you get apport to report a freeze?
<chrisccoulson> X freezes constantly on my laptop now
<pitti> chrisccoulson: it "just happens"
<pitti> xserver-xorg-video-intel.2010-02-19_12:55:36.379175.crash
<chrisccoulson> pitti - it's magic? ;)
<pitti> chrisccoulson: with today's xorg
<bryceh> pitti: sweet... did you not have intel_reg_dumper installed maybe?
<pitti> indeed I don't
<pitti> xserver-xorg-video-intel-dbg, isn't it?
<pitti> ah, no, intel-gpu-tools
 * pitti -> lunch
<nigelb> bryceh: thanks for sponsoring a debdiff I posted a few days back :)
<bryceh> nigelb, my pleasure
<nigelb> :)
<jiboumans> hi gents, we got a question on the ubuntu-server mailing list about nfs v4 for lucid+1. has anyone here given that any thought before? https://lists.ubuntu.com/archives/ubuntu-server/2010-February/003808.html
<ttx> Hm, looks like console-setup no longer sets up keyboard on recent ISOs
<ttx> bug 524439
<ubottu> Launchpad bug 524439 in console-setup "20100219 Server ISO fails to set up console keyboard correctly" [Undecided,New] https://launchpad.net/bugs/524439
<pitti> apw, tjaalton: do you happen to know about the status of bug 507148?
<ubottu> Launchpad bug 507148 in xserver-xorg-video-ati "[lucid] desktop runs out of video memory on ATI Radeon Mobility 7500" [High,Confirmed] https://launchpad.net/bugs/507148
<pitti> this sounds like it could require a painful backport of the .33 ati driver? (AFAIUI, upstream does not recommend us to use .32, but .33, which will be supported longer)
<apw> pitti, i think that one is the one where KMS doesn't work for that board, and it also crashes a bit
<apw> if so: then i think we had a few patches for it which might mean nomodeset might work for it
<apw> but ... as you say upstream is saying "2.6.32 is crap use .33 we don't care about .32'
<apw> its not clear how that gives us any more support really as they won't care about .33 in about 2 weeks either
<pitti> apw: hm, I thought they said "we'll support that longer", perhaps they also release something with it?
<apw> yeah but htat might just mean, "cause we care about the previous release until the next one" for all i actually know
<pitti> ok
<apw> pitti, but yes we are getting pressure for ati to be .33 indeed they are actually saying 'drm' at .32 is crap
<apw> and that we should be backporting .33 drm en-toto for long term use
<hyperair> http://pastebin.com/m58534978 <-- is udev supposed to fork this many times?
<pitti> that sounds like fun
<apw> i have an action to see how hard that is, then its up to bryceh to chose i suspect
<pitti> hyperair: erm, no
<hyperair> pitti: okay. this is weird >_>
 * hyperair sighs. such a problematic laptop
<hyperair> from pulseaudio leaking memory to udev forkbombing to undetected usb devices...
<hyperair> i can't possibly think of any machine that is less ubuntu-friendly than this
<tjaalton> apw, pitti: f12 already has the .33 drm on top of .32, so it'll end up in rhel6 as well
<tjaalton> and at least bits from .34
<pitti> what a mess :/
<tjaalton> why?
<apw> upstream drm seems to have no idea what 'release' means
<apw> its not meant to mean 'drop the tip ... NOW'
<apw> tjaalton, how do you expect to be able to support a lash up like that for 5 yeas
<tjaalton> .32 drm is buggy all over the place
<tjaalton> 3y for the desktop
<apw> you'd think they would produce some fixes for it though wouldn't you
<tjaalton> just pull in what rhel6 has
<pitti> I guess going with .33 is entirely out of question?
<apw> pitti, the whole of .33?
<tjaalton> pitti: no, that's what will likely happen
<tjaalton> just the drm of course
<pitti> apw: yes
<tjaalton> drm is self-contained
<pitti> (for having the same kernel version as other distros, and thus sharing patches, etc.)
<apw> it would put us out of sync with long term support release
<tjaalton> pretty much completely separate from the rest of the kernel
<pitti> tjaalton: oh, it's relatively independent of the other kernel bits?
<tjaalton> pitti: right
<apw> the other distros seem to be going .32 + .33 drm
<pitti> if it's sanely possible to pull the drm .33 bits, this would certainly be better than taking all of .33
<tjaalton> we also need the nouveau abi bump that'll happen for .34 (and was reverted from the libdrm 2.4.18 I just uploaded)
 * pitti remembers a recent LKML post about Linus not being happy about so many recent regressions
<apw> pitti, yeah ... i am lookin at it
<pitti> apw: May the source be with you!
<apw> the nouveau people are even worse
<tjaalton> http://cvs.fedoraproject.org/viewvc/rpms/kernel/F-12/drm-upgrayedd.patch?view=log
<tjaalton> well, nouveau hasn't even had a release yet
<tjaalton> but it should happen after .33 I think
<apw> its in .33?
<tjaalton> yes
<apw> so when .33 releases it will be released
<tjaalton> that's why lbm has it no? :)
<tjaalton> well I meant the ddx
<tjaalton> there has been no tagged releases
<tjaalton> so far
<apw> so there will be no userspace support for .33 nouveau ?
<tjaalton> apw: we have it now, but we need to backport fixes from >= .34 in the future, so having the new abi in lucid is beneficial
<apw> what a damn mess
<tjaalton> it's still better than status quo
<apw> dpeends if you have to try and maintain the kernel that results from the fusion
<soren> I'm confused by the locale names I see in Lucid. So, gdm sets my $LANG to da_DK.utf8. It's been da_DK.UTF-8 since almost forever, but now it's changed. /usr/lib/locale/da_DK.utf8 does exist, but "locale-gen $LANG" no longer works, since locale-gen still expects da_DK.UTF-8.
<soren> I'm not sure who or what to blame.
<BenC> Good morning people of Ubuntu
<ion> pitti: Yay for a default keyboard shortcut for launching a term.
<soren> BenC: Hey dude.
<pitti> ion: :)
<dholbach> bah, why does rhythmbox try to index my whole harddisk everytime I start it
<dholbach> ok, rather ~, but that's still bad enough
<ion> Do you have ~ set as the media library path?
<davmor2> guys une doesn't show the install option in favourites
<ion> apw: linux-backports-modules-nouveau-lucid-generic is mistyped with ânoveauâ. linux-backports-modules-wireless-lucid-generic-pae depends on linux-backports-modules-2.6.32-13-generic-pae instead of linux-backports-modules-wireless-2.6.32-13-generic-pae.
<dholbach> ion: I don't have a media library path set
<apw> ion, ta
<soren> I wonder if it'd make sense to have the build-essential seed not include recommends.
<soren> It would free at least a couple of MB on the ISOs.
<soren> (manpages-dev alone eats 3 MB)
<soren> brb
<Laibsch> Hi
<Laibsch> git-buildpackage in lucid currently does not handle dpkg v3 which I guess is a pretty serious thing.  The version in testing and unstable does.  I think there is a minimal patch available that could be backported to the lucid package but I wonder if it isn't better to still try a merge instead.  Opinions?
 * Laibsch is afraid we may end up backporting just about everything
<superm1> pitti, i think it's a small fix, the pointer that partitioning wasn't being asked is the real problem
<kitallis> \//k
<persia> soren: We talked about `locale-gen ${foo}.utf8` earlier, and the consensus seemed to be that either vm-builder needed to do something like language-selector to get a complete list of locales (and match against it), or just check for well-formedness, as 1) the complete list of locales is not available locally without extra work, and 2) the set of locales differs by release.
<soren> persia: It does seem rather odd that "locale-gen $LANG" doesn't work.
<soren> regardless
<persia> Why should it work?  There's no guarantee that the relevant langpack is installed in the chroot.
<soren> Not in my chroot.
<soren> On my own system.
<persia> OK.  There's no guarantee that the relevant langpack is installed on your system :)
<soren> $ locale-gen $LANG || echo this is weird
<soren> this is weird
<soren> Well.. it is.
<soren> locale-gen expects the charset to be "UTF-8", not "utf8".
<persia> soren: You may want to review http://irclogs.ubuntu.com/2010/02/18/#ubuntu-devel.txt from 21:25 for more in-depth discussion.
<ogra> well, there is no guarantee that $LANG is sometinh locale-gen can use
<soren> I didn't say I wanted a guarantee.
<soren> i'm just saying it's odd.
<soren> Can't we just all please accept that my life would be easier if everyone else did something differently?
<soren> kthxbai
<persia> Accepting that is easy.  Now make sure it's everyone's goal :)
<pitti> soren: I can't make a lot of sense from this either, FWIW; locales have been .UTF-8 forever, and in lucid libc6 seems to have switched to .utf8
<pitti> like "almost, but not quite"
<soren> pitti: Exactly.
<pitti> I haven't investigated it at all, though
<ogra> i know cjwatson has looked at it
<pitti> soren: however, locale-gen $LANG does work
<soren> It doesn't.
<ogra> it doesnt
<pitti> it's just that LANG=de_DE.utf8, not .UTF-8 any more
<soren> It silently fails.
<soren> Check the exit code.
<pitti> oh
<pitti> ok, that's a bug
<soren> ...and try it with UTF-8.
<soren> See the difference.
 * persia suspects a bug in locale-gen
<pitti>         GENERATE=`grep -E "^${1}( |[._@][^[:space:]]* )UTF-8" /usr/share/i18n/SUPPORTED`
<pitti> that was me, in ancient times
<soren> Oh!
<pitti> /usr/share/i18n/SUPPORTED also needs to be updated then, I figure
<pitti> but I'm still not sure what the "canonical" form is
<pitti> we don't do any migration on upgrade right now
<pitti> and I don't even know whether .utf8 was even intentional
<soren> We can argue all day long that /[uU][tT][fF]-?8/ are all valid ways to write it, but we've always done it one particular way. It would be nice to at least understand why it changed.
<pitti> ack
 * pitti will read the IRC link from persia after meeting
<soren> ..and for another week, I'm still getting paid to understand this operating system, and not just accept when it changes underneath me. :)
<mdeslaur> soren: you know that by saying that you've effectively deferred the investigation for a week, right? :)
<soren> mdeslaur: I do now :(
<soren> Darn it.
<mathiaz> what needs to be done to promote a binary package to main? (puppet-common is currently in universe - while puppet is in main)
<mathiaz> puppet-common is already in the component-mismatch list since puppet and puppetmaster (both in main) depend on it
<pitti> mathiaz: just poke an archive admin
 * pitti looks
<pitti> mathiaz: done
<mathiaz> pitti: \o/ - thank you!
<qense> pitti: there is this comment in /etc/apport/crashdb.conf: "# NOTE this will change Fall '07 when RHT switches to bugzilla 3.x!" Fall '07 has already been a while ago now, is it still valid?
<pitti> qense: no, I don't think so; Fedora decided to NIH apport
<qense> pitti: ok, then shouldn't this be removed?
<qense> (me=afk)
<pitti> qense: we could, yes, but it would be a rather pointless conffile change
<qense> pitti: ok
<pitti> qense: if I'll ever change it for another reason, I'll remove the entire stanza
<lool> Would someone be so kind to NEW linux on all arches?
<pitti> lool: I'm on it
<lool> pitti: Thanks a lot!
<lool> That will allow to poke the versatile armel udebs over the weekend
<lool> (and will also allow me to give back user-mode-linux, but that's minor)
<pitti> l;oall done
<pitti> argh, what was that
<pitti> lool: all done
<pitti> right in time for the publisher
<lool> pitti: thanks a lot!
<pitti> superm1: my hero!
<superm1> :)
<geser> ScottK: does this https://bugs.edge.launchpad.net/ubuntu/+source/pysvn/+bug/523863/comments/5 answer your question?
<ubottu> Ubuntu bug 523863 in pysvn "Merge pysvn 1.7.2-2 from Debian testing" [Undecided,Confirmed]
<superm1> pitti, after that publishes can you queue up an ubuntu daily-live rebuild?  I'm suspecting it's far more widespread than just your hardware.. the consequences were pushing the partman pages out to "post-install" pages
<nigelb> Do we still have time to add apport hooks to packages?
<pitti> superm1: sure; I was going to fiddle with the seeds anyway to make it not overflown any more
<nigelb> been thinking of creating a rhythmbox hook.  Wondering if its still possible for lucid
<smoser> slangasek, the branch linked to bug 524516 has all the needed fixes in it.
<ubottu> Launchpad bug 524516 in cloud-init "[FFE] run cloud-init early and add runcmd support" [High,Confirmed] https://launchpad.net/bugs/524516
<smoser> verified that with that build and a new upstart, it runs early and reliably.
<smoser> slangasek, how should i proceed there ?
<slangasek> smoser: I'm going to take care of fixing upstart today; do you want to wait for that before changing cloud-init, or maybe just have cloud-init add a versioned dep on upstart?
<smoser> well, if you're going to get it fixed today, i'm ok to wait.
<smoser> if you think i should add a versioned dep, then i'm ok to do that.
<ScottK> geser: It does.
<slangasek> smoser: so what was the other cloud-init job with the unsatisfiable 'and' condition (and what was the condition)?
<smoser> well, it seemed that anything that depended on 'cloud-config and local-filesystems' or 'cloud-config and filesystems' would cause issues.
<smoser> err.. wait.
<smoser> yeah, thats right.
<smoser> cloud-init emits cloud-config, and anything that had those 'start on' listed above would seemingly block boot.
<smoser> i changed them to just depend on filesystems, with the implicit assertion that cloud-config would alrady be done at that point.
<shtylman_> where is the best place to ask about package dependency conerns/problems?
<fabrice_sp> dbus is back in lucid? I thought it would disappear in lucid
<smoser> slangasek, please let me know if you need anything from me.
<persia> shtylman_: Depends on the package.  Here works, or a team channel for the developers working on that packages, if it's specific.
<shtylman_> persia: k
<shtylman_> well...my problems started with: http://packages.ubuntu.com/lucid/liblua5.1-sql-mysql-2
<shtylman_> which wants 15off version
<shtylman_> and other system libraries use the 16 version
<shtylman_> so I get some conflicts and executables with two versions in them
<shtylman_> and nice warnings like:
<shtylman_> /usr/bin/ld: warning: libmysqlclient.so.16, needed by
<shtylman_> /usr/lib/gcc/x86_64-linux-gnu/4.4.3/../../../../lib/libmysqlpp.so, may
<shtylman_> conflict with libmysqlclient.so.15
<shtylman_> and I don't seem to be able to remove one or the other without causing a massive removal of other packages....
<shtylman_> I dunno if its an actual issue...but I figured I would ask
<shtylman_> and get some clarification
<fabrice_sp> shtylman, in Debian, this package is using 16 version, so it seems that the ubuntu version needs to be rebuilt
<shtylman_> fabrice_sp: do I need to file a bug or something?
<shtylman_> cause right now it makes things kinda broken :)
<fabrice_sp> shtylman, no bug reported right now, so file one, please :-)
<shtylman_> against which package? and how should I describe it? to make it clear and such
<fabrice_sp> agains liblua5.1-sql-mysql-2
<shtylman_> fabrice_sp: k
<fabrice_sp> a lot of pacakges still depends on 15off ,so it seems some transition is on going
<fabrice_sp> (or missing)
<shtylman_> heh
<shtylman_> fabrice_sp: should I subscribe anyone to it? or leave as default
<fabrice_sp> subscribe me (fabricesp): you just uncovered a wide issue, so I'll have a look (a rebuild is not enought)
<fabrice_sp> shtylman, ^
<shtylman_> fabrice_sp: will do... I loe uncovering wide issues :)
<fabrice_sp> :-D
<slangasek> smoser: ah, right, presumably because cloud-init isn't emitting cloud-config asynchronously :)
<slangasek> but yes, an implicit assertion is fine
<smoser> slangasek, regarding the FFE bug, please let me knwo if you need anything .
<smoser> i have to be leaving, but will check in later.
<slangasek> smoser: which FFe bug is this?  I don't see anything in my mailbox suggesting ubuntu-release has been subscribed to a bug
<smoser> hm..
<smoser> bug 524516
<ubottu> Launchpad bug 524516 in cloud-init "[FFE] run cloud-init early and add runcmd support" [High,Confirmed] https://launchpad.net/bugs/524516
<slangasek> oh, 524516, I see it on the webpage
<smoser> i was under the impression you'd sponsor that for me? or do i need to get someone else.
<smoser> sorry if that was way off base.
<slangasek> right - ok, will process that and let you know
<slangasek> well, I was saying that I was fixing upstart, which I've just uploaded
<jbebel> cjwatson: You'll be interested in fixing 524637. patch supplied.
<slangasek> smoser: the branch you've linked from 524516 doesn't correspond to the archive at all
<slangasek> smoser: cloud-init is at 0.5.5-0ubuntu2 in the archive; the bzr branch's changelog lists neither of 0.5.5-0ubuntu{1,2}
<lamalex> Hi, I'm getting confused on what the procedure is to have a package sync'd from debian into universe
<lamalex> Do I still file a needs-packaging bug?
<lifeless> requestsync
<lamalex> !requestsync
<c_korn> !syncrequest | lamalex
<ubottu> lamalex: Helpful information for filing a sync request can be found at https://wiki.ubuntu.com/SyncRequestProcess
<lifeless> lamalex: its a command, in ubuntu-dev-tools
<lamalex> lifeless: yah, I just saw that
<lamalex> thanks
<lamalex> lifeless: does this apply for new packages as well?
<lifeless> yes, though its a little tricky to get the bug filed
<lifeless> I normally upload a stub package to my ppa to make the SPR and then I can file the bug:P
<lamalex> hm actually it's already been sync'd. I don't know how I missed it when I was searching the first time
<slangasek> lifeless: you don't just file it against Ubuntu, nopackage?
<lifeless> slangasek: no
<lifeless> slangasek: the other thing I tend to do is waylay an archive admin
<slangasek> tsk, queuejumper
<lifeless> slangasek: not at all
<lifeless> slangasek: I say 'please run the damn queue'
<slangasek> we're past DebianImportFreeze
<slangasek> so that won't get you much :)
<lifeless> slangasek: so I'll queuejump now ;)
<ScottK> lamalex: We're past Feature Freeze, so you'd need a feature freeze exception and a good reason.
<lamalex> ScottK: doesn't matter anyway
<lamalex> it's been sunc(?)
<persia> synchronised
<lifeless> sunk, but its a false friend
<lifeless> synced
<lamalex> I'm gonna stick with sunc, it's got nice phenomes
<lamalex> very guttural
<slangasek> I endorse this participle
<slangasek> smoser: "cloud config and local-filesystems and net-device-up IFACE=eth0" - "local-filesystems" should always be after the other two if this package is installed, no?
<ev> jbebel: committed and uploaded
<ev> 524637, that is
<jbebel> ev, excellent, thanks!
<ev> sure thing.  Thanks for the patch!
<lifeless> james_w: did you file a bug about trial <-> testresources and your port listening resource?
<james_w> no
<lifeless> I just found the mail you sent me before we spoke
<lifeless> I would like it if you filed a bug /somewhere/ - there clearly is a problem
<james_w> I sent it after we spoke, when you asked me to send you a mail about it so that you could file the bug at twistedmatrix
<slangasek> smoser: oh, ignore me, that's exactly what you fixed, I was reading the diff backwards
<james_w> or at least, that's what I understood from our combination
<lifeless> james_w: ah! ok. I shall handle
<james_w> thanks
<james_w> you'll to a better job of the discussion with them than I woul
<slangasek> smoser: "start on filesystems" - that's not the documented event that mountall emits, that should be 'filesystem'
<YokoZar> What happened to libxtrap6?  Was it obsolete?
<smoser> slangasek, where did i have that ?
<smoser> slangasek, i'll be back in ~ 1 hour or so.
<slangasek> smoser: which?
<smoser> ...
<smoser> i'll push a fix for that to that branch
<smoser> you're right on filesystems
<slangasek> smoser: the 'start on filesystems' is in cloud-config-ssh.conf, cloud-disable-ec2-metadata... ok
<smoser> right.
<smoser> thank you for noticing that.
<smoser> ok. slangasek that is pushed now to the lucid branch
<smoser> the one linked there.
<slangasek> smoser: ok, thanks.  can you clarify for me why the previous changelog entries went away when you rebased to 0.5.6 - was that just a casualty of a revert?
<smoser> it was a causualty of .bzr-builddeb
<smoser> and being "native"
<slangasek> smoser: also, is there an upstream tarball available somewhere for use when uploading this?  Otherwise it just ends up as a native package again.
<slangasek> no, I think "being native" is a red herring here
<smoser> the 0.5.5 merge was never done in that branch
<smoser> so i backed to 0.5.4 and then jumpbed forward, just ditching the merge-upstream for 0.5.5
<slangasek> ah
<smoser> merge-upstream moaned that it didn't have the tags for the 0.5.6 version
<smoser> err 0.5.5
<smoser> so it wouldn't let me go to 0.5.6
<slangasek> right
<smoser> i might have those numbers wrong
<smoser> but i just forced it
<smoser> sorry
<smoser> the upstream tarball should be creatable by bzr-builddeb
<smoser> but it is available for download
<smoser> http://smoser.brickies.net/
<smoser> (bad, i know). i'll put it somehwere more official
<smoser> i have to run . i'll check back in in 1 hour.
<slangasek> smoser: oh, you have two references to the same bug # in your changelog - can you fix that (I think maybe you wanted to add 524516 as the second one), add a tag for the release, and I'll sponsor?
<pyrak> Hey guys, we just launched this new thing on openhatch.org where we're letting people tell the community how to get involved in specific open source projects
<pyrak> here's the page for ubuntu: https://openhatch.org/+projects/Ubuntu
<pyrak> we'd love to get some feedback on how this kind of thing could be more useful.  like, are there different questions we should be asking?
#ubuntu-devel 2010-02-20
<smoser> slangasek, done
<smoser> thanks
<cyberix> I'm trying to understand this http://people.canonical.com/~scott/daily-bootcharts/20100219.1-max.png
<cyberix> Why do so many tasks end at the same time?
<cyberix> ah
<cyberix> now I get it
<cyberix> they are processes that continue to run when the system is up
<cyberix> and I should be looking at blue stuff
<tlp> Is there a trivial reason some GTK2 apps will show network places (~/.gvfs mounts) in their file dialogs and others won't? i.e. a compile-time option?
<lifeless> yes, gvfs isn't a kernel mount, so all apps need to be updated to use it.
<tlp> how trivial is that, do you know? It's something I'd be interested in working on, because it's bothered me for years.
<tlp> I figured it'd be a toolkit thing
<tlp> i.e. any GTK2 app would have it inherently
<wgrant> tlp: You need to use a GVFS, a different VFS API, to access GVFS mounts directly.
<jdong> doesn't GVFS also put FUSE mounts in ~/.gvfs anyway, so when you rm -rf a home directory it'll trash all your network shares too ^W^W^W^W^W^W^W^W^W^W^W^ legacy apps can use it
<wgrant> jdong: Yup.
<tlp> I don't understand why even, say, GNOME Terminal doesn't let me pick "Network" in its file dialog
<wgrant> GNOME Terminal has a file dialo!?
<wgrant> +g
<tlp> File->Save Contents
<jdong> I'm guessing save transcript
<wgrant> Ah.
<wgrant> That menu item lies.
<wgrant> It doesn't not have an ellipsis.
<wgrant> Er, "does not".
<tlp> I understand how to get to mounts via ~/.gvfs, but I highly doubt an end user would.
<wgrant> tlp: So, the key is that real GVFS apps don't use ~/.gvfs at all.
<tlp> right. Just seems weird that core GNOME stuff isn't using it already :)
<tlp> jdong: seriously? that's pretty scary.
<jdong> tlp: what, recursion down network shares?
<lifeless> tlp: you have to replace all your file IO
<jdong> tlp: there's a reason why rm is aliased to rm --one-filesystem in my zshrc right now :)
<lifeless> tlp: there is an argument that its basically a bad idea and that they are solving the wrong problem.
<jdong> fortunately the remote system was over a low-bandwidth link AND gvfs sftp is slow :)
<tlp> lifeless: .gvfs is a bad idea, or the GVFS API?
<jdong> the GVFS API is kinda annoying to use IMO...
<jdong> I'd rather wish they did everything over FUSE
<lifeless> tlp: both
<jdong> (then again, the UNIXes where FUSE isn't available/common...)
<lifeless> fuse still has some issues last I heard
<tlp> I've never used it myself. I'm a renegade from a more complex UNIX-like operating system and only recently started caring about out-of-the-box user experiences
<tlp> anyway, seems like a big usability problem
<tlp> jdong: so, here's a question. an rm alias seems like an easy thing to commit to prevent that; any idea why nobody has?
<jdong> tlp: probably because it's confusing behavior to those not expecting rm to be crippled in such a way
<tlp> I didn't even know about ~/.gvfs until last year when someone pointed it out to me. I was using smbfs or something. I'd be pretty pissed if I accidentally nuked a network share.
<tlp> good thing I don't rm my home directory much
<jdong> indeed. Though IMO this still files under the general category of "careful with -f / -r on rm"
<jdong> it's an abnormal usecase to be zapping the home directory all that often.
<tlp> that's true
<jdong> fortunately, the gdm-guest-session setup does not allow any sort of usermounts thanks to apparmor policy.
<jdong> I tried without success in tricking it to rm -rf a mountpoint.a
<tlp> don't we prevent rm /?
<jdong> upstream does.
<jdong> specifically it refuses to recurse starting from /.
<jdong> but you can still use /* and other cute variants to do just as much damage.
<tlp> I don't see much harm in a simple y/n confirmation for that sort of thing
<tlp> few people intend to do that, I think.
<jdong> IMO that's something to take up with coreutils.
<jdong> -f should mean -f.
<jdong> would be mean to scripts to change such a primitive command like rm to include new prompts
<tlp> still trying to figure out how the Ubuntu project is structured (starting by staying in here more often)
<tlp> ah, true
<lifeless> you can turn on prompting
<jdong> lol but then it seems to prompt too much :)
<jdong> either either nag nag nag or *BOOM*
<jdong> at least users always feel that way ;-)
<tlp> I've been using rm -rf so long that I almost forgot -f is supposed to force those things :p
<wgrant> My university aliases rm to rm -i, which means everybody is immediately taught to always use -f, which is sort of bad...
<tlp> yeah. something I learned early on and just never thought about again.
<jdong> yeah, a lot of distros I've used do the same.
<jdong> at least for the root user.
<nigelb> anyone good with python give me a little help with parts of an apport hook?
<nigelb> here's the pastebin: http://pastebin.com/d67f035af
<nigelb> something to do with lines 15 to 20 is causing some issues
<slangasek> nigelb: missing an 'import re'?
<nigelb> slangasek: oh!
<nigelb> now something more seems to go wrong
<nigelb> slangasek: I dont seem to be going into line 20
<nigelb> somewhere I'm doing something wrong
<nigelb> and the file isn't being attached either
<slynux_> hi
<slynux_> i am trying to build a initramfs which can load wireless driver
<slynux_> i tried modprobe iwl3945
<slynux_> but its not activating wlan0
<slynux_> i think due to inability of firmware loading
<slynux_> howto load firmware without udev ?
<hyperair> slynux_: which ubuntu are you using?
<hyperair> slynux_: and what kernel?
<slynux_> 9.10
<slynux_> 2.6.31-14-generic
<hyperair> slynux_: the module is called "iwlagn"
<slynux_> oh
<hyperair> slynux_: and the way to make it be loaded in the initramfs is by adding iwlagn to the bottom of /etc/initramfs-tools/modules
<slynux_> okay
<slynux_> but i cannot find iwlagn in my lsmod o/p
<slynux_> why?
<hyperair> o/p?
<slynux_> output
<hyperair> lsmod | grep iwl
<slynux_> my wireless driver is working when the ubuntu boots up
<slynux_> when udev runs
<slynux_> iwl3945                77212  0
<slynux_> iwlcore               112508  1 iwl3945
<slynux_> mac80211              181236  2 iwl3945,iwlcore
<slynux_> led_class               4096  3 sdhci,iwl3945,iwlcore
<slynux_> cfg80211               93052  3 iwl3945,iwlcore,mac80211
<slynux_> i want it to be activated during initramfs
<slynux_> before udev
<hyperair> why would you want that?
<slynux_> i am trying to implement a wireless LTSP
<syn-ack> wow, is that gonna suck bandwidth wise
<slynux_> still i wanted to do it
<slynux_> there is some wltsp came with windows
<hyperair> but why before udev?
<hyperair> why not after udev in initrams?
<nigelb> when an apport hook is added, I only need to add one line to the debian/rules file.. correct?
<slynux_> i dont want to include udev in intramfs
<slynux_> once network is up i need to chroot to remote box
<nigelb> does this line work "cp debian/rhythmbox.apport debian/rhythmbox/usr/share/apport/package-hooks/source_rhythmbox.py"
<hile> why you want to _remove_ udev from initramfs
<hyperair> slynux_: what's wrong with having udev there anyway?
<slynux_> i need to add udev in initramfs
<slynux_> it will become heavy
<slynux_> i just need to keep it very small
<hile> udev is in initramfs already
<hyperair> initramfs is currently 9.8MB
<hyperair> how much of this is udev?
<slynux_> oh
<slynux_> i though udev was outside
 * hyperair sighs
<slynux_> sorry
<syn-ack> its both
<slynux_> thanks
<hile> anyway the wireless module is useless in initramfs unless you add iwconfig and ifconfig/iproute2 - not sure how big deps these would be
<hile> ok, wireless-tools would add only libiw29 so it's likely fine
<syn-ack> hey, anyone have a rough guess at how much of Ubuntu's code is sent back upstream to Debian?
<hile> I see a wireless ltsp quite useless in most cases, just because wlans suck when you have enough traffic, but for ad-hoc setups it would be nice, maybe
<hile> of course you would still need to have local initramfs, because you can not usually tftpboot wlan adapters (there is no way to configure the wlan to use for booting etc)
<hile> oh he left. I would have first tried running for example 10 normal clients with remote X sessions over wlan and see if it's usable, before wasting time with fully diskless setup...
 * ogra wonders if anyone else is seeing horrible slowness with X since the last upgrade
<ogra> and also a lit of flickering in terminals
<jdub> ogra: mmm, and possibly the source of my rhythmbox/xorg cpu abuse
<jdub> ogra: there's definitely something odd going on in the X stack
<jdub> ogra: intel?
<ogra> xchat takes about 60% CPU here
<ogra> yeah, intel
<ogra> in xchat i see a lot of flickering on the line that separates nicks from typed text ... like there are dots jumping on the line
<ogra> (i already disabled compiz, its definately not composite related)
<SevenMachines> i'm seeing a little bit of terminal flickering, not as bad as it was a few days ago, none of the other problems you mention though
 * ogra downgrades the intel driver and restarts X
<ogra> nope, didnt help
 * ogra downgraades xorg-server too
<ogra> hmm, still broken
<c_korn> I think I also seem some flickering in virtualbox. if this is what you mean: http://abs.getdeb.net/X.avi
<vikkio88> hi guys
<vikkio88> do you have some ideas to create an autocompletition texteditor?
<vikkio88> to create post with bbcode for blog?
<ogra> sigh
<ogra> c_korn, my system is to slow to play a movie, both CPUs are at 100%
<ogra> funnily one is completely taken by evolution-alarm-notify
<ogra> the rest by X and xchat
<c_korn> ogra: oh, well what you would see is the consolte of the update-manager which flickers when a new message is displayed
<ogra> yeah, gnome-terminal behaved similar
<ogra> though that part seems to be fixed with the X downgrade i just did
<ogra> i still see the flickering one the spatrator line in xchat though
<ogra> *on th
<ogra> e
<ogra> ah, killing evo i can at least type again without delay
<wgrant> I've noticed that Evo's been pretty slow the last day or two.
<wgrant> But it's not eating my CPU.
<ogra> i dont think its evos fault but something lower in the stack
<ogra> nothing in any log though
<wgrant> Indeed.
<hile> if it's in gtk-based text widgets, maybe testing with plain xterm would be good idea... problem even there and it's likely server level issue
<ogra> yeah, downgrading to libgtk2.0-0 2.19.5-1ubuntu2 fixes the world \o/
<ogra> its all sebs fault !
<highvoltage> the world!?
 * highvoltage installs now
<uelapeppa> hi
<uelapeppa> how do you create official ISOs?
<t3rm1n4l> hi
<t3rm1n4l> i am trying to activate wlan0 in initramfs
<t3rm1n4l>  when i do modprobe iwl3945
<t3rm1n4l>  it shows error -2
<t3rm1n4l> and says cannot probe the device
<t3rm1n4l> is that problem with firmware loding?
<t3rm1n4l>  i added a hotplug script
<t3rm1n4l>  but it has no subsystem=firmware uevent
<t3rm1n4l> any comments ?
<geser> StevenK: as you offered to help on the OCaml transition: findlib and facile need a rebuild (bug 522363) and camlp5 and havea need a sync (bug 522358)
<ubottu> Launchpad bug 522363 in xml-light "[OCaml 3.11.2 transition][round 2/6] Please rebuild packages involved in OCaml transition" [Undecided,Fix released] https://launchpad.net/bugs/522363
<ubottu> Launchpad bug 522358 in hevea "[OCaml 3.11.2 transition][round 2/6] Please synchronize packages involved in OCaml transition from Debian sid to lucid" [Undecided,Confirmed] https://launchpad.net/bugs/522358
<jdub> ogra: interesting -- thanks
<jdub> ogra: the ol' IZ GTK BUG
<jdub> ogra: hah, that resolves my rhythmbox issue too :-)
<jdub>   * debian/patches/062_client_side_decoration.patch:
<jdub>     - upload the work from Cody Russell on client side decoration to lucid
<jdub> j'accuse!
<azeem> what's about this issue with having "LGPL 2.1 or later" licensed code?
<pochu> azeem: I guess some people are afraid of the FSF releasing a newer version that says something they dislike?
<azeem> right, but first off, the FSF actually vowes to not change the spirit of the license
<azeem> and saying something like "Because seriously, everything should be this way.  None of us should be saying "LGPL 2.1 or later".  Ask a lawyer, even one from the FSF, how much sense it makes to license your software that way." seems unproductive
<melodie_> hello
<melodie_> hi
<melodie_> I came to ask it the devs know about possible improvements around screen detections in the next Ubuntu ? and about the network as well ? (network-manager still the default app ?)
<asac> melodie_: yes nm will still be default
<melodie_> hi asac
<melodie_> do you know if it will get improvements ? (last version I gave up on Ubuntu because it didn't even see my ethernet :/ )
<asac> melodie_: did you have anything in /etc/network/interfaces configured?
<melodie_> what about screen detections ? no new tool coming out to get it configured the good way ?
<asac> if not, its a driver bug and has nothing to do with nm
<asac> anyway out ... getting food and weekend action and so on ... enjoyy
<melodie_> what I can tell you, is that it was just after installing, and that it didn't work whereas before it used to work out of the box. I could connect only with dhclient, whatever I tried. I'm not a /etc/network/interfaces specialist on the other hand
<asac> (dont know about screen detection ... usually everything happens automatically quite well nowadays)
<melodie_> asac, not really. well, I guess I should go back to bugzilla more often ;)
<asac> cant tell then. would need to see the logs and the files. most likely its fixed in lucid
<melodie_> asac, I'll give it a try again when out. thanks asac
<asac> melodie_: give it a try before its out ;) ... otherwise its hard to get things fixed
<asac> at least pop in the live cd
<asac> and check if network is good
<melodie_> asac, allright, I'll try it in virtualbox and will yell if the vbox drivers aren't included. ;-)
<asac> take tomorrows dailies ... http://cdimage.ubuntu.com/daily-live/
<melodie_> asac, ok ! thank you !
<asac> melodie_: virtualbox is not really important
<melodie_> for me it is
<asac> what is important is your main system
<melodie_> that's where I do many tests
<asac> virtualbox usually worked here
<melodie_> at a time I could not get a gui in vbox, without strange tweaks
<asac> if your problem was about virtualbox then its odd because i am sure i would have gotten more complains if it didnt work at all
<melodie_> now I have a Xubuntu in it, but only 800x600 and no way to know how to change it unless I get a xorg.conf from another install
<melodie_> which has also occurred in a real machine several times
<melodie_> the ethernet problem was on my laptop ibm T30
<melodie_> ok I get a tomorrows' daily anyhow.
<melodie_> do you know if is it possible to dd it to a usb pendrive and boot it from there ? I like to save cd-r when I can
<LaserJock> melodie_: I don't think dd will work, usb-creator works to best or unetbootin
<melodie_> hi LaserJock
<melodie_> to use usb-creator you have to have a Ubuntu installed don't you ?
<LaserJock> yeah, or I think Windows
<melodie_> I don't use Windows
<LaserJock> unetbootin is available for most distros
<melodie_> I tried it once, it screwed my menu.lst
<melodie_> never again !
<melodie_> I can have it in Archlinux ! Great !
<melodie_> which one there is the one asac told me about ? http://cdimage.ubuntu.com/daily-live/
<melodie_> which is the latest ? 20th ?
<LaserJock> melodie_: usually there is a link to "current"
<melodie_> LaserJock, ok, thank you
<melodie_> I'm dowloading from the "daily-live" directory now.
<melodie_> do one knows if is there any development done especially for the netbooks ?
<ari-tczew> please sponsor debdiffs for fakesyncs: bug 512430 ; bug 524955 ; bug 524957
<ubottu> Launchpad bug 512430 in geronimo-jpa-3.0-spec "Fake sync geronimo packages (main) from Debian testing (main)" [Undecided,Confirmed] https://launchpad.net/bugs/512430
<ubottu> Launchpad bug 524955 in polkit-qt "Fake sync polkit-qt 0.9.3-1 (main) from Debian testing (main)" [Undecided,Confirmed] https://launchpad.net/bugs/524955
<ubottu> Launchpad bug 524957 in polkit-qt-1 "Fake sync polkit-qt-1 0.95.1-1 (main) from Debian testing (main)" [Undecided,Confirmed] https://launchpad.net/bugs/524957
<melodie_> LaserJock, do you know if there are specific components at Ubuntu, that one should install when having a notebook Samsung NC10 ? Or if some special developments are led ? (kernels for notebooks, or ?)
<asac> melodie_: for netbooks you should install une
<asac> melodie_: http://cdimage.ubuntu.com/ubuntu-netbook/daily-live/
<LaserJock> melodie_: you can look at the "Hardware Specific Help" section of https://help.ubuntu.com/community/UbuntuNetbookEdition
<kees> james_w: when you get a moment, can you look at bug 524980?  if that patch is ok, I'd like to get it in; this error drives me crazy.  :)
<ubottu> Launchpad bug 524980 in lazr.restfulclient "does not retry temporary failures" [Undecided,New] https://launchpad.net/bugs/524980
<james_w> kees: nicely phrased :-)
<james_w> I have the same code externally
<kees> heh
<kees> yeah, I have the same code externally in lots of different scripts.  :)
<james_w> I'd like to get leonard's opinion though
<kees> okay
<kees> yeah, I figured it should get a little review
<asac> kees: that patch is bad ;)
<asac> 1st. using while True: is lazy habit imo ;)
<asac> 2nd. you have an endless loop there, no?
<kees> asac: well, I suppose it could be better, but it's not endless, we either break or reduce retries.
<asac> run a s/retires/retries/
<asac> ;)
<kees> asac: I wanted to avoid a needless trailing sleep(1)
<asac> kees: you dont reduce retries, but retires ;)
<kees> oop, but yeah, typo is ugly
<asac> which probably never retires ;)
<asac> cheers
 * kees updates patch
<james_w> kees: fwiw, you've probably discovered this already, but just that isn't really sufficient for unattended jobs
<kees> james_w: oh? it seems to work well enough for mine jobs?
<kees> s/mine/my
<james_w> you often need to back of more than that
<james_w> back off
<james_w> if it's in cron and will try again an hour later then you are probably fine
<james_w> but there are often storms that go on longer than the ~30s that will retry for
<kees> hrm, I hadn't noticed anything that got that crazy, but I think stalling for 30m in a client call isn't probably good.
<james_w> no
<james_w> so if it's appropriate you may want to do it at a higher level
<kees> yeah.  but this should catch, at least for me, the bulk of the glitches
<james_w> yeah
<james_w> I just did the same thing hoping it would solve more than it ended up doing
<james_w> lets see what Leonard says, I'd rather not stick it in if clients can't rely on it being there
<james_w> oh, and "ValueError: No json object could be decoded" means that haproxy can't reach an appserver, a couple of bugs mean you get a silly error
<kees> kirkland: hrm, does qemu-nbd hang for you?  I can't get it to connect
<melodie_> hi again
<melodie_> I think I ought to post a bug report, but I don't know against what I should post it : Xorg ? what is the configuration tool for resolution ? I installed in vbox, and did search a simple solution within Ubuntu to fix the resolution, but found none. Ended with using a foreign xorg.conf to fix it.
<melodie_> http://pastebin.ubuntu.com/380521/
<melodie_> what should I do to help improve this ? It's a problem I also met before, on a real install
<melodie_> I feel that there is really something missing...
<LaserJock> melodie_: is this on Lucid or a stable release?
<melodie_> LaserJock, on Xubuntu Karmic, and last year same happened in Ubuntu Karmic on an install on one of my machines
<melodie_> LaserJock, maybe you are not interested in bugs about Karmic for now ?
<melodie_> LaserJock, one more among many ? -> https://launchpad.net/+search?field.text=xorg+resolution+Karmic&field.actions.search=Search
<melodie_> :o
<bigon> has something got decided about the fakesync version scheme?
<bigon> cjwatson: ^?
<melodie_> I try to install Lucid in a pendrive : does it need a ext2 partition to work out ?
<melodie_> (with usb-creator-gtk)
<bigon> nobody for the fakesync versioning scheme?
<james_w> bigon: you've read the mailing list discussion?
<bigon> yeah but I'm not sure something have been really decided :p
<james_w> well, you have all the information that I know of then
<bigon> well I will upload my pkg with -Xfakesync1 then
<slangasek> bigon: the tools today won't know how to handle that
<bigon> :/ too late
<slangasek> I wouldn't recommend using new package version schemes before there's a clear consensus and a committment to implementing the tool support
<crimsun> slangasek: do you want me to leave bug 283217 open for the thinkpads?
<ubottu> Launchpad bug 283217 in pulseaudio "Volume HotKey shows OSD, doesn't change mixer level" [Medium,Incomplete] https://launchpad.net/bugs/283217
<crimsun> otherwise I'm inclined to close it for the OR's hw
<Laibsch> Is mvo the only specialist on update-manager?  I'm about to update my hardy LAN server, but it picked hardy->intrepid instead of hardy-lucid.  I did some initial triage together with mvo and reported a ticket in LP.  Since then I've not heard back from him even though I pinged him a couple of times.  I finally want to go ahead with the upgrade, but that will then be the end of further data collection.
<slangasek> crimsun: eh, why would you use that bug to track anything about thinkpads when there's no mention at all of thinkpads in it?
<lifeless> Laibsch: he is the primary author
<lifeless> its just python though, so anyone that can program can debug it reasonably easily
<Laibsch> who is econdary author?
<Laibsch> ;-)
<Laibsch> +s
<Laibsch> lifeless: computers are just 0s and 1s, anybody who can count can debug them ;-)
<crimsun> slangasek: given the title, I did not know whether you intended to track thinkpad symptoms there
<crimsun> slangasek: anyhow, I'll close it, thanks.
<slangasek> crimsun: yes, please close it
<lifeless> I wasn't intending to be sarcastic
<lifeless> I feel like you were though in your response; is that accurate?
 * hyperair finds python pretty hard to debug
<hyperair> is there some gdb for python?
<lifeless> hyperair: yes; pdb and also gdb can do python
<hyperair> oh that's cool
<hyperair> lifeless: gdb doesn't appear to do python. says it's not an executable format
<slangasek> you either need to run 'gdb python' and then pass the script as an argument to 'run', or attach to the process by pid
<melodie_> is 6 Go enough for Lucid, in a Virtual machine, please ?
<slangasek> melodie_: it should be, yes
<slangasek> melodie_: you may find #ubuntu+1 is a better forum for asking such questions
<melodie_> thks slangasek, what is that chan dedicated to ?
<lifeless> hyperair: http://wiki.python.org/moin/DebuggingWithGdb
<slangasek> melodie_: #ubuntu+1 is for support of the current development release
<melodie_> slangasek, I'll also look for the dedicated bug tracker
<slangasek> melodie_: sorry, dedicated bug tracker for what?
<melodie_> for Lucid
<melodie_> sorry I was disconnected :-
<slangasek> melodie_: https://help.ubuntu.com/community/ReportingBugs
<melodie_> thank you ! theses pages can look like a real jungle when you don't know where the right one is
<melodie_> no
<melodie_> I meant the bug tracker dedicated to Lucid. there I have gone allready, I am logged in launchpad too
<Laibsch> If you don't take some time to read the chances are that you will not write a good bug report.  The effect of that will be that you will take up valuable developer time that could have otherwise gone into fixing a bug.
<Laibsch> Please make sure you write the best possible bug report you can so that the devs can actually fix it
<Laibsch> You may find out that your "bug" is not a bug after all or has a known workaround
<slangasek> melodie_: Launchpad *is* our bug tracker
<lifeless> melodie_: bugs.launchpad.net/ubuntu is the dedicated bug tracker
<lifeless> melodie_: its big because Ubuntu is big.
<melodie_> I know that
<melodie_> I used it at it's very beginning
<Laibsch> melodie_: this isn't the right place for you to ask for support, please use #ubuntu+1 or #ubuntu-bugs.  Please be sure to read the wiki pages pointed out to you. You will find all the answers you need.
<melodie_> Laibsch, I am logged there, I was just asking where the dev's are looking for bugs to fix
<lifeless> melodie_: bugs.launchpad.net/ubuntu
<melodie_> in the whole place ?
 * Laibsch is getting a certain feeling
<lifeless> melodie_: yes
<melodie_> lifeless, thank you
<Dunkirk> Is there a web site / way to view the patches that have been applied to packages in Lucid. (I'm looking to see if a particular has been fixed since Karmic.)
<lifeless> Dunkirk: patches.ubuntu.com
<melodie_> what is todays Lucid ? alpha ? alpha 1 ?
<melodie_> or more ? I want to report this : http://pastebin.archlinux.fr/378262
<sherr> melodie_: Lucid questions in #ubuntu+1
<melodie_> allright thanks
<melodie_> bye
#ubuntu-devel 2010-02-21
<jdong> who do I beg for new bcmwl-kernel-source crack?
<jdong> oh never mind... I am 5 days late to the party.
<coolrave143> hi
<coolrave143> i am trying to add iwconfig to initramfs
<coolrave143> but it doesnt work
<coolrave143> i tried to build it using static option
<coolrave143> still i get error
<coolrave143> /bin/sh: iwconfig: not found
<slangasek> coolrave143: please see #ubuntu for support
<ubuntu> bugs
<ccheney> can we use deb v3 yet?
<sistpoty> ccheney: yes
<ccheney> sistpoty: ok
<sistpoty> (actually uploaded a v3 package today ;))
<ccheney> OOo just switched in debian today
<ccheney> sistpoty: is lucid the first ubuntu version to support it?
<ccheney> i'm wondering due to sometimes doing backports for OOo if i need to make sure to special case anything for them
<sistpoty> ccheney: afaict there's (limited) support in karmic already, but lp couldn't handle it back then... you'd need to check dpkg changelogs for what works and what doesn't though
<ccheney> sistpoty: ok
<sistpoty> persia might now more details
<persia> There's a couple oddities with that.  LP now has a backported dpkg that can support 3.0, but it also appears to have filters that block uploads of 3.0 packages to releases prior to lucid.
<persia> I don't know all the details, but that's what I've garnered from backscroll.
<persia> (and if more bugs are found in dpkg 3.0-handling, someone needs to merge, backport, etc., so some packages may be wonky)
<ccheney> ok
<persia> I *think* the best option is to try to convert packages to 3.0, and push them.  If they don't work, try against dak/Debian (you may have to hunt someone if you don't want to set this up locally).  If they don't work there, get it fixed, and get the fixes into lucid.
<persia> I understand that the servers that run Launchpad are supposed to upgrade to lucid at some point (perhaps not right after release), so this saves later backport messiness (or should do so, at least)
<ccheney> can you convert between debian versions in the same upstream version number?
<ccheney> it seems debian is doing this for OOo between 3.2.0-1 and 3.2.0-2, but he hasn't actually uploaded -2 yet
<persia> ccheney: I believe the only restriction on source format changes is that if your new .dsc references some original file it must carry the same checksums.
<persia> So, for instance, if you have foo.orig.tar.gz, you need to use the same foo.orig.tar.gz, and not re-upload it.
<persia> But otherwise, it should all be fair game (for the same reasons you can do things like convert from native to non-native or non-native to native with such a version)
<persia> (but I could be wrong: I haven't actually ever played with archive acceptance code)
<aburch> ccheney: You can.
<ccheney> aburch: ok
<zubin71> hi, im working on a small script which can helps programmers work at the linux terminal. its a work in progress and its hosted at code.google.com/p/pyautorun
<zubin71> id like to have the script i wrote added to the ubuntu repository; what should i do?
<persia> !newpackages
<ubottu> The packaging guide is at http://wiki.ubuntu.com/PackagingGuide - See https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages for information on getting a package integrated into Ubuntu - Other developer resources are at https://wiki.ubuntu.com/UbuntuDevelopment - See also !backports
<persia> zubin71: The NewPackages link there talks about the process, but we've just passed FeatureFreeze for the current release cycle.
<persia> At this point, your best bet would be to work at getting it included in Debian, and Ubuntu will pull it from there to include it in the next release.
<zubin71> persia : is getting a package accepted into debian similar to the procedure followed in ubuntu?
<persia> zubin71: At a high-level, yes.  At a low-level not so much.
<zubin71> persia : ok... thankx a lot! :)
<persia> So, one still needs to have it packaged (either oneself, or by someone else), and get it reviewed, and sponsored by a developer (unless it is packaged by a developer who uploads themselves).
<zubin71> i see...
<persia> But one files a different kind of bug in a different bug tracker to request it, and uses a different upload site to get reviews, etc.
<zubin71> hmm, so in order to get it reviewed by a developer should i just upload the project smwhere and post the link to the mailing list?
<zubin71> would that do?
<zubin71> !backports
<ubottu> 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
<persia> zubin71: There may be better documentation (you might want to ask in #debian), but http://www.debian.org/devel/wnpp/ may provide some hints.
<zubin71> sure, will do...
<zubin71> persia : thank you
<persia> zubin71: Good luck.
<wgrant> persia, ccheney: LP supports 3.0 (quilt) and 3.0 (native) in Lucid fine, with all current known fixes. If somebody manages to get the few remaining issues fixed in karmic-updates, we can permit it for Karmic too. And yes, you can change format at any time, as long as you don't try to change a file's content.
<persia> wgrant: What are the remaining issues with Karmic?  Daviey wanted to upload something to a Karmic PPA earlier, and was unhappy that it was blocked.
<wgrant> persia: There is at least that quilt compatibility issue that was just fixed in hardy-cat, but IIRC there are others too.
<wgrant> I'm not sure of the details, though.
<persia> Oh, so someone would have to backport dpkg to fix the various 3.0-related bugs?
<persia> Would it be possible to permit uploads to Karmic with the recent hardy-cat changes, and have them end up as potential build-failures if the target archive didn't have a dpkg that supported whatever 3.0 features were required?
<wgrant> At least the patches would have to be backported, yes.
<wgrant> That would indeed work.
<wgrant> Since Karmic's should be good for most packages, and the chroot's dpkg should be upgraded to the target's anyway.
<wgrant> Upgraded before the unpack, that is.
<wgrant> So maybe we should just go ahead and enable it.
<persia> And whatever happens to be supported will work, and what doesn't can be made to work by pushing a fixed dpkg.
<persia> Does that need a bug, or is it something where you can just turn off the rejection filter easily?
<wgrant> Just needs somebody to execute a trivial INSERT on the production DB. A poke from a distro person in the direction of bigjools would achieve it pretty quickly.
<wgrant> (the filter is just a (series, source format) whitelist table in the DB)
<persia> Oh, that's easy.  Since bigjools and Daviey (mostly) share a timezone, I'll pass info around :)
<lifeless> anyone run into 'GLib-WARNING gwpudi_r failed due to unknown user id(0)
<lifeless> on boot
<lifeless> bah, getpwuid_r I mean
<lifeless> and boot splash staying up, no login prompt
<persia> Just to make sure, root has uid 0 on that system, right?
<lifeless> I sure hope so
<lifeless> its my laptop
<lifeless> also getty not running at this point, so can't debug
<lifeless> also appears to be a heisenbug ><
<coolrave143> hi
<coolrave143> may i know which option to ./configure is used to specify custom lib path
<coolrave143> --prefix would do ?
<persia> coolrave143: You would probably do better asking in an autotools forum.  We generally receive configure scripts from various upstreams, and simply use whatever is documented in the upstream build instructions.
<lifeless> [and we don't need custom lib paths]
<stefanlsd> coolrave143: ./configure --help may help
<coolrave143> okay
<persia> lifeless: Well, it depends on the defaults :)  I've seen several packages that needed customised lib paths to follow FHS :)
<chirag> hi
<chirag> join
<chirag> quit
<dan4dm> hi - lintian stuff, I'm getting "debian-watch-file-in-native-package" but the package is not 'native' - the .orig.tar.gz has no watch file in it - any suggestions?
<azeem_> dan4dm: ask in #ubuntu-motu
<dan4dm> azeem_: k thanks
 * persia isn't sure why this is specifically a -motu question, but it's being answered there, so it's not worth dicussing here in parallel.
<azeem_> persia: sorry, I thought general packaging questions are more on-topic in #ubuntu-motu then here
<azeem_> than*
<persia> Used to be that way, but not anymore.  With the new plans for archive reorganisation, *all* the development teams are expected to participate in training new folk.
<persia> So it's precisely the same amount on topic.
<azeem_> ok, thanks
<persia> (although people are more likely to get help from teams working in their area, so kubuntu-devel for KDE stuff, and ubuntu-desktop for GNOME stuff and xubuntu-devel for XFCE stuff, and ubuntustudio-devel for pro audio/video/graphics stuff, etc.)
<Damascene> empathy is broken in Lucid
<persia> Damascene: Have you filed a bug?  If not, please do.  If you think the issue may be local, please ask in #ubuntu+1
<Damascene> it's working now after update
<Damascene> I mean empathy
 * iulian is looking for an SRU member to unsubscribe motu-sru from bug#525116.
<ion> bryceh: xserver-xorg-video-all â xserver-xorg-video-nouveau â linux-backports-modules-nouveau-lucid-generic â linux-backports-modules-nouveau-2.6.32-14-generic â linux-image-2.6.32-14-generic dependency chain causes my box to have a -generic image in addition to the -generic-pae one i actually want to use. xserver-xorg-video-nouveau should probably have an alternative dependency on linux-backports-modules-nouveau-lucid-generic-pae.
<bdrung> hi, persia told me to complain about the main sponsors queue. there are currently 122 bug in the queue. so every core-dev should pick at least one. i have done my job and the universe queue is empty.
 * persia only redirected from -motu to here
<persia> bdrung: What did you do with the cowsay patch that didn't actually fix the bug?
<persia> Also, kudos to the kubuntu and server teams for having a relatively small set of bugs in queue.
<bdrung> persia: subscribed ubuntu-reviewers (that's the team for converting patches into debdiffs)
<persia> bdrung: You noticed that it had just been sent from reviewers to sponsors two days ago?
<LaserJock> main sponsoring is tricky because there's quite a bit more sense of "ownership"
<bdrung> persia: ups, no. didn't noticed that.
<persia> bdrung: Maybe you just want to fix it :)
<bdrung> LaserJock: is there a way for getting the "owner" of the package?
<LaserJock> bdrung: there's a wiki page somewhere that kinda outlines some of it
<LaserJock> but a lot of packages fall through the cracks (i.e. there's not really a defined owner or a very vague one)
<persia> Note that the sense that there is a sense of "ownership" is as much of a problem as anything else.  Heaps of packages *don't* have an "owner".
<persia> (and I've yet to encounter a package with an owner that didn't say "Thank you" for a fix, or even an upload (except in cases where there is a really complex upload process like the installer).
 * micahg wishes someone would kick thunderbird out of NEW
<LaserJock> I think there's probably a class of packages that are in Main because they are a dep of some package that people really care about, but the dep is not really as interesting
 * bdrung wonders how long yofrankie will stay in NEW.
<LaserJock> I found the risk of sponsorship in Main was also a decent bit higher
<LaserJock> i.e. screwing up a Universe upload is often much less of a problem than say taking out gtk or xorg
<Laibsch> There are ubuntu-10.04-beta-1 and ubuntu-lucid-alpha-1.  I guess that inconsistent naming got me a bit confused.  Is there a deeper meaning for using the numbers in one case and the release name in the other?
 * Laibsch is talking about milestones in Launchpad
<Laibsch> Alpha uses numbers, beta the release name and the final release again uses numbers.  Is that just coincidence?
<LaserJock> could be but I'd guess it reflects the changing nature of the releases
<LaserJock> the number version is the "official" naming scheme, whereas we use the codename more during development
<EagleScreen> users really need a ncurses version of jockey
<EagleScreen> overall when the graphics card is the matter
<dupondje> asac: thx for thunderbird 3 :)
<sebner> dupondje: I'd thank micahg ;)
<micahg> what did I do?
<nigelb> micahg: TB3
<micahg> nigelb: ah
<dupondje> yea its cool :)
<dupondje> finally added
<micahg> did someone finally release it from the NEW queue?
<dupondje> seems so :P
<dupondje> 3.0.1 is out btw :p
<dupondje> rofl
<micahg> dupondje: I know
<micahg> and 3.0.2 is coming soon
<dupondje> will you update it ? or will 3.0.0 stay the version in Lucid ?
<micahg> dupondje: it'll be updated ...just not sure when
<sebner> dupondje: one step after another is the motto here ;)
<dupondje> yea true :)
<dupondje> i'm already happy 3.0 is in lucid
<dupondje> it was just a question ;
<nigelb> micahg: in case I forget, thanks for the great work on TB :)
<micahg> nigelb: you're welcome :)
<dupondje> but seems there a some issues :(
<dupondje> closing thunderbird, but doesn't seem to get killed .. :s
<micahg> hmmm...I get that occasionally
<dupondje> now it works :P strange
<sebner> dupondje: let's hope for 3.0.x then :D
<dupondje> 138 bugs fixed in 3.0.1 :p
<micahg> dupondje: upload is ready whenever asac wants to release it :)
<cjwatson> Laibsch: the difference is intentional - the intent is to use the codename through the alpha period (so that people don't get the impression that it's more solid than it is), and start using the numbers from beta.
<cjwatson> Laibsch: so it's Lucid Alpha 1 but Ubuntu 10.04 Beta 1 - of course some confusion is to be expected but that's the standardised naming, since hoary/breezy or thereabouts
<Laibsch> OK
<dupondje> micahg: so we need to slap asac  ? ;)
<Laibsch> cjwatson: thanks for clarifying. kind of confusing IMHO, but not a real issue.  I was just curious.
<cjwatson> cf. the reason Debian uses codenames
<micahg> dupondje: no, he has his own timetable :)
<lifeless> cjwatson: why does debian use codenames?
<cjwatson> http://www.debian.org/doc/manuals/project-history/ch-detailed.en.html#s4.1
<cjwatson> the bit about the abortive Debian 1.0 non-release
<lifeless> cjwatson: that talks about official cd rom image
<lifeless> s
<dupondje> micahg: you know if there is a ppa for thunderbird 3.0.1 / 3.0.2 ? mozilla-daily is to daily imo :)
<lifeless> cjwatson: not about adoption of codenames; later on they are introduced with no explanation.
<lifeless> cjwatson: I think you're saying 'after confusing a cd rom printer, Debian started getting codenames printed until releases happen'.
<cjwatson> *shrug* that incident was the cause anyway
<lifeless> thanks
<cjwatson> even if it's not documented in the particular history I found :)
<lifeless> I appreciate the pointer :>
<micahg> dupondje: not yet, but soon
<dupondje> creating one ? /P
<micahg> dupondje: soon
<tjaalton> how to find out why a package has been removed from the archive?
<c_korn> tjaalton: search for the package launchpad.
<tjaalton> c_korn: no bugs filed against it
<cjwatson> if you look in the publishing history there'll be a removal comment from the archive admin who did it
<tjaalton> oh
<tjaalton> "mass removal of old and unpopular packages"
<tjaalton> right :)
<fale> in lucid, xserver-xorg-video-geode reccomends xserver-xorg-video-cyrix and xserver-xorg-video-nsc but they are not in the repo :(
<c_korn> lol, what package was it ?
<tjaalton> c_korn: vdr-plugin-skinsoppalusikka, and I admit that it hasn't changed since hardy
<tjaalton> in ubuntu anyway
<tjaalton> fale: file a bug
<tjaalton> fale: preferably in the debian bugtracker
<c_korn> I wonder how many packages were affected by this mass removal
<fale> tjaalton: in debian? :|
<tjaalton> fale: it was synced from there. having those recommends doesn't break anything though
<fale> I see
<persia> tjaalton: https://lists.ubuntu.com/archives/ubuntu-motu/2009-December/006412.html was the discussion about it.
<persia> tjaalton: If you want to restore one, pull the source from an earlier release, get it updated to match lucid standards, and file an FFe citing a regression.
<tjaalton> just upgraded my vdr box to lucid, and was wondering if I should just let the packages be synced from debian. most of the people are using 3rd party packages anyway, and I'm not doing a proper job keeping up with debian or e-tobi
<tjaalton> persia: well, I don't think it's worth it
<tjaalton> just was surprised to see it gone
<mdz> has anyone else seen bug 522067?
<ubottu> Launchpad bug 522067 in ca-certificates "Equifax_Secure_Global_eBusiness_CA.pem unexpectedly disabled" [Undecided,New] https://launchpad.net/bugs/522067
<fale> tjaalton: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=568516
<ubottu> Debian bug 568516 in xserver-xorg-video-geode "xserver-xorg-video-geode: Recommends inexistant packages xserver-xorg-video-cyrix, xserver-xorg-video-nsc" [Minor,Open]
<tjaalton> fale: thanks
<fale> tjaalton: ;)
<fale> in fedora main and universe have been unified some time ago... is planned something similar for ubuntu too?
<cjwatson> fale: http://wiki.ubuntu.com/ArchiveReorganisation
<cjwatson> (short answer: yes, it's just taking a while)
<fale> cjwatson: awesome :) thankyou for the url
<sebner> cjwatson: good feeling being back from holidays, hmm? *hrhr* :)
#ubuntu-devel 2011-02-14
<bcurtiswx> whats the easiest way to get what functions are called when performing an action in a program
<bcurtiswx> say i open a new IM window in empathy, how do I find out what functions are called ?
<penguin42> bcurtiswx: You trace it back or forward from something that you know must have happened
<bcurtiswx> penguin42, so keep strace open, wait for it to stop then perform the action?
<penguin42> bcurtiswx: So if it was a menu item that triggered it you'd look for the menu code and what ever registered the action for it; or you could go the other way, you could set a breakpoint at some function in gnome you know must have got called - e.g. whatever opens a new window
<penguin42> bcurtiswx: strace is too low level really
<penguin42> bcurtiswx: gdb and breakpoint on a function you expect to get called and then do a backtrace
<bcurtiswx> OK
<bcurtiswx> just 'break' in a c file ?
<penguin42> yeh
<pitti> Good morning
<a3Dman> good morning
<TheMuso> Hey pitti.
<pitti> hey TheMuso, how are you?
<TheMuso> pitti: Well thanks, yourself?
<pitti> TheMuso: pretty well, thanks!
<dholbach> good morning
<didrocks> good morning
<dholbach> salut didrocks
<didrocks> hey dholbach
<geser> pitti: Hi, as you dealt with hal in the past, is disabling the v4l code the right fix for the current hal FTBFS? (http://launchpadlibrarian.net/63796245/buildlog_ubuntu-natty-i386.hal_0.5.14-5_FAILEDTOBUILD.txt.gz)
<pitti> geser: I filed bug 716275; if that is easy to do, I'd prefer that
<ubottu> Launchpad bug 716275 in linux (Ubuntu) "Please ship /usr/include/linux/videodev.h" [Undecided,New] https://launchpad.net/bugs/716275
<pitti> geser: if not, I'd add a patch upstream to check if it is available and disable it in configure if not, and ask mbiebl to cherrypick it
<geser> ok
<alkisg> I've attached a debdiff for natty in LP bug #552404, is there anything else I need to do? The https://wiki.ubuntu.com/StableReleaseUpdates wiki page doesn't apply for development releases, right?
<ubottu> Launchpad bug 552404 in dbus (Ubuntu) "dbus fails to be configured in chroots" [Medium,Confirmed] https://launchpad.net/bugs/552404
<alkisg> So I can just re-subscribe ubuntu-sponsors?
<persia> alkisg, Yes.  The sponsor will upload, and then the SRU process will resume.  Do you need something for maverick as well?
<alkisg> persia: yes, but I don't have a maverick installation available for testing
<persia> My understanding of lucid SRU is that there is an expectation of fix in natty and maverick first.
<persia> alkisg, It's a chroot bug, right?  Do you have disk space to create a maverick chroot?
<RAOF> pitti: /usr/include/linux/videodev.h is the header for the V4L API, which is entirely removed in 2.6.38 - we don't want to ship a header for code that can't work on Natty, do we?
<alkisg> persia: I guess I could ask someone over in #ltsp to try it in maverick, to save me the time of creating a maverick chroot, since I won't ever be using maverick...
<persia> alkisg, I've requested nomination for each release, which should make it easier to follow the correct status of SRU.  Needs someone to approve the nominations, but the sponsor will probably do that as well.
<alkisg> Thank you :)
<pitti> RAOF: ah, ok, good to know
<persia> alkisg, Good luck!
<pitti> RAOF: I'll patch hal upstream then
<RAOF> pitti: The correct response is to port to V4L2 or, at a pinch, just disable V4L support.
<RAOF> Given hal's tremendous utility, I'd guess disabling V4L support is the winning move :)
<persia> Are there no devices that have V4L support, but not V4L2 support?
<RAOF> persia: Not anymore, no.
<pitti> RAOF: absolutely
<persia> Cool!
<RAOF> Well, not with 2.6.38, at least, because it doesn't support V4L at all :)
<persia> heh.
<RAOF> So there might now be some *unsupported* devices, but I don't know of any offhand.
<pitti> geser: ok, fixed upstream; I'll talk to Michael now
<ev> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: open | 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 | Current Friendly Patch Pilots: ev
 * dholbach hugs ev
<dholbach> :-D
<ev> google calendar ftw
<apw> cjwatson, have you heard of any plymouth not working issues recently?  for example: bug #718044
<ubottu> Launchpad bug 718044 in plymouth (Ubuntu) "[Natty] New plymouth does not get loaded" [Undecided,Confirmed] https://launchpad.net/bugs/718044
<cjwatson> apw: nothing new
<cjwatson> apw: the last several updates to plymouth weren't mine, though
<cjwatson> apw: ask soren
<apw> cjwatson, will do thanks
<soren> whuh?
<soren> Oh, crap.
<apw> soren, there is a bug about the latest plymouth affecting some people
<apw> actaully ubuntu15 and up
<udienz> cjwatson, is see in MoM that adduser need to merge, but an changelog says only undating translations. is aduser will be merge this time?
<soren> ubuntu15 was  bit of a bust, but ubuntu16 should be fine.
<soren> Darn it.
<soren> I'm on it.
<pitti> geser: pushed fix to Debian's hal svn; will wait for Michael to review/upload, though
<cjwatson> udienz: we're after Debian import freeze, so merges are not a priority.  Is there a particular reason why we should pay attention to this merge?
<apw> soren, there seems to be be little in the way of changes from the ubuntu14 which was claimed as working ... odd
<cjwatson> udienz: the big merge push is in the first half of the release cycle, i.e. not now
<udienz> cjwatson: ah ok.  i think is not, because only updating translation from debian.
<lool> Ah
<cjwatson> udienz: so just leave it, it'll happen in natty+1
<lool> cjwatson: I've just seen util-linux gained armhf support in Debian and decided to merge it; in the merge, I ended up removing a lot of delta that I think we don't need anymore; do you mind these changes at this point?  Maybe it would be best if these got peer reviewed, I've pushed them as UNRELEASED to the UDD branch
<lool> armhf support would be trivial to add on top of the Ubuntu package, but heck, I've merged it now  :-)
<cjwatson> lool: what sort of things?
<lool> cjwatson: upgrade snippets mostly
<cjwatson> from pre-lucid?
<lool> or diff which didn't add any value to us
<lool> cjwatson: yes
<cjwatson> I don't really care if we drop pre-lucid upgrade stuff
<lool> http://paste.ubuntu.com/566915/
<cjwatson> the stuff listed on https://code.launchpad.net/~ubuntu-branches/ubuntu/natty/util-linux/natty seems generally fine
<lool> cjwatson: I usually review the full debian -> ubuntu diff when documenting remaining changes; the longer it is, the more painful for me
<lool> that's usually why I remove this stuff when I can, or to make maintainer scripts more readable
<cjwatson> sure
<soren> apw: Yeah. /me investigates
<lool> cjwatson: Ok; will give it some testing now, and upload; thanks
<apw> soren, the linked internally bug for the kernel seems to be reporting grub2 showing corrupted display ... so there may be a grub2 connection in part
<cjwatson> none of that has changed recently
<apw> cjwatson, yeah, the description is very hard to understand, i have requested much clarification on the linux bug
<cjwatson> certainly not as recently as the plymouth changes mentioned
<GunnarHj> ev: Hi Evan, do you have time to sponsor a couple of MPs? Both are linked to from https://launchpad.net/bugs/666565
<ubottu> Ubuntu bug 666565 in language-selector (Ubuntu) ""utf8" charmap in locale name is wrong" [Undecided,In progress]
<ev> GunnarHj: I'll have a look
<GunnarHj> ev: Great!
<sivang> hi all
<sivang> what's the relationship between Ubuntu and Linaro?
<sivang> (ubuntu-mobile is closed and said to ask here)
<persia> sivang: Complex :)
<sivang> persia: complex?
<sivang> persia: it is for armel yes?
<persia> So, a number of folks involved in Linaro are also involved in Ubuntu.
<sivang> does it use apt?
<persia> Linaro has some goals (see www.linaro.org), and tries to accomplish them within Ubuntu, releasing things based on Ubuntu.
<persia> So, from an Ubuntu perspective, Linaro just happens to be another project some folk are involved in.
<persia> From a Linaro perspective (I'm guessing), Ubuntu is distribution project that is one of the targets for their efforts.
<persia> Ubuntu supports armel, and tends to select the Linaro branches of tools to do so, because those tend to have the best performance on armel.
<persia> But I don't believe there exists any single interface, or anything, which is why I say "complex".
<sivang> so when I do linaro stuff I work .deb and can use ubuntun repos?
<persia> Also, that's *completely* unrelated to ubuntu-mobile.  ubuntu-mobile was part of an effort to make Ubuntu better for highly mobile and embedded uses.  The consensus seemed to be that as the devices got better, it was more interesting to just deliver normal Ubuntu, than to try to make a special software stack.
<persia> You'd do better to ask the linaro folk, but I believe so.
<soren> apw: I think it
<soren> s all me, actually.
<soren> apw: I don't understand why at all, though.
<soren> apw: the avoid-sigpipe patch causes it.
<soren> apw: If I revert that, it works again
<sivang> persia: thanks, makes sense.
<soren> apw: It just don't understand. write(a,b,c) ought to be the same as send(a,b,c,0), but even that substitution causes it to fail.
<cjwatson> soren: is 'a' a socket fd?
<soren> cjwatson: Let's pretend the answer is "no".
<soren> cjwatson: Just for giggles, let's say it's a pipe.
<cjwatson> you can only use send() on sockets
<soren> Ah.
<soren> man send(2) is rather misleading, then.
<soren> Darn it.
<cjwatson> depends how you look at it
<cjwatson> it does start "send a message on a socket"
<soren> cjwatson: Is there any way I can get write() call to not SIGPIPE if the remote end of a pipe is closed?
<cjwatson> I think "The only difference between send() and write(2)" is intended to be read as "(for sockets)"
<soren> cjwatson: I thought changing it to send and passing MSG_NOSIGNAL would do the trick.
<soren> And certainly it did in my tests, but they were using actual sockets :-/
<cjwatson> I'm surprised it isn't a socket, actually.  ply_boot_client_connect calls ply_connect_to_unix_socket
<soren> Alternatively, some way to reliably determine if an fd is a socket.
<soren> I'm sure it is.
<soren> It's probably just that other things are using the same routine with non-sockets.
<cjwatson> ah
<soren> ...which I hadn't expected, tbh.
<cjwatson> yes, src/client/plymouth.c calls ply_open_unidirectional_pipe
<cjwatson> and there are a couple of other calls
<cjwatson> you probably get EBADF from send - you could just check for that and fall back to write
<cjwatson> that would be OK
<cjwatson> actually, you get ENOTSOCK
<cjwatson> which is pretty clear
<soren> Heh.
<soren> cjwatson: Yeah, that's a good idea. I'll try that.
<soren> cjwatson: So if this were a pipe, the only way to avoid being SIGPIPE'd is to flush the fd first and see if it's closed?
 * soren reboots to check this new patch
<soren> That seems to have done the trick.
<cjwatson> soren: I guess so (or to ignore SIGPIPE, of course).  The pipe uses are all internal to plymouth though, so I don't think we need to worry about that
<soren> cjwatson: Sure, I was just thinkin more gnerally.
<persia> geser, DMB meeting?
<PetrHH> Hello
<PetrHH> I'm working on packaging my app to deb packages
<PetrHH> but have no idea how to create menu entry after install
<PetrHH> could anybody send me link to the how to? I'm not so successful with google
<PetrHH> thank you
<soren> PetrHH: Look at the .desktop files in /usr/share/applications
<PetrHH> soren, Thank you!
<soren> apw: Plymouth fix uploaded. Thanks for pointing it out. I've been watching the new bugs for plymouth, but it looks this this was filed as "confirmed" from the start.
<soren> cjwatson: Thanks for your help on that, by the way.
<cjwatson> np
<PetrHH> soren, Where should I put application icon, please? I've found a lot of directories where e.g. f-spot.png icon is.
<soren> I'm not entirely sure where it truly belongs.
 * soren isn't a desktop person, really.
<pitti> PetrHH: apps usually ship their "canonical" icons in /usr/share/icons/hicolor/
<hallyn> slangasek: kirkland: so, where did we decide qemu-kvm-ppc64 belongs?  qemu-kvm, or qemu-user?
 * hallyn objects to 'apt-get instlal tree' apparently having done an implicit 'apt-get dist-upgrade'
<cjwatson> apt-get install never does an implicit dist-upgrade, but it may be necessary to upgrade other packages to fulfil dependencies.
<cjwatson> I don't see why it would have done so for tree though.
<hallyn> cjwatson: it even updated my firefox
<hallyn> <shrug>
<hallyn> i dunno, this thing's package mgr must still be ina funky state.  it also refuses to install 2.6.38.  i may just need to reinstall
<cjwatson> hallyn: it might have attempted to continue a previously incomplete upgrade
<cjwatson> 'apt-get -f install' might be a good idea
<hallyn> cjwatson: no, that didn't (and doesn't) seem to say anything other than about autoremove packages
<hallyn> guess I'll try another rm -rf /var/cache/apt* and retry without apt-cacher again
<kirkland> hallyn: qemu-kvm, as i recall
<zyga> mvo, ping
<zyga> mvo, do you have 3 minutes for a short brainstorm about dpkg?
<hallyn> kirkland: that's what I had thought.
<hallyn> kirkland: so should we reclasssify bug 717690 as against qemu-user ?
<ubottu> Launchpad bug 717690 in qemu-kvm (Ubuntu) "package qemu-kvm 0.13.0+noroms-0ubuntu12 [modified: usr/share/man/man1/qemu-user.1.gz] failed to install/upgrade: trying to overwrite '/usr/bin/qemu-ppc64', which is also in package qemu-user 0.13.50-2011.02-0-0ubuntu1" [Low,Confirmed] https://launchpad.net/bugs/717690
<hallyn> kirkland: hm, so all of the arm-* patches should be removed from qemu-user, right?
<hallyn> \o/
<pitti> debfx: note that we already have python-gudev in the archive, which just like pyudev is obsolete
<zul> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: open | 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 | Current Friendly Patch Pilots: ev, zul
<kirkland> hallyn: should be fix released now
<pitti> debfx: ah, sorry, it's libudev bindings, not libgudev; for the latter we have a GIR now
<kirkland> hallyn: my last upload fixes that
<pitti> debfx: ok, so ignore me :)
<kirkland> hallyn: yes, all of the arm patches can go
<hallyn> kirkland: you re-uploaded qemu-user?
<kirkland> hallyn: no
<kirkland> hallyn: qemu-kvm
<kirkland> hallyn: we dropped that manpage from qemu-kvm (slangasek's patch)
<hallyn> so you removed qemu-ppc64 from qemu-kvm?
<hallyn> oh, it's the manpage!
<hallyn> doh
<hallyn> kirkland: at this particular moment, I'm down to two patches in qemu-kvm-0.14.0~rc1+noroms :)
<kirkland> hallyn: rock
<soren> No doko?
<hallyn> kirkland: shoudl '~rc1' be in the name like that, btw?
<soren> Maybe someone else can help me out.
<ScottK> I thought he'd be back today (doko)
<soren> ScottK: You might be able to help me with this, actually.
<soren> Once upon a time, python-eventlet was built: https://edge.launchpad.net/ubuntu/+source/python-eventlet/0.9.13-0ubuntu1/+buildjob/2031930
<ScottK> OK
<soren> The build log from amd64 shows that the .deb ended up containing a bunch of things in /usr/lib/python2.7/dist-packages/eventlet/
<soren> in addition to the expected stuff in  /usr/share/pyshared/eventlet/
<soren> I just built a newer version earlier today that didn't end up with stuff in /usr/lib/python2.7/dist-packages/eventlet/
<soren> ..this makes upgrades suck because there are leftover .pyc files in /usr/lib/python2.7/dist-packages/eventlet/.
<ScottK> Where's the newer version?
<soren> https://edge.launchpad.net/ubuntu/+source/python-eventlet/0.9.14-0ubuntu1/+buildjob/2261008
<soren> I tried rebuilding the old source package, and this time I didn't get anything in in /usr/lib/python2.7/dist-packages/eventlet/ so it looks like there was a toolchain problem at some point.
<soren> ...and I can't imagine I'm the only one having to deal with this fallout on upgrades.
<seb128> soren, seems similar to the pywebkitgtk recent issues
<seb128> soren, see the current upload of that one, the changelog has some details
<soren> seb128: The one from about two weeks ago?
<soren> Yeah, changelog entry sounds similar. Thanks.
<seb128> soren, yes
<seb128> soren, I think that was due to package rebuilt in natty when part of the python... didn't support 2.7 yet
<ScottK> soren: I agree it was a problem with the 0.9.13 upload's toolchain.
<seb128> soren, was the "buggy" version uploaded around the time python2.7 landed?
<ScottK> Looks like it was.
<seb128> soren, it's likely to be a similar issue, rebuilt at a time python2.7 was pulled it but part of the buildchain was not ready
<soren> 2010-10-31 17:05:06 CET
<ScottK> There was also a period where 2.7 was a supported version, but not all the helper tools had been updated to know about it yet.
<soren> ScottK: Now that sounds like trouble.
<soren> Uh, wrong timestamp.
<seb128> soren, well, just add some code to clean it up on upgrade
<soren> Yeah.
<seb128> we should likely check what packages got rebuilt around this time
<seb128> it's 2 of those which are spotted as broken now
<seb128> we might have some other ones
<ScottK> soren: I think seb128's suggestion is the right way.
<ScottK> soren: Alternatively, I think switching to dh_python2 would also fix this as, IIRC, that's where it puts it's .pyc files.
<soren> ScottK: I'll deal with dh_python2 some other day. :)
<soren> ScottK, seb128: Thanks, guys!
<ScottK> OK.
<ScottK> barry: ^^^ It would probably be a good idea for someone to do a methodical search for other misbuilt packages.
<mvo> ScottK: misbuild in what way? I may be able to help here (got a VM image with maverick->natty upgraded *python*)
<ScottK> mvo: As soren and seb128 were discussing it looks like late Octoberish pysupport was installing files for python2.7 in the wrong place.
 * mvo reads scrollback
 * barry reads scrollback too
<jelmer> zul: Thanks once again for sponsoring :)
<zul> jelmer: no worries
<kirkland> pitti: hey, are you still around?
<pitti> hi kirkland
<kirkland> pitti: i'm hoping there's an obvious fix for this ...
<kirkland> pitti: been broken for me for 1 month now;  been hoping a magic update would just fix it
<kirkland> pitti: i can't alt-tab to switch windows, resize windows, move windows, etc.
<kirkland> pitti: this is natty gnome
<kirkland> pitti: perhaps i'm missing a package?  or some configuration from day1 natty is not compatible with today?
<pitti> kirkland: hm, that doesn't happen for me; seb128, didrocks, did you ever hear about alt+tab/resizing/moving windows being broken in natty?
<pitti> kirkland: does it happen for a new user, too?
<pitti> kirkland: that's usually the first litmus test whether it's package or config related
<seb128> didn't read anything about that
<pitti> I didn't see that either
<seb128> kirkland, is that under unity or classic GNOME?
<seb128> try to unity --reset maybe
<pitti> kirkland: ok, so try with new user first, then let's bisect it todwn
<pitti> down
<pitti> seb128: "classic gnome"
<highvoltage> pitti: that sounds like the start of a nercore rap :)
<highvoltage> *nerdcore
<didrocks> pitti: not really about that, alt + tab can be very slow
<geser> kirkland: I got once a problem with alt-tab in unity too, I had to re-add the key shortcut as it was gone
<kirkland> pitti: okay, i'll create a new user
<kirkland> seb128: classic gnome
<didrocks> kirkland: normally, I tried to migrate uncompatible settings, but yeah, --reset is always better :)
<seb128> kirkland, try a guest session to start I guess
<seb128> didrocks, is there a compiz --reset?
<pitti> guest session would start unity, though
<didrocks> seb128: not for that, unfortunatelyâ¦
<didrocks> guest session should start the session your are in
<didrocks> you*
<seb128> pitti, what didrocks said
<pitti> didrocks: oh? clever
<didrocks> so, classic if you are in gnome-classic, unity if you are in ubuntu desktopâ¦ and so on :)
<kirkland> weird, unity was not installed
<kirkland> i did not uninstall it
<didrocks> pitti: I fixed it for alpha1, but didn't retest for alpha2
<didrocks> so, in any case, it's in my checking TODO as it's often broken by inadvertance
<seb128> didrocks, what?
<didrocks> seb128: the "start the corresponding guest session"
<seb128> didrocks, that works, at least it starts the classic session for me
<didrocks> seb128: ok nice, not broken again yet :)
<kirkland> didrocks: seb128: pitti: okay, i installed unity, and then ran unity --reset and I can now move windows and resize them again!
<kirkland> i still can't alt-tab, though
<pitti> kirkland: that's progress!
<pitti> curious, though, as unity shouldn't be involved in classic gnome
<didrocks> kirkland: try to hang the alt + tab for few seconds
<pitti> ok, need to finish early today, sorry
<pitti> kirkland: I'll read backscroll
<seb128> pitti, well, unity --reset starts compiz with a fresh profile
<pitti> ah
<pitti> so, compiz bug
<didrocks> kirkland: there is a performance issue with it, so maybe
<hallyn> jinkeys - requestsync failed with 'too many concurrent connections' to mx.launchpad.net:25
<kirkland> didrocks: nope ... if I'm in the terminal, I get "^[      " in my window
<seb128> pitti, "bug" or "config issue"
<didrocks> kirkland: staticswitcher in enabled in ccsm?
<didrocks> (it should as you just reset the value)
<kirkland> didrocks: what is ccsm?
<hallyn> kirkland: did you allow the latin keyboard thingie to misconfigure with alt perhaps?
<kirkland> hallyn: oh
<didrocks> kirkland: compizconfig-setting-manager, a way to change everything in compiz and break it :)
<kirkland> hallyn: maybe so
<kirkland> didrocks: not installed, installing now
<didrocks> kirkland: compizconfig-settings-manager and then, just launch "ccsm"
<didrocks> kirkland: you should ensure that the staticswitcher plugin is activated
<kirkland> didrocks: was not emabled
<didrocks> humâ¦
<didrocks>  /!\ activating/deactivating plugin make compiz crash now
<kirkland> didrocks: got it, that works now
<kirkland> didrocks: seb128: pitti: thanks so much!
<didrocks> kirkland: that's really weird, unity.ini, debian/rules for autogeneration list, and the compiz gconf default are setting itâ¦
<didrocks> kirkland: but well, nice that fixed it for you, I'll try again with a new user :)
<kirkland> didrocks: seb128: pitti: because of this, i have spent most of the last 4 weeks in tty1, with byobu+w3m+ irssi+mutt :-)
<kirkland> (which is actually pretty nice :-)
<seb128> kirkland, don't hesitate to ask early when you have a such issue
<didrocks> kirkland: well, that's just a way for you to enjoy byobu a little more :)
<kirkland> seb128: thanks, will do
<tumbleweed> bdrung: ^5 (on ubuntu-sponsoring)
<dholbach> bdrung, tumbleweed: are you both looking into the unicode problem right now?
<dholbach> I just wanted to take the dog for a walk real quick - I can review whatever you have when I'm back
<dholbach> it'd be nice to get the issue resolved :)
<tumbleweed> dholbach: at least I am :)
<dholbach> thanks muchly
<dholbach> I'll let you know when I'm back
<bdrung> dholbach: i am cooking
<mvo> hey zyga - you pinged me earlier?
<zyga> mvo, yes
<zyga> mvo, I had this crazy idea of being able to install packages without invoking any scripts, then gathering the required scripts and executing them in sequence during first boot, I was wondering what kind of caveats would you think of in such design
<mvo> barry: mind if I upload some rebuilds for python2.7 ? looks like python-oss is a candidate for this, probably more
<mvo> zyga: you need to consider that pre-depends requires a package to be installed and configured, so you can only delay those with "regular" dependencies. then you need to run the configure scripts on bootup in the right order (well, dpkg --configure -a should actually handle this for you). and there is the issue that your daemon will not get restarted, so e.g. on security updates of libfoo the old copy keeps running
<zyga> mvo, re, sorry about being missing
<zyga> mvo, this about building system images "dry", without running the target system (pc->arm)
<zyga> mvo, so issues such as running system are not important here
<zyga> mvo, in fact we have a slightly easier work to perform, currently linaro has a tarball with the root fs created using lexbuilder/offspring with the regular method (which AFAIR depends on qemu faiking the target system)
<zyga> mvo, then when you want to create a bootable media for your device you need to combine this filesystem with a "hardware pack" which is a tarball with extra packages and repository for anything that they might depend on
<zyga> mvo, currently the procedure is somewhat complex because we need to install those hardware pack packages in the image we're building, I wanted to simplify that
<zyga> mvo,  up to a point that the whole procedure would not depend on anything apart from simple file manipulation tools
<ev> GunnarHj: merged both branches and uploaded; great work on these!
<ev> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: open | 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 | Current Friendly Patch Pilots: zul
<seb128> hum
<seb128> is launchpad or launchpadlib known to be broken?
<seb128> the retracers crash on "NotImplementedError: Can't look up definition in another url (https://api.launchpad.net/1.0/#distributions)"
<jpds> seb128: leonardr is talking about this in #launchpad with apw.
<james_w> seb128, login_*(name, service_root=EDGE_SERVICE_ROOT) needs to change EDGE_SERVICE_ROOT to "production"
<pitti> james_w: thanks
<apw> james_w, so login_*(name, service_root="production") ??
<james_w> apw, yeah
<james_w> if you are on a really old version of launchpadlib that will crash, let me know if so
<seb128> james_w, how come they didn't keep it working for compatibility purpose?
<seb128> it's breaking retracers and sponsoring queue and versions and...
<seb128> like is there any need to force us to do review and fix everything now by breaking it?
<james_w> seb128, they wanted to reassign the edge machines to the production, and a redirect broke some other things
<james_w> seb128, I disagree with the way they have gone about it
<seb128> james_w, ok, thanks
<bobg> i am writing a package for my company that supplies the debconf values for ldap-auth-config (so that we can install this package to config a machine to use the company ldap for authentication) what's the best channel to get help for that?
<cjwatson> in fairness the edge decommissioning was announced several months ago
<pitti> seb128: apport trunk already uses production, so the natty chroot should be okay, and the crash-digger merely needs a bzr pull
<pitti> seb128: the only problem is the maverick chroot, we'd need either an SRU or a backport of apport in my PPA; I'll handle that one tomorrow
<bdrung> dholbach, tumbleweed: merged
<pitti> seb128: ok, branches updated and locks removed; let's see how it goes
<seb128> pitti, thanks
<pitti> seb128: ah, need to refresh the LP cookie, doing..
<pitti> seb128: did it crash right away? it's currently consolidating the dup db, but that already means lots of LP access
<seb128> pitti, yes
<pitti> ok, cool
<seb128> pitti, thanks for the quick fixing
<achiang> pitti: do you understand the relationship between udev and usb_modeswitch? i'm playing around with a new modem, which i'm pretty sure needs to be mode-switched. it was not originally listed in /lib/udev/rules.d/40-..., so i stuck an entry in there. yet, when i plug it in, i don't really see udev calling the proper script
<achiang> udevadm monitor isn't really showing me anything interesting (or i don't know what i should be looking for)
<pitti> achiang: I'm just logging out, can you please mail me?
<achiang> pitti: ok, sure
<pitti> cheers
<achiang> thanks
<slangasek> hallyn: I thought the conclusion was that qemu*ppc64 rather belonged in /qemu-linaro/; is that not the plan?
<hallyn> kirkland: ^
<hallyn> slangasek: that hadn't been what i remembered, and i *think* not what kirkland took away from it either, but waiting for him to confirm
<kirkland> slangasek: i thought we were putting any and all kvm-accelerated stuff in qemu-kvm
<kirkland> slangasek: where ppc64 is (or will very soon be) kvm-accelerated
<dholbach> bdrung, pulled
<slangasek> kirkland: well, we said that, yes... we also earlier discussed that powerpc support would be going directly against qemu upstream so it might be just as good to package it via qemu-linaro
<slangasek> kirkland: I guess I don't mind either way, but at this point you're missing a Replaces :)
<kees> seb128: re 717358: what does that have to do with this goofy menu bar?
<seb128> bug #717358
<ubottu> Launchpad bug 717358 in nautilus (Ubuntu) "nautilus puts a menu bar at the top of the desktop" [Low,Incomplete] https://launchpad.net/bugs/717358
<seb128> kees, I guess I didn't understand the issue, it seemed like you have the default config with a gnome-panel at the top of the screen and indicator-appmenu
<kees> nope. I have no panel on the top.
<kees> you can see in the screenshot that it's a menu bar
<seb128> kees, well that could have been the indicator-appmenu applet on a panel weirdly themed as well
<kees> and if I select "Help / About" it says nautilus
<kirkland> slangasek: hrm, okay;  please commit the Replaces that we need against lp:ubuntu/qemu-kvm
<seb128> right, the default appmenu if you have nothing focussed is the nautilus one
<kees> I'm using classic desktop.
<seb128> kees, do you have a dual screen config?
<kees> nope
<kirkland> slangasek: the ppc64 patches will be against HEAD, but we're shipping qemu-kvm-0.14 in 11.04, so we're not far off
<seb128> kees, well, indicator-appmenu is in the default classic desktop applet list in natty
<kees> none of my other menu bar end up there (thank goodness).
<kirkland> slangasek: also, it's the server team doing the work and testing against ppc64/kvm, so i think it'll be better for us to work against qemu-kvm (ours) rather than stepping on qemu-linaro (yours)
<seb128> kees, ok, dunno then, I just tried in a guest session and move the default gnome-panel which is at the top and I don't get that
<seb128> kees, I've switched back the bug to New I will let someone else confirm
<kees> seb128: mdeslaur already confirmed it
<seb128> kees, nautilus didn't get an upload for a month so it's not likely due to it
<slangasek> kirkland: well, I would like less of an ours vs yours here; qemu-linaro is just like any other Ubuntu package and if changes are needed any Ubuntu developer can make them as normal
 * kees looks around for tedg
<kirkland> slangasek: heh, fair enough
<slangasek> kirkland: so from that POV I don't really think that having it in qemu-linaro instead of qemu-kvm should handicap you
<seb128> kees, try mterry or kenvandine otherwise ;-)
<kirkland> slangasek: okay, but you did tell me qemu-linaro will be 0.13.5, right?
<kees> seb128: okay, thanks!
<seb128> kees, you're welcome
<kees> mterry, kenvandine: hi! :) can you look at 717358? does that relate to work you've done recently?
<slangasek> kirkland: qemu-linaro is *currently* at 0.13.50, which is "straight from HEAD plus linaro cleanups"
<kirkland> slangasek: we'll be uploading 0.14~rc1 today, so that puts us closer to HEAD (which I think is the main point)
<slangasek> from my side I haven't heard that an rc was impending, but the line of communication is a bit long
<slangasek> AIUI we're no more than 2 weeks out of date wrt upstream
<slangasek> and will be syncing with them again between now and release
<mterry> kees, wait, so nautilus is drawing its menu in gnome-panel even without the appmenu being active?
<kees> mterry: no, no gnome panel at all up there.
<slangasek> kirkland: the other question I have is, is whether it makes sense to install qemu-system-ppc64 for everyone on x86 who installs qemu-kvm
<kirkland> slangasek: interesting choice of version, then :-)
<kees> mterry: I have only a panel at the bottom of my screen, and I'm running classic desktop so none of the menu-bar stealing should be happening.
<slangasek> kirkland: the 0.13.50? It's what was in the upstream git at the time as the label
<mterry> kees, oh, weird.  No, not related to my work
<kees> mterry: okay
<kirkland> slangasek: fair enough;  qemu is weird then :-)
<seb128> kees, mterry: ok, I can confirm that, if you don't have an appmenu container set it does that
<seb128> kees, mterry: like in a guest session if you remove indicator-appmenu from gnome-panel
<mterry> MUST SHOW APPMENU!!! GRR
<seb128> ;-)
<mterry> seb128, I can look at it
<seb128> mterry, if you want to that would be welcome
<seb128> otherwise we can ask ted when he's back
<kirkland> slangasek: and yes, i think that to be consistent with myself (oh so important, btw!), qemu-kvm should install qemu-system-[i386,x86_64,ppc64]
<kirkland> slangasek: and qemu-kvm is the home for "architectures that support kvm-acceleration"
<kirkland> slangasek: at least for now
<kirkland> slangasek: and then we have another interesting discussion when cortex15 adds VT support for ARM
<kirkland> slangasek: hopefully by then, qemu-linaro has merged into qemu
<slangasek> kirkland: <smirk>
<kirkland> slangasek: but i won't hold my breath on that one
<kirkland> slangasek: too many moving parts outside of our control (ARM, QEMU, etc)
<ogra> and you cant be sure the VT variant is actually kvm
<seb128> re
<slangasek> kirkland: qemu-linaro is already the source for upstream qemu in Ubuntu packages, for all intents and purposes - merging isn't the issue
<ogra> compatible
<seb128> mterry, I was saying that if you want to look to it that would be welcome or we can ask ted
<kirkland> slangasek: okay
<seb128> laptop crashed on vt switch then
<seb128> mterry, that's not an appmenu though but the nautilus menu
<mterry> seb128, oh, it's only nautilus?  ah, thought it was everything
<seb128> like it doesn't track other menus or anything and go away when you nautilus --quit
<seb128> could be the compiz update for the invisible dialogs issue
<mterry> seb128, ok, I'll delay looking at that then.  I've got other indicator stuff I can do
<seb128> mterry, ok
<seb128> it happens in unity as well in fact
<seb128> I can see a one pixel grey line below the unity-panel there
<seb128> if I switch workspaces I can see the menubar from nautilus during the transition
<GunnarHj> ev: Thank you, Evan!
<seb128> kees, mdeslaur: do you know when the menu issue started?
<mdeslaur> seb128: Unfortunately, not really, since it's being drawn _underneath_ my gnome-panel
<geser> seb128: a few days ago, I can check my IRC log when I asked about it #ubuntu-desktop
<seb128> geser, you asked on friday morning european time
<seb128> geser, I checked
<seb128> ok
<seb128> let's say it's one of the update on thursday
<hyperair> was there a tool that allows you to check the signatures of source packages?
<Laney> dscverify
<hyperair> aha!
<hyperair> thanks
<hyperair> i'm uploading gdata-sharp to ubuntu now
<Laney> â¥
<Laney> sync?
<hyperair> yes
<hyperair> Laney: we'll need to rebuild gnome-do-plugins
<Laney> sure
<hyperair> in debian as wel
<hyperair> +l
<hyperair> well gdata# has been uploaded.
<hyperair> next will be banshee
<hyperair> but that'll have to wait for directhex to upload it to debian first.
<Laney> you can probably make it syncable
<hyperair> the one with amended debian/control
<Laney> if you take that patch into debian
<hyperair> nah, banshee isn't syncable.
<Laney> i mean plugins
<hyperair> ah
<hyperair> i don't know, i didn't work on gnome-do-plugins before
<Laney> it's your patch :P (which is already upstream)
<hyperair> eh?
<hyperair> it's my patch?
<hyperair> O_o
<Laney> check it out
 * hyperair checks
 * sebner hugs Laney and hyperair =)
<hyperair> oh that one
<hyperair> that's oooooooooold
<hyperair> and that patch should go into debian, yes
<Laney> there you go, an excuse for an upload/sync
<Laney> \o/
<hyperair> heheh
<hyperair> hmm
<hyperair> it's still svn? =O
<Laney> RAOF was talking about migrating it the other day
 * Laney knows not what the plans are
<hyperair> i see.
<hyperair> it seems that hibernate in gnome-do is broken though.
<hyperair> on maverick
<hyperair> i haven't had time to poke it to see
<hyperair> or maybe it's my weird setup
 * sebner goes crying into the corner as he feels slightly ignored
 * Laney fluffs sebner
<sebner> :D
 * iulian hugs sebner.
<sebner> \\o/
 * Laney fades away
<Laney> ttyl
<bobg> is it possible to use debconf-set-selections inside a package preinst (or other) script so that it effects another package?
<cody-somerville> pitti, Is apport sending a 'Crash report detected' to the notification daemon over and over repeatedly a known issue in Maverick? :P
<cody-somerville> wow... I just noticed that apport will open up the web browser running as root. That can't be intentional.
<satya> hello
<kklimonda> jdstrand: hey, do you have a moment?
<kklimonda> actually, anyone from the security team would help :)
<jdstrand> kklimonda: whatcha need?
<jdstrand> kklimonda: and hi! :)
<kklimonda> jdstrand: hey. I have a small problem.
 * jdstrand thinks he may know what it is...
<kklimonda> jdstrand: Transmission requires a newer version of libevent then the rest of the archive, and we can't do the transition as we get some ftbfs - some of them in tests which indicates that something subtle has changed, and other packages may be affected.
<jdstrand> that was not it :)
<kklimonda> jdstrand: it leaves me with two choices - keep transmission at 2.13 for natty
<kklimonda> which will make it harder on both us and upstream to maintain it.
<kklimonda> jdstrand: or rebundle libevent2 in transmission source - it was bundled for a long time, I think we started using a system version only a year ago or so.
 * jdstrand cringes a little
<jdstrand> let me look at the source
<kklimonda> sure - do you want a link to libevent 2.0.10?
<jdstrand> looks like 1.73-3 use the system libevent
<jdstrand> kklimonda: not really
<kklimonda> so it was even earlier? How long have I been around..
<jdstrand> so, lucid is supported until 2012-04 and natty is supported until 2012-10
<jdstrand> yeah, that was pre-karmic
<jdstrand> I'm sorry
<jdstrand> lucid is supported until 2013-04
<jdstrand> that makes it easier
<jdstrand> natty will fall off before lucid is eol
<kklimonda> right, how does it help
<kklimonda> ?
<jdstrand> so I'm not sure the maintenance burden is greatly reduced by having the absolute latest trnasmission
<chrisccoulson> we want the latest crack though ;)
<jdstrand> kklimonda: so, I'm inclined to say that the recommendation from a security team POV is to keep transmission where it is for now, until the libevent issues are worked out and it can use the system one
<jdstrand> chrisccoulson: :P
<jdstrand> there might be other factors, but embedded a library is really pretty bad, even more so when we diverge from Debian
<jdstrand> s/embedded/embedding/
<kklimonda> jdstrand: where can I check the history of security issues in libevent?
<jdstrand> http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=libevent
<kklimonda> hmm.. so it's a choice between the latest crack, and ease of maintainance.. bummer, both choices suck ;)
<jdstrand> well, what sucks is the timing of the library transition
<SpamapS> Is hardy still getting actively updated with non-security SRU's or is it security only?
<jdstrand> SpamapS: it will ge tthe occasional SRU
<SpamapS> jdstrand: whiel I have your attention, I think that bug #251139 is making an unacceptable SRU request to have apr backport a change to use /dev/urandom instead of /dev/random. Would you concurr?
<ubottu> Launchpad bug 251139 in apr (Ubuntu) "backport apr 1.2.12 to Hardy" [Undecided,New] https://launchpad.net/bugs/251139
<kklimonda> ok, we are staying with 2.13 in this case, I'm not willing to add burden on others so we can get latest features. thanks jdstrand :)
<jdstrand> kklimonda: sure, np. a wise choice if I may say :)
<jdstrand> SpamapS: on the face of it, I don't see it as particularly high-risk, but hardy is pretty stable these days. I think you might have a hard time convincing them it is needed. it is a 2.5 year old bug with no one saying it affects them too or duplicates
<jdstrand> and by them, I mean ubuntu-sru
<SpamapS> Yeah exactly
<SpamapS> Entirely possible too that somebody has built a system out there expecting super-high-quality-randomness in apr.
<jdstrand> "Won't Fix" is a viable choice. who knows, the user may come back with an important use case to reconsider
<SpamapS> Thats what I was going to mark it.
<SpamapS> Thanks for taking a look. :)
<jdstrand> sure! :)
 * SpamapS just loves triaging bugs that are older than his children.
<kklimonda> oh, I just made my life harder then it should be - I'm subscribed to ubuntu MLs from my @ubuntu address, but bug mails are sent to my main address. Because of that people CC the email which is not subscribed, and my response ends up in the moderation..
<micahg> kklimonda: virtual identity or correct identity for Thunderbird can help with that
<kklimonda> thunderbird you say? :)
<kklimonda> I guess it's time to give it another shot
<SpamapS> Evolution seems to get the reply address mostly right, most of the time.
<ScottK> Wow.  A nice comment about Evolution and multiple hours of stunned silence ensue.
<maco> haha, especially after that pc world article
<charlie-tca> amazing what a single good thing will do, huh?
<kees> doko: what're your thoughts on 712662
<doko> bug #712662
<ubottu> Launchpad bug 712662 in bash (Ubuntu Karmic) "network redirection has been enabled" [High,Confirmed] https://launchpad.net/bugs/712662
<doko> kees: would it be ok, if such packages use /bin/sh in there scripts only? and if a user is created for these packages, to set the login shell to /bin/sh ?
<kees> doko: hrm? the point is to keep any shell from having built-in network redirection
<doko> kees: shell or interpreter?
<kees> shell.
<kees> scripting languages all have networking, even awk
<doko> people did file bug reports to enable it
<kees> but shells doing networking is odd
<kees> yeah.
<kees> but it's been off for so long; it's a security feature :)
<doko> I did enable it once dash was the default shell
<kees> true
<kees> jdstrand: what do you think of making the distinction between dash and bash for this? I think it wouldn't work well.
<kees> doko: the problem is that most apps (say, firefox) when running subshells are using the users's defined login shell to do the work.
<kees> so it's not so simple to separate dash and bash in this case
<doko> kees: what would break if we disable the redirects?
<jdstrand> kees: I'm not sure I understand the question. your last comment is the problem. eg, things that use /bin/sh get dash in Ubuntu and profiling is no problem. it is things that specifically use bash
<kees> doko: nothing I know depends on it
<doko> jdstrand: bash is still essential, so it's difficult to determine what depends on bash
<jdstrand> forgive me, I have no idea what I am being asked
<doko> ask kees ;P
<kees> jdstrand: heh, sorry.
<jdstrand> I'm coming at it from an apparmor profiling angle
<jdstrand> it is very easy to see when profiling an application which is used
<kees> jdstrand: right, so how to the abstractions currently deal with dash vs bash?
<jdstrand> there is no dash abstraction
<jdstrand> things that use dash will use the bash abstraction
<jdstrand> and ixr
<kees> I'm just trying to use AppArmor as supporting evidence. I don't like shell redirection because it makes remote attacks much easier
<jdstrand> the bash abstraction isn't a problem
<jdstrand> it is when you pull in networking, and have bash ixr
<jdstrand> eg,
<jdstrand> #include <abstractions/namneservice>
<jdstrand> #include <abstractions/bash>
<jdstrand> /bin/bash ixr,
<SpamapS> slangasek: around? I think we may need to make a change to upstart-job's handling of the 'restart' command after discussing something w/ Keybuk last week.
<jdstrand> ^ with that, networking is implicitly allowed via the nameservice abstraction, and bash has network redireection, so you have a reverse shell
<jdstrand> where one would not think one would
<doko> kees, jdstrand: offline now, let's continue later this week, but not tomorrow. need to catch up on more things
<jdstrand> if networking is not allowing in the profile, then no problem
<kees> doko: okay
<jdstrand> if dash is used and not bash, then no problem
<kees> jdstrand: right
<jdstrand> it is the combination of bash, networking in the profile and network redirection
<jdstrand> then you have to go through ridiculous hoops to confine bash
<jdstrand> (see the bug)
<jdstrand> kees: cups suffers from this, as a specific example
<jdstrand> ./usr.sbin.cupsd:  #include <abstractions/bash>
<jdstrand> ./usr.sbin.cupsd:  /bin/bash ixr,
<bdrung> zul: are you still progressing bug #719056?
<ubottu> Launchpad bug 719056 in sg3-utils (Ubuntu) "Sync sg3-utils 1.30-1 (main) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/719056
<zul> bdrung: hmm?
<bdrung> zul: you gave your ACK, but ubuntu-sponsors is still subscribed, the status is still new, and ubuntu-archive isn't subscribed
<zul> yeah i just stepped away for a momment
<zul> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: open | 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 | Current Friendly Patch Pilots:
<bdrung> zul: status -> confirmed
#ubuntu-devel 2011-02-15
<xorgnak> woud anyone know what the discover1 package has been moved to for 10.10?
<xorgnak> nevermind... if anyone's curious for remixes, discover1 has been depreciated to discover
<slangasek> SpamapS: hi; still around?
<r3d2> hey you guys. i just downloaded my first source code so i can get an idea of how linux programs are written....i picked a relatively small program, mousepad. and after i "sudo apt-get source mousepad" it seems like everything worked out
<r3d2> but now i have 1 folder and 3 files for it
<r3d2> mousepad.diff.gz mousepad.tarr.gs and mousepad.dsc
<r3d2> what are all those?
<RAOF> mousepad.dsc is some metadata about the source package, mousepad.diff.gz is the difference between the upstream source and the Ubuntu source package, and mousepad.orig.tar.gz is the original source.
<r3d2> ah nice
<r3d2> thank you
<r3d2> that explains it all lol
<YokoZar> what are the ways that Universe might be unchecked?
<YokoZar> Is there an option at install, for instance?
 * micahg thought it was disabled by default
<vish> there is an option during which enables the restricted and multiverse repos but as micahg says nothing enables universe until user selects it
<pitti> Good morning
<pitti> cody-somerville: no, it isn't; apport doesn't use notifications at all; also, web browser should be opened as user indeed
<cody-somerville> pitti, if you click links in dialogues, they open as root
<cody-somerville> pitti, for example, the link to trying out upstream kernel
<pitti> cody-somerville: you mean in the kernel dialogs?
<pitti> right, that's GTK itself
<pitti> perhaps there's a way I can override the default URL handler in GTK
<pitti> when apport opens the browser for bug filing, it uses some tricks to go "back" to the user's account
 * cody-somerville nods.
<alkisg> Hi, can someone re-open LP bug #580961, as it's not fixed yet?
<ubottu> Launchpad bug 580961 in unzip (Mandriva) "unzip fails to deal correctly with filename encodings" [High,Confirmed] https://launchpad.net/bugs/580961
<maco> alkisg: you tried it with version 6.0-4ubuntu1 in 11.04 alpha 2?
<alkisg> maco: yes, I posted why it's broken in the bug report
<alkisg> It looks like part of the patch is missing
<maco> alkisg: ok, reverted to triaged
<maco> or well...as soon as my web browser goes as bit faster....
<alkisg> Thank you. To clarify, it's still not working, i.e. a regression from previous Ubuntu versions, I'm not asking for anything new like autodetection (like others in that bug report do ask).
<dholbach> good morning!
<didrocks> good morning
<pitti> hey dholbach, bonjour didrocks
<didrocks> hey pitti
<dholbach> hey pitti
<kklimonda> jdstrand: btw, the other thing you thought I was talking about is still important, but it just wasn't as important to me ;)
<cjwatson> vish: not true, universe has been enabled by default since feisty
<cjwatson> (not on the live CD though, but in installs)
<vish> cjwatson: odd.. the last time i installed with natty cd it made me choose universe to install banshee..
 * vish will check but trusts cjwatson more ;)
<seb128> hum
<seb128> does anybody has any clue about bug #717516?
<ubottu> Launchpad bug 717516 in cairo (Ubuntu) "No Plymouth message or password prompts w libcairo2_1.10.2-2ubuntu1" [Undecided,New] https://launchpad.net/bugs/717516
<seb128> slangasek, pitti, cjwatson: ^ not sure who is tracking plymouth issues nowadays, seems something to check but I'm not sure what to ask on the bug
<cjwatson> there was a plymouth bug that soren fixed yesterday
<cjwatson> haven't actually read that report but make sure that the user isn't using plymouth 0.8.2-2ubuntu15 or 0.8.2-2ubuntu16
<seb128> cjwatson, he says he still get the issue on 17 in the bug
<cjwatson> soren: did you commit your patch anywhere?  I don't see it in lp:ubuntu/plymouth
<seb128> cjwatson, thanks, I've added a comment pointing to the bug fixed in ubuntu17 and asked some details
<Riddell> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: open | 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 | Current Friendly Patch Pilots: Riddell
<pitti> whee, Scottish airpatchlines!
 * dholbach hugs Riddell
<apw> cjwatson, can you remind me  when we enabled the grub graphical handoff at the grub level?  was that after A1 ?
<cjwatson> apw: Wed, 24 Nov 2010 13:59:55 +0000
<soren> cjwatson: Gah, sorry.
<soren> cjwatson: I wanted to wait until it was accepted into the archive, but got sidetracked.
<soren> cjwatson: Pushed.
<seb128> dholbach, did someone point already that the sponsoring queue have wrong urls for merge requests today?
<dholbach> seb128, no, not yet
<seb128> dholbach, it has api.launchpad.net/1.0/.... instead of "code.launchpad.net"
<dholbach> ah yes
<seb128> dholbach, it's likely a side effect of the fix they did yesterday after breaking things still using "edge" in their code
<seb128> dholbach, you should probably port your code to use "production" rather than edge
<seb128> should be trivial
<dholbach> yes part of it was, yesterday
<seb128> dholbach, well yesterday it just crashed, they did online patching to fix the redirect
<seb128> but seems it's not perfect
<dholbach> yes, I know
<dholbach> working on it
<seb128> dholbach, danke
<dholbach> that's why I said "part"
<seb128> ;-)
<dholbach> nice, bdrung already fixed it
<dholbach> seb128, should be fixed with next cron run
<seb128> dholbach, excellent
<seb128> bdrung, dholbach: thanks
<Riddell> zul: python-django-nova packaging is GPL 2, I think canonical policy is for GPL 3
<Riddell> zul: I've accepted but you should check that
<soren> \o/
<\sh> moins
<siretart> hi \sh!
<\sh> hey siretart...how's life?
<siretart> \sh: not too bad, a bit stressful, but otherwise making progress. how are you and family?
<nigelb> g40
<nigelb> ugh, sorry
<\sh> siretart: fine..wife is waiting in belgium, that our nice and nephew are born...and I'm still at KA and merging from netviewer to citrix online ;)
<siretart> \sh: :-)
<\sh> siretart: means our company just reported the closing of the deal between citrix and netviewer ;) so we are now a 100% division of them ;)
<siretart> wow. does this relate in any way to your dc^2 project?
<\sh> siretart: dunno...but I still have some weeks of time to think about staying with this company or to change to another company or to just leave all that behind and become self-employed (or in the worst case, hartz IV ;))
<siretart> \sh: don't make (bad) jokes about that
<siretart> \sh: but while I have you here, is there some installation guide or something available for dc2? I'm considering to deploy it.
<\sh> siretart: no..I mean that...well, I have some nice job proposals
<siretart> :-)
<\sh> siretart: nope...but I can guide you if you want...I have to push another branch to trunk to make especially the qooxdoo frontend more usable with self deployed installations
<\sh> and there are two other branches to switch dcÂ² from mysql to couchdb, and to integrate some amazon ec2 management to it...it's still work in progress but hey :)
<siretart> sure, I imagine. for a starter, the precise installation requirements would help me
<siretart> but perhaps we should move that to a more appropriate channel ;-)
<\sh> siretart: #dc2 ;)
<siretart> oftc or freenode?
<\sh> freenode
<Riddell> cjwatson: thanks for fixing bug 705917 :)
<ubottu> Launchpad bug 705917 in ubiquity (Ubuntu Natty) "kde frontend keyboard selector broken" [High,Fix released] https://launchpad.net/bugs/705917
<cjwatson> np
<zyga> doko_, ping
<MadCow108> hi, when I want to backport a bugfix in a debian native package (format 3) for ubuntu, do I still use the debian/patches method or do I just directly patch the source as I would do it for debian?
<MadCow108> the former would additionally require to add quilt to the build depends
<cjwatson> er, a *native* package?
<cjwatson> what does 'cat debian/source/format' say?
<pitti> MadCow108: I'd apply inline for native packages
<cjwatson> Debian and Ubuntu are just the same in this regard, but your question is confusingly phrased in a way which makes me think one of us is misunderstanding something
<pitti> ITHM "3.0 (native)"?
<MadCow108> 3.0 (native)
<cjwatson> it's not clear, that's why I asked
<hallyn> anyone else seeing garbled gnome-terminal text with 2.6.38-3 ?
<cjwatson> you don't use the debian/patches method in either Debian or Ubuntu for native packages
<cjwatson> you apply it inline, and there is no need to build-depend on quilt
 * hallyn figures kirkland will chime in
<MadCow108> ok
<cjwatson> because you wouldn't be using quilt
<MadCow108> I was just wondering as the qult method would make it a bit easier to see the differences between the debian and ubuntu version
<cjwatson> you can see that by just diffing the packages
<cjwatson> but no, that would involve changing from native to quilt format and we try hard not to make that sort of fundamental change to a package's format in Ubuntu
<MadCow108> ok thanks
<Riddell> mvo: are you going to update natty for bug 556189 ?
<ubottu> Launchpad bug 556189 in python-pip (Ubuntu) "$ pip install <package> fails on missing setuptools" [Medium,In progress] https://launchpad.net/bugs/556189
<mvo> Riddell: this is just a stale status, I fix that
<doko_> zyga: pong
<zyga> doko_, who should I ask to debug stale pymodules cache?
<doko_> zyga: either barry or me. could you be a bit more specific?
<zyga> doko_, drop in to #ubuntuone please
<zyga> doko, ralsina and me are trying to understand and debug something that seems to be stale cache of pyc files after an older installation
<zyga> doko_, we'll file a bug and I'll ping you about it if you don't mind
<tumbleweed> zyga: which package? It's quite possible that there are stayle .pyc files in the python path, if it was uploaded inbetween python2.7 support and python-support being updated
<zyga> tumbleweed, this is still on maverick, and seems to be reproducible
<zyga> tumbleweed, ralsina on #ubuntone understands more
<asac> didrocks: master ... how painful is it to backport the current unity stuff to maverick?
<asac> or are you guys actually maintaining a backport somewhereÃ
<asac> ?
<didrocks> asac: we stopped backporting it because it's really painful
<didrocks> asac: you need to backport compiz and all plugins + a lot of package from the unity and appmenu world
<didrocks> and soon, you will need the latest glib
<asac> grr
<asac> why are folks always jumping on the latest crack :)
<didrocks> asac: yeah, people are crazyâ¦ :)
<sebner> asac: because old stuff is boring ;)
<asac> its really dog style of development ;)
<kirkland> hallyn: kirkland reading scrollback
<kirkland> hallyn: garbled terminal text?  no....
<ogra> could an archive admin promote unity-2d, libqtgconf, libqtbamf and libqtdee to main ? (MIR bugs are bug #708649, bug: #708661, bug: #708659 and bug: #708658
<ubottu> Launchpad bug 708649 in unity-2d (Ubuntu) "[MIR] please include unity-2d in natty main" [High,Fix committed] https://launchpad.net/bugs/708649
<ubottu> Launchpad bug 708658 in libqtdee (Ubuntu) "[MIR] please include libqtdee in natty main" [High,Fix committed] https://launchpad.net/bugs/708658
<pitti> ogra: yup, doing
 * ogra hugs pitti
<pitti> kein Problem :) *hug*
<kirkland> pitti: hey
<pitti> kirkland: hey Dustin, how are you?
<kirkland> pitti: fine thanks :-)
<kirkland> pitti: okay, so ecryptfs-utils version in lucid and maverick were identical, hence that upload was rejected
<kirkland> pitti: how does this look:
<kirkland> ecryptfs-utils (83-0ubuntu3.1-maverick) maverick-proposed; urgency=low
<pitti> kirkland: ah, usually we do somehting like x.10.04 and x.10.10, but as we already have lucid, "3.1maverick" works
<pitti> kirkland: no dash, please, as this is the separator of upstream-revision
<kirkland> pitti: cool
<kirkland> ecryptfs-utils (83-0ubuntu3.1maverick) maverick-proposed; urgency=low
<kirkland> pitti: done;  re-uploading now
<pitti> kirkland: thanks!
<kirkland> pitti: done
<kirkland> pitti: thanks, mate!
<smoser> geser, bug 715818 is fixed.
<ubottu> Launchpad bug 715818 in ec2-api-tools (Ubuntu) "ec2-api-tools FTBFS in natty" [Medium,Fix released] https://launchpad.net/bugs/715818
<geser> smoser: thanks
<smoser> thank you for your help. I irresponsibly failed to credit you in changelog. for that i am sorry.
<geser> np
<Riddell> mterry: could bug 676512 get some MIR assignment love?
<ubottu> Launchpad bug 676512 in qtmobility (Ubuntu Natty) "MIR qtmobility" [Undecided,New] https://launchpad.net/bugs/676512
<mterry> Riddell, I'll check
<ogra> pitti, hmm, unity-2d doesnt show up in main yet
<ogra> (netbook-meta update tells me its unknown)
 * ogra thinks after 
<ogra> 3h it should be there
<ogra> oh, its only 2h
<RoAkSoAx> stgraber: http://iso.qa.ubuntu.com/qatracker/dllist is empty and there are ISO's available in the tracker
<RoAkSoAx> any ideas why?
<stgraber> RoAkSoAx: that's weird, let me check
<stgraber> RoAkSoAx: http://iso.qa.ubuntu.com/qatracker/info/5015
<stgraber> RoAkSoAx: seems to happen with all the builds
<stgraber> so dllist doesn't return anything as it can't get the info from cdimage
<stgraber> RoAkSoAx: I guess that the current magic to find the right file on cdimage doesn't cover the point releases
<RoAkSoAx> stgraber: ah I see
<stgraber> marjo: ^
<RoAkSoAx> Riddell: till what time are you piloting?
<Riddell> RoAkSoAx: until I sign off :)
<RoAkSoAx> Riddell: lol ok :)/. Let me know cause I'm up next :)
<Riddell> RoAkSoAx: oh you can add yourself too I'm sure
<Riddell> just do @pilot in
<gaurav_pawaskar> hi people, I want to know.. when bug is raised .. how do we identify, which all packages are related to that bug?
<RoAkSoAx> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: open | 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 | Current Friendly Patch Pilots: RoAkSoAx, Riddell
<mdeslaur> mvo: have you got a minute? I want to update flashplugin-nonfree in hardy from v9 to v10. There is another package that some people install called "libflashsupport" that ships a library that is incompatible with v10.
<mdeslaur> mvo: of course, even if I try to conflicts/replaces it, update-manager in hardy won't remove it
<mdeslaur> mvo: is my only hope to ship a dummy libflashsupport update that is empty?
 * ogra glares at bug 9068
<ubottu> Launchpad bug 9068 in casper (Mandriva) "Serial mouse/mice not autodetected" [High,Confirmed] https://launchpad.net/bugs/9068
<ogra> mandriva uses casper ?!?
<mdeslaur> mvo: hmm..I'll try adding a transitional package to flashplugin-nonfree
<marjo> stgraber: I noted same to jibel; will fix in future point releases
<cjwatson> stgraber: in the case of http://iso.qa.ubuntu.com/qatracker/info/5015, that should be /lucid/dvd/...
<cjwatson> stgraber: generally, put lucid/ before the "daily", "daily-live", or "dvd" bit
 * ogra wonders how long main promotion takes nowadays
<ogra> publisher should have run several times now
<cjwatson> I probably forgot to release the lock after my manual work earlier today
<ogra> oh
<cjwatson> released, hopefully the next run will work
<cjwatson> sorry about that
<ogra> thanks
<ogra> no problem
<kees> pitti: is /etc/default/apport's "maxsize" actually used anywhere?
<Riddell> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: open | 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 | Current Friendly Patch Pilots: RoAkSoAx
<ari-tczew> cjwatson: lilo 23 in Debian. what's the decision?
<cjwatson> ari-tczew: I followed up to the bug
<ari-tczew> cjwatson: stay with 22?
 * cjwatson wonders why he is on the hook for lilo - I'm a grub developer, I'd rather not deal with lilo
<cjwatson> ari-tczew: are you prepared to deal with all issues that arise from upgrading?
<cjwatson> e.g. subscribe to all lilo and lilo-installer bugs until at least the natty release
<ari-tczew> cjwatson: guess no
<cjwatson> then I think we ought to merge up to what was released in squeeze, and let the new version shake out in Debian for a while
<cjwatson> that seems like a reasonable course of action to me.  do you agree?
<cjwatson> without somebody paying attention to it in Ubuntu, I think we should be fairly conservative and stick with what we would have done if it hadn't had Ubuntu modifications - sync up to Debian import freeze
<cjwatson> it's different when somebody has taken active ownership
<ari-tczew> cjwatson: I agree.
<slangasek> SpamapS: ping
<SpamapS> slangasek: pong hey. :)
<SpamapS> slangasek: so, the restart action..
<slangasek> yes!
<SpamapS> slangasek: in discussing with keybuk, he made it clear that it is intended to restart the job *without* reloading the job file.
<slangasek> SpamapS: "it is intended" under what circumstances?
<slangasek> I mean, that's what the 'restart' command is designed to do, right?
<slangasek> but those are not the defined semantics of the init script interfaces
<SpamapS> slangasek: right, it is designed to restart the job, without reloading the job config...
<slangasek> and /lib/init/upstart-job accounts for this by calling stop && start instead of calling restart
<slangasek> *because* we need to make sure we're forcing a reload of the job
<SpamapS> It does.. oook.. good.
<SpamapS> For some reason I thought it used the restart action.
<slangasek> nah - I had this conversation with Keybuk a while ago :-)
<SpamapS> slangasek: well glad I could occupy some of your brain-space for a few minutes. Carry on then.
<slangasek> SpamapS: glad to help :)
<kees> ari-tczew: nvclock> sounds fine; much easier that way.
<ari-tczew> kees: about nbd: OK, Agreed with sync in natty+1. However, probably natty is affected by CVE and I'll prepare debdiff in CVE's bug.
<ari-tczew> kees: about openssl: I'll _TRY_ to update d/changelog, but it seems to be hardcore to do
<ari-tczew> kees: and now we are entering in problem: developers prefer to upload changes to archive without describe changes in details like e.g. d/rules: foo bar
<ari-tczew> just 'foo bar' without describing changes in which files done
<cjwatson> and that's perfectly reasonable
<ari-tczew> cjwatson: what?
<cjwatson> people who need that level of detail can look in a VCS - changelogs are a little bit more user-focused
<kees> ari-tczew: nbd> yeah, the CVE fix is appreciated. I'd like to know how far back it goes, though.
<cjwatson> while I do sometimes mention individual files in debian/changelog, I normally only describe the functional change made
<kees> ari-tczew: openssl> yup; that's why merging can be difficult. unless you can understand and explain each change, it's not a good idea to just cargo-cult them forward.
<kees> cjwatson: for merges, I like having the mapping.
<cjwatson> I don't usually object when people include it, but it is in no way a requirement
<ari-tczew> cjwatson: very very good solution! (sarcasm), now while merging contributor wastes time to looking about information changes, congrats
 * cjwatson ignores ari-tczew in order to avoid breaching the code of conduct.
<kees> ari-tczew: there's no need for that tone. developers each have their own preferences and time constraints.
<ari-tczew> what breaching? I'm just telling the true
<ari-tczew> sometimes it might hurt, though
<kees> ari-tczew: I happen to prefer verbose merge logs, as it helps me review the work since I'm rarely a primary maintainer for packages.
<kees> it's not a waste of time to understand the changes in a package when doing a merge.
<ari-tczew> kees: bullshit
<ari-tczew> I call this way an egoism
<ari-tczew> I won't describe changes in details because someone else will do it while merging.
<kees> I think you misunderstand the motivation.
<kees> I happen to disagree with cjwatson's opinion on the level of detail, but that doesn't mean either of us is wrong.
<cjwatson> for example, here's one of my changelog entries:
<cjwatson>   * Use a separate build directory, eliminating the requirement to preserve
<cjwatson>     some files by hand.
<cjwatson> I don't see that that would gain anything by enumerating all the little details, and it would be a lot of noise for users.
<ari-tczew> cjwatson: normal uses usually don't understand that specific changes
<cjwatson> (This was a changelog entry written for Debian, but I write Debian and Ubuntu changelog entries essentially the same way and I happen to think that that's a good thing.)
<cjwatson> People who need to know the exact details can look in a VCS, which is more convenient for that anyway.
<kees> and I'm saying I prefer details for when package deltas get large.  e.g. lvm2 mdadm
<ari-tczew> anyway, it's egoism
<cjwatson> In some cases it can be useful, certainly
<cjwatson> I just don't agree with mandating it in all cases; I've found that the cases where I need it are rare
<ari-tczew> kees: so I have to more time for update d/changelog and I'll do it at the weekend because someone else WAS LAZY to do it appropriate
 * ari-tczew True hurts, not breaking Code of Conduct.
<kees> ari-tczew: you're making a judgement about cjwatson's opinions. I don't recommend doing that for anyone.
<ari-tczew> kees: I'm just pointing what is wrong in development flow of work.
<kees> ari-tczew: this is not a black and white issue. it's not wrong, it just makes merging later somewhat more difficult if you're unfamiliar with the package.
<ari-tczew> but what do I know, I'm not developer with 10 years expierence
<cjwatson> and honestly, nobody who doesn't make themselves fairly familiar with, say, grub2 is going to be able to merge it correctly anyway
<cjwatson> so I've deliberately gone for trying to be a bit more concise there, while still describing the changes adequately to explain the differences versus Debian
<cjwatson> not every piece of explanation needs to live in the changelog; it can often quite reasonably live elsewheree
<cjwatson> aiming for concision in changelogs doesn't imply (in the extreme) writing comment-free ultra-obscure code just because you like it that way
<ari-tczew> cjwatson: do I like? kees as sponsor requires it from me
<smoser> i guess i'm missing something.
<kees> smoser: ?
<smoser> i bzr branch lp:ubuntu/natty/udev
<smoser> cd udev
<smoser> bzr bd -S ... sbuild -d natty-amd64 --arch-all ../udev_165-0ubuntu3.dsc
<smoser> build fails unable to find linux/videodev.h:
<ari-tczew> smoser: v4l is dead.
<ari-tczew> smoser: you have to port package to support v4l2
<smoser> hm.. i see i'm out of date. maybe i need to try with 166-0ubuntu1  which isn't synced yet to bzr repo
<smoser> ari-tczew, i just want to build it. should not the above basically rebuild ?
<poolie> hi smoser
<ari-tczew> smoser: probably rebuild will result in FTBFS
<smoser> hi poolie
<ari-tczew> since linux/videodev.h is no longer supplied by linux-libc-dev
<ari-tczew> zul: you might be interested in comments on https://code.launchpad.net/~ssalley/ubuntu/natty/likewise-open/likewise-open-fix-716615/+merge/49458
<jdong> cjwatson: what's your opinion on the suitability of the natty patch for bug 232557 for SRU?
<ubottu> Launchpad bug 232557 in ConsoleKit "console-kit-daemon leaks memory" [Unknown,Confirmed] https://launchpad.net/bugs/232557
<jdong> I just happened to run across a particularly horrendous occurrence of this bug leading to console-kit-daemon using close to 6GB memory
<jdong> looks like the git patch is http://cgit.freedesktop.org/ConsoleKit/commit/?id=7b9212fa6aff55420c58f2cacd0a941762920337 from andersk
<cjwatson> jdong: I haven't looked at the patch (not at my laptop), but your description of the problem sounds SRUable to me
<jdong> cjwatson: *nods* Indeed the bug itself is IMO SRU-able, just the FDO bugzilla discussion worried me in that andersk seems to still express a correctness concern over the patch (e.g. a potential use-after-free)
<jdong> but seeing how upstream accepted it into their latest release.... *shrug*
<broder> jdong: did upstream end up taking Anders' followup _ref/_deref patch?
<jdong> broder: I couldn't find evidence of that in git :-/ and the FDO bug didn't have any comments after that one.
<jdong> https://bugs.freedesktop.org//show_bug.cgi?id=26227
<ubottu> Freedesktop bug 26227 in Daemon "Memory leak" [Normal,New]
<broder> ugh
<RoAkSoAx> kirkland: do you want timestamp in the logging for testdrive?
<kirkland> RoAkSoAx: sure!
<andersk> I posted another comment to poke upstream about that potential use-after-free.
<jdong> andersk: thanks
<chrisccoulson> slangasek, re bug 439007 - the retracer doesn't run on any firefox crashes now, as they all go directly upstream since lucid (using breakpad)
<ubottu> Launchpad bug 439007 in firefox-3.5 (Ubuntu) "firefox crashed with SIGSEGV" [Undecided,Incomplete] https://launchpad.net/bugs/439007
<slangasek> chrisccoulson: well, that was reported pre-lucid, and anyway having them sent upstream doesn't help us any with triaging that bug report...
#ubuntu-devel 2011-02-16
<RoAkSoAx> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: open | 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 | Current Friendly Patch Pilots:
<RoAkSoAx> kirkland: in a bit will be uploading testdrive
<kirkland> RoAkSoAx: cool
<kirkland> RoAkSoAx: i'll blog the notifier thing ;-)
<kirkland> RoAkSoAx: that's going to be great!
<RoAkSoAx> kirkland: indeed!! also jcastro requested to add quicklist support for available isos for Unity
<kirkland> RoAkSoAx: cool
<RoAkSoAx> kirkland: uploaded. Should be building soon
<kirkland> RoAkSoAx: \o/
<RoAkSoAx> kirkland: alrighty it is build, not yet published though. What's gonna happen, is that around 5 seconds after you first started it will check if there are any available ISO's and display the notification if it does/. Otherwise will continue check every 1 hour for now. Later on I'll make that configurable
<kirkland> RoAkSoAx: that's totally awesome!
<RoAkSoAx> kirkland: let me know, as always, if how it goes :D.
<RoAkSoAx> im gonna go grab something to eat in the meanwhile
<psusi> hallyn, you recently changed multipath-tools to use 'path' instead of 'p' to separate base device from partition number.  why is this?  Where do these rules come from about what to separate with?  dmraid has been using 'p' for some time, but Curtis Gedak ( gparted maintainer ) has told me that it should only add the p if the base name already ends in a number
<hallyn> psusi: using path instead of p comes from the debian packages
<psusi> hallyn, ohh, so they added the patch and you just merged it?  any idea why?  it seems it will screw things up...
<psusi> there are several components that all seem to be building the names differently when they should be agreeing... kpartx adds 'p' only if the last character of the base name is a digit... recent versions of dmraid always add the p, and now it seems that this init script got changed to tell kpartx to use part instead of p... it doesn't make sense
<RoAkSoAx> kirkland: still around?
<hallyn> psusi: no they didn't add the patch.  They don't use that rule
<psusi> hallyn, so what did you mean it comes from the debian packages?  why was it changed from p to part?
<hallyn> psusi: the p had come from me by mistake.  debian uses part
<hallyn> see for instance debian/kpartx.udev in lp:debian/experimental/multipath-tools
<kirkland> RoAkSoAx: halfway here
<psusi> hallyn, why?  upstream kpartx and dmraid just use the letter p
<RoAkSoAx> kirkland: quick thingy: I'm planning to add something like this additionally to the MessagingIndicator: http://me.roaksoax.com/notify.png What do you think?
<kirkland> RoAkSoAx: looks great
<hallyn> psusi: I don't know why.  because it looks less SunOS4.x-y ?
<hallyn> psusi: but I just wanted to make it consistent
<RoAkSoAx> kirkland: cool, will do in the next release then
<psusi> hallyn, that's my problem... I am seeing 4 different programs that all have a different way of doing it now which messes things up... they need to all agree
<hallyn> psusi: my change was just to the initramfs/local-top script wasn't it?
<psusi> hallyn, sounds like it
<hallyn> psusi: yes, they need agree
<hallyn> psusi: I wonder where is the best place to get all the relevant people together
<psusi> email :)
<kirkland> RoAkSoAx: just upload again ;-)
<hallyn> psusi: but which list?
<psusi> I'm working up a message to dm-devel right now... probably should figure out a few more places to add to the Cc
<psusi> maybe the debian maintainer of multipath-tools?
<hallyn> sounds good.
<psusi> it seems that gparted likes the method upstream kpartx uses of adding just a p and only if the base name ends in a digit.. it goes so far as to explicitly tell dmraid to NOT use any character rather than letting the new versions always add the 'p'
<psusi> I guess I'll include Curtis as well then...
<psusi> you want on it?
<hallyn> yup, i personally coudl care less, but I know that if you install a multipath lucid system, it will use -partX right now
<hallyn> well, i'm on dm-devel, but wouldn't mind a copy to make sure i don't miss it
<psusi> what's your addy?
<hallyn> (i'm pretty ruthless with mailing list email in the morning)
<hallyn> serge.hallyn@ubuntu.com
<hallyn> thanks
<tomreyn> hi
<tomreyn> with this backtrace, which package do i file a bug against?       http://paste.ubuntu.com/567540/
<hallyn> pulseaudio?
<tomreyn> ah so not libopenal1
<hallyn> no, yeah, i'd start with libopenal1
<hallyn> openal-soft is the name of the package looks like
<tomreyn> I have no package of the name "openal-soft" installed, though
<tomreyn> maybe that's the upstream name
<RAOF> That's the source package name; it generates libopenal1
<tomreyn> thanks guys/gals
<yellowblue> sup niggas im true gangsta
<yellowblue> !ops
<robertzaccour> can i attatch a video to a bug report?
<robertzaccour> I want people to see exactly what I'm experiencing here
<persia> robertzaccour, You could, but folks may not want to download it: you'd do better to try to describe in detail, perhaps with before and after screenshots or similar.
<robertzaccour> well I'm reporting compiz and gtk-recordMyDesktop not playing well together
<robertzaccour> whenever I do a screen recording with compiz on, it totally bugs out
<robertzaccour> some apps like docky require compiz. both docky and gtk-recordMyDesktop are in the repos
<robertzaccour> Whenever I do a screen recording with gtk-recordMyDesktop and compiz running at the same time, which it does by default, The recording is always very buggy and still-framed for the most part and crazy mixes of coloring. Some applications (that are in the repos) require compiz to run properly e.x. docky. Since compiz and gtk-recordMyDesktop are both in the repos, I do believe this qualifies as a bug.
<persia> Ah, yes, in that case, attaching the result video may be useful :)
<robertzaccour> persia, its been a few minutes since i clicked submit but with the video attatched, and its still not paged over
<robertzaccour> oh it just did good
<robertzaccour> #719818
<mneptok> !bug 719818
<ubottu> Launchpad bug 719818 in compiz (Ubuntu) "compiz doesn't play well with gtk-recordMyDesktop" [Undecided,New] https://launchpad.net/bugs/719818
<mneptok> taa-daa!
<robertzaccour> mneptok, :) now i know thanks
<ikonia> robertzaccour: it may do you well to read the topic of this channel
<ikonia> robertzaccour: this channel is not for bug reporting or support
<robertzaccour> I have a feeling I might just be screwed based on my GPU. No issues in windows so I figured it might be fixable
<robertzaccour> ikonia, maybe someone here knows how to fix drivers? This is a developers channel
<ikonia> robertzaccour: no, I just said, this is not a support or bug channel, it's a development discussion channel
<robertzaccour> you remind me of a youtube comment tracker
<persia> ikonia, Maybe nice to redirect to -bugs for this sort of thing?
<ikonia> persia: I told him to read the topic
<ikonia> the topic tells him where to go
<ikonia> he found it
<persia> I suppose.
<ikonia> the guy wasted hours in #ubuntu not listening to help yesterday *UK time*, he needs to stop randomly doing things and start listening
<persia> Ah.  The background makes all clear :)
<pitti> kees: maxsize> it's not any more actually; just if I change it, people might get dpkg conffile questions a lot..
<kees> pitti: but you'll have to do an update for rc to enable apport, yes?
<pitti> kees: "disable", yes
<kees> couldn't you fold it into that?
<pitti> kees: I could change it at any time, but that doesn't change the fact that the conffile in the RC would suddenly change for upgraders who ever touched it
<pitti> I guess it's a pain we have to take at some point
<pitti> or I could actually make it work again :)
<kees> no, I don't like maxsize. :)
<kees> I like 3/4 memory, though the error could be improved.
<kees> pitti: this all stems from me looking at bug 718635
<ubottu> Launchpad bug 718635 in apport (Ubuntu) "Error message "Your computer does not have enough free memory" when core dump or stacktrace failed to be created is misleading" [Low,Incomplete] https://launchpad.net/bugs/718635
<persia> Does apport consider cache/buffers free when calculating "free memory" for that purpose?
<kees> persia: yup
<kees> persia: see my later comments showing the calculation
<kees> slangasek: should bug 716703 be counted on the arm porting jam?
<ubottu> Launchpad bug 716703 in chromium-browser (Ubuntu Natty) "chromium-browser not built PIE on ARM" [Medium,Confirmed] https://launchpad.net/bugs/716703
<persia> Ah, cool.
<pitti> persia: it looks at /proc/meminfo, and uses (MemFree + Cached - Writeback) * 1024 * 3/4 as a limit
<slangasek> kees: yes - it's there on the list
<kees> slangasek: oh, so it is! I hadn't noticed the tag get added
<kees> persia, pitti: actually, I guess it doesn't subtract buffers
<dholbach> good morning
<didrocks> good morning
<iqbal> anyone use lammp?
<iqbal> i have a problem
<iqbal> no lampp folder in /opt
<iqbal> but apache php and phpmyadmin run
<iqbal> morning didrocks
<didrocks> morning iqbal
<iqbal> are you install lampp on ubuntu
<iqbal> ?
<poolie> vila, hi, i'm just updating https://dev.launchpad.net/LEP/BuildFromBranchIntoPrimary and am going to circulate it later
<poolie> if you would care to look over it now and point out any questions that would be nice
 * vila reads
<vila> poolie: I had some notes and after re-reading they still seem valid: http://paste.ubuntu.com/567571/
<vila> grr, no line breaks
<poolie> it's ok
<vila> http://paste.ubuntu.com/567573/
<poolie> by 'build based on a revision property' you mean at commit time you'd say whether it should be built or not?
<poolie> interesting idea
<vila> yes
<poolie> if that's when we want to make the decision, we could equally well say that if there is a changelog entry it will build
<vila> one way or another, the dev decides what should be built, istm he knows that when he commits or he can still decide after the fact by doing a changeless commit and pushing it
<poolie> either that or an api call
<vila> there may be a grey area if he ``push --overwrite`` though but that could guarded against with append_revisions_only
<poolie> probably doing it off the commit is cleaner
<vila> and trackable
<vila> and gives if we can find a place to put the revid in the build artifact we also get a way to retrieve the source
<vila> s/gives//
<GunnarHj> Hi all,
<GunnarHj> Suddenly I have no longer web access to lp:language-selector. Anybody who can tell why? Maybe somebody who don't want me to propose more mergers...
<vila> note to self: add a semaphore between writer and reviewer when chatting
<ricotz> diwic, hi :), will alsa 1.0.24 be in natty?
<diwic> ricotz, that's the plan
<diwic> ricotz, do you have any personal preference, and why?
<ricotz> diwic, currently i dont really need it, but i am running your ppa packages without any complains, and since the last alsa upstream is one year old, it should just be updated
<diwic> ricotz, ok, yesterday I realized that I forgot to include alsa-driver as well, I'll package that today or tomorrow hopefully
<ricotz> diwic, great, perhaps it is usefull to use dh-autoreconf to avoid shipping a relibtoolize patches, but this might be coordinated with debian maintainer
<diwic> ricotz, something like that - how to package autotools is a complete science :-/
<diwic> ricotz, but I'm all for skipping large crazy diffs
<ricotz> diwic, shouldnt be so hard adding it, i havent looked at the alsa packaging lately, did you talk to jordi mallach yet?
<diwic> ricotz, I talked to the pkg-alsa-devel ML, Elimar has answered but not Jordi
<ricotz> diwic, you can find him in #debian-gnome on oftc
<jibel> latest util-linux in Natty looks broken, bug 719754 , anyone taking care of it ?
<ubottu> Launchpad bug 719754 in util-linux (Ubuntu) "package mount 2.17.2-3.3ubuntu4 failed to install/upgrade: subprocess new pre-installation script returned error exit status 127" [Critical,Triaged] https://launchpad.net/bugs/719754
<jibel> lool, ^
<mdz> pitti, is it appropriate to submit new devices to media-player-info these days? my phone isn't listed
<lool> jibel: uploading, thanks
<RAOF> mdz: I'm pretty sure that's still used by applications; it uses udev rules and I think banshee uses that info.
<mdz> RAOF, yes, it's definitely still active, but every few months or so it seems there is a new Right Way to Do It :-)
<RAOF> Too true!
<apw> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: open | 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 | Current Friendly Patch Pilots: apw
<mdz> howdy apw
<apw> morning
<pitti> mdz: yes, of course; usually to https://bugs.freedesktop.org/enter_bug.cgi?product=media-player-info (launchpad works as well, though)
<mdz> pitti, thanks!
<apw> pitti, i think you looked at the UDF DVD issue -- bug 635499
<ubottu> Launchpad bug 635499 in linux (Ubuntu) "[Maverick, Lucid] Does not show UDF contents" [Undecided,Confirmed] https://launchpad.net/bugs/635499
<apw> specifically it seems that later version of windows are using rrr on directories ...
<apw> looking at the spec it appears we are actually doing what is mandated by the spec
<apw> ie, the are 'wrong'
<apw> (the disks are mastered incorrectly) ... now do we want to override that for RO media ?
<pitti> argh, that sounds tricky -- can we add permissions in mount options as well? or just remove them a la fmask, dmask?
<apw> pitti, you can override all permissions for a directory for instance yes
<pitti> ah, mode= and dmode=, I didn't know about that one
<apw> pitti, yeah we have a hammer for it.  udf appears to be a format which can be used on writable media in theory; though i have never heard of doing it
<apw> so if we are doing somethign like that then we might want to do it for 'read only' 'removable' media only or something
<pitti> apw: I did actually; isn't that what you would usually do on packet writing CDs/DVDs?
<pitti> you can't use iso9660 on them
<apw> that is possible, packet writing is mentioned, though i was thinking of real 'rewriable' metia such as hard-drives which are mentioned in this spec too
<apw> pitti, so i'll write up what the spec says, to confirm that us failing to read a 444 directory is what the disk asked us to do
<apw> i guess the logical thing to do is do it in udev or something?
<pitti> apw: mode/dmode isn't documented yet in mount(8) as it seems; but apparenlty it has worked for a while now
<apw> udisks even
 * dholbach hugs apw
<pitti> apw: udisks, yes
<apw> dholbach, thanks :)
<dholbach> thank YOU :)
<pitti> apw: I guess having 0400 for files is not a big problem, so we don't need to fiddle with "mode"?
<apw> pitti, if my reading of this bug is right, it seems to be 'worked with disks made before vista' and not since
<apw> its actually sounding like 'newer versions of UDF now support permissions bits'
<apw> pitti, hmm seems there is a bug in windows as the spec (which mentions windows specifically and how it implements permissions) it says that the execute bit should be honoured for directories only on windows ... hrm
<pitti> apw: that sounds confusing -- it shoudl be honoured on the system that gets them wrong?
<apw> yeah, as permissions on the disk are pretty unix'ey in semantics there is a table of how to map them in various OSs and specifically how they should be mapped to local permissions
<apw> and that says "file execute" is ignored on windows as there is no mapping for it, but directory execute is mapped and 'Enforced'
<apw> clearly not in reality of course else the disk would be the same there
<apw> pitti, ok i've pushd in the spec information, should i move it back to udisks do you thnk ?
<pitti> apw: thanks for the spec additions; I'll keep it on my radar and discuss with upstream for a fix in udisks
<apw> pitti, ack and thanks ...
* cjwatson changed the topic of #ubuntu-devel to: Archive: all uploads failing, LP team aware | 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 | Current Friendly Patch Pilots: apw
<cjwatson> if you get reject messages like http://paste.ubuntu.com/567617/, the LP team is on it
<Laney> does it affect all uploads?
<Laney> oh, /me didn't see the topic change
<ogra> cjwatson, http://people.canonical.com/~ubuntu-archive/component-mismatches.txt shows libqtbamf1 and libqtgconf1 binaries arent promoted, i only seeded unity-2d as the toplevel package, do i need to seed the launcher explicitly to get them into main or is that just a promotion issue ?
<cjwatson> that output is telling you that you got it right
<cjwatson> and that we just haven't promoted them yet
<cjwatson> I've promoted them now
<ogra> k, i thought so, just wanted to be sure its not something missing on my side
<ogra> thanks :)
<ogra> hmm, though it seems i need to seed unity-2d-default-settings. as transitional package it doesnt get pulled in by anything
<pitti> ogra: unity-2d-default-settings only exists in natty, why do we need it as a transitional packages? just for alpha-2 installs?
<ogra> pitti, for upgrades for people that had the maverick PPA
<pitti> ah
<pitti> ogra: they won't get unity-2d otherwise?
<ogra> though i think we should probably just do the transition there
<ogra> they will indeed
<pitti> ogra: I'd assume that "unity-2d" would be in the PPA as well then
<pitti> then natty's unity-2d could just conflicts/replaces: unity-2d-default-settings, to get it cleaned up on upgrade, and the package could go away entirely
<ogra> it is, and has the right breaks/replaces in natty
<pitti> Breaks: unity-2d-default-settings (<= 0.4)
<pitti> that should probably be bumped then
<ogra> i have to try an upgrade if everything in natty is in order to make sure everything is right
<ogra> PPA has 0.4
<pitti> ogra: I mean, if you want to ditch the unity-2d-default-settings transitional package entirely in natty, you'd need to bump the breaks/replaces version
<ogra> ah, yeah
<ogra> will do that with the next upload and after a test upgrade
* cjwatson changed the topic of #ubuntu-devel to: Archive: open | 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 | Current Friendly Patch Pilots: apw
<cjwatson> (uploads fixed, thanks wgrant)
<wgrant> cjwatson: Only yours was affected, FWIW.
<cjwatson> odd!
<cjwatson> oh, just nobody else uploaded in the relevant time window?
<wgrant> Right.
<seb128> cjwatson, did you read any recent issue with dpkg triggers?
<seb128> cjwatson, I'm trying to make sense of a issue which started being reported recently where the gdk pixbuf svg loader doesn't work on new installs
<seb128> neither gdk-pixbuf or librsvg got an recent upload and the gdk loaders index is built in the libgdk-pixbuf postinst or refresh by a trigger when a loader is installed
<seb128> but it seems the svg loader is missing from the index somehow
<seb128> not sure how that could happen out of having the trigger not triggering
<cjwatson> the only issues I've heard of are ones where some package management frontends don't give apt/dpkg a terminal, which tends to result in triggers failing when they try to output anything
<cjwatson> but that causes hard failures, not didn't-trigger
<seb128> hum k
<seb128> cjwatson, ok, I think I found a clue on the livfs build log
<seb128> "libpixbufloader-svg.so: libGL.so.1: cannot open shared object file: No such file or directory"
<seb128> seems that's because the libgdk postinst is configured first and the libGL ldconfig is not done yet
<seb128> what is the right way to deal with that? use a pre-depends to ensure libGL's ldconfig call is set before the libgdk-pixbuf install?
<cjwatson> pre-depends would be wrong.  that causes configuration to happen before another package is *unpacked*
<cjwatson> anyway, it has no effect on triggers, which is what's happening here
<cjwatson> I'd suggest changing libGL to do 'LDCONFIG_NOTRIGGER=y ldconfig'
<cjwatson> (whatever package provides it)
<cjwatson> with a comment saying that we need to force this to happen immediately so that other packages are happy, or some such
<pitti> barry: may I prod you about the computer-janitor pygi branch again? I just updated it to yesterday's upload, so it merges cleanly again
<seb128> cjwatson, well, in that case the call which fails is the libgdk-pixbuf-2 post installation script one
<seb128> cjwatson, so the pre-depends would fix it but there would still be the trigger case to be buggy, I think it's better to do what you suggest, thanks
<seb128> tjaalton, bryceh, Sarvatt: ^
<cjwatson> seb128: pre-depends wouldn't fix it because pre-depends on package A doesn't wait for triggers pulled by A to have happened
<seb128> cjwatson, right, but it would assure the package is configured first, which is needed if that's the post install script which calls ldconfig?
<cjwatson> seb128: the postinst calls ldconfig, but ldconfig is a wrapper script nowadays; when called from a maintainer script, it normally only pulls the trigger and returns immediately
<seb128> cjwatson, or do we assure that the libgl ldconfig is done before the gdkpixbuf package is configured?
<cjwatson> if it needs to actually do ldconfig work immediately, that's what LDCONFIG_NOTRIGGER=y is for
<seb128> cjwatson, I got that, we need 'LDCONFIG_NOTRIGGER=y' and a way to assure the postinst for libgl is called first?
<cjwatson> Depends would be sufficient for that
<cjwatson> Pre-Depends just gets in other things' way
<cjwatson> actually, though, I suspect you don't need Depends
<cjwatson> I think the reason that ldconfig needs to be forcibly called here is that various things divert libGL.so.1
<cjwatson> which means that the cache is invalidated
<cjwatson> my suspicion is that there is no need for a Depends - all we need to do is ensure that anything that diverts a library and installs a replacement version of it calls LDCONFIG_NOTRIGGER=y ldconfig
<cjwatson> that way, you get one version of libGL or the other, not an error message
<seb128> cjwatson, ok, I though that it was not assured that Depends would be configured before the binary which Depends on those
<cjwatson> it's not, but you don't need that, that's what I'm saying
<seb128> well libGL is not in /usr/lib
<cjwatson> at least I don't think so
<seb128> it's a special dir, which is why it doesn't find it until ldconfig is called
<seb128> the ldconfig needs to happen before libgdk-pixbuf's postinst is called
<cjwatson> hmm, libgl1-mesa-glx.postinst already uses LDCONFIG_NOTRIGGER=y
<seb128> but it's run after the libgdk-pixbuf configuration...
<seb128> so when libgdk-pixbuf postinst runs the ldconfig is not right
<seb128> so it doesn't find the lib
<cjwatson> yes I know, I'm thinking out loud :)
<seb128> which is why I thoguh it would need a pre-depends
<cjwatson> pre-depends => pointless, forget it please
<seb128> ok
<cjwatson> Depends is enough unless it's circular
<seb128> should the libgdk-pixbuf call ldconfig before doing the gdk-pixbuf update?
<cjwatson> which it wouldn't be here
<seb128> hum, it already does it
<cjwatson> looking at this, I think Depends: libgl1 would be enough
<cjwatson> it's a bit nasty
<cjwatson> you get to choose between:
<cjwatson>  (1) artificial Depends: libgl1, to force the ldconfig cache to be brought up to date
<cjwatson>  (2) artificial 'LDCONFIG_NOTRIGGER=y ldconfig' in libgdk-pixbuf2.0-0.postinst, to cope with the fact that the ldconfig cache may not be up to date
<seb128> well, gdk-pixbuf shouldn't bring libgl, I can see some people not wanting it
<seb128> let's go for (2)
<seb128> cjwatson, thanks
<cjwatson> does libpixbufloader-svg.so dlopen libGL?
<seb128> yes
<cjwatson> that would explain the lack of an explicit dependency there
<seb128> would a librsvg2-common (which has the svg loader) depends on libgl work as well?
<cjwatson> it would, but wouldn't that have the same "people might not want it" thing?
<cjwatson> you could put (2) in librsvg2-common as an alternative, I suppose
<cjwatson> on pre-depends: it should only be used when you need some other package's postinst to have run before your package's preinst, or in rare cases before unpacking your package's filesystem tarball (creating users/groups)
<cjwatson> the problem with using it as a hammer to force other kinds of ordering is that it slows everything down by splitting things up into multiple dpkg runs, and it can create unresolvable loops
<cjwatson> (because Depends can be circular, but Pre-Depends can't)
<cjwatson> you can get particularly nasty Pre-Depends/Conflicts loops too
<seb128> ok
<cjwatson> so it's best to just confine its use to where it's necessary for stuff run in the preinst
<seb128> is there a way to say "this binary postinst should run before my postinst"?
<cjwatson> Depends
<cjwatson> as long as it isn't circular, that will do it
<seb128> ok, I though the unpackaging and configure order was not assured by depends
<cjwatson> A Depends: B says exactly that B must be configured (postinst run) before A
<seb128> that depends just assured that what you depends on will be installed
<cjwatson> before A is configured
<seb128> but not in which order
<cjwatson> Depends says nothing about unpack order
<cjwatson> but it very definitely says something about configure order
<seb128> ok, so issues I had in the past was with unpack orders
<seb128> I should re-read that part of the debian policy, it has been a while
<seb128> cjwatson, thanks!
<cjwatson> np :)
<smoser> stgraber, ping
<stgraber> smoser: pong
<smoser> http://www.stgraber.org/2010/12/08/want-your-own-edubuntu-weblive/ "Installation is relatively trivial, just follow the README file in the branch.".  but "ls: cannot access README: No such file or directory"
<stgraber> smoser: there's a README in the drupal-vmmanager branch, for the daemon part, there's packages for lucid, maverick and natty in my experimental ppa
<smoser> i was looking at lp:vmmanager
<sconklin> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: open | 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 | Current Friendly Patch Pilots: apw, sconklin
<apw> dholbach, you'll be pleased to know that the kernel bugs with patches backlog has been reduced from 99 -> 89 today, from 120 when the patch pilot activities started ... and the oldest not responded bug is down from 221 weeks to 66 weeks
<apw> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: open | 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 | Current Friendly Patch Pilots: sconklin
<apw> sconklin, have fun !
 * ScottK pokes at lamont about postfix 2.8.0.
<barry> pitti: sorry i haven't had time to review your branch yet.  but i will do that today for sure
<dholbach> apw, rock and roll!
 * csurbhi_ shall be back later
<GunnarHj> tedg: Hi Ted, are you there?
<tedg> GunnarHj, I'm in a phone call...  so kinda :)
<GunnarHj> tedg: Ok. Saw that you changed the status of https://launchpad.net/bugs/636693 to "Opinion" again. Could we talk about it, please? (after your phone call...)
<ubottu> Error: Could not parse data returned by Ubuntu: list.index(x): x not in list (https://launchpad.net/bugs/636693)
<superm1> pitti, it appears scour doesn't touch svg's at all right? bug 719735 seems really odd because the file is OK in the orig.tar.gz, but got busted in the binary deb somehow
<ubottu> Launchpad bug 719735 in dell-recovery (Ubuntu) "dell-recovery crashed with GError in __init__(): Couldn't recognize the image file format for file '/usr/share/pixmaps/dell-dvd.svg'" [Undecided,New] https://launchpad.net/bugs/719735
<pitti> superm1: it does touch svgs
<superm1> any thoughts on how that could have happened then?
<superm1> hmm actually it seems the binary deb itself is fine - there's an issue with opening svg's on natty then, i just checked with kent and it's not showing other svg's either properly
<hyperair> how does one retry a build in launchpad?
<hyperair> for a package that's not a PPA?
<ScottK> hyperair: The same was as a PPA, but you have to have upload rights for the package.  What do you need retried?
<hyperair> ScottK: gnu-smalltalk.
<hyperair> ScottK: i don't see a rebuild button, and it seems to be in universe
<ScottK> hyperair: Link me to the build page.
<hyperair> https://launchpad.net/ubuntu/+source/gnu-smalltalk/3.2-1/+buildjob/1735324
<hyperair> someone was complaining about the lack of an amd64 package in ubuntu
<Laney> you probably need to do a no-change SRU for that (as it's in release)
<hyperair> i see.
<hyperair> Laney: so should i make two uploads (natty and maverick-proposed), or should i just make one to maverick-proposed and have it copied forward?
<Laney> you can do the latter
<dupondje> could somebody check https://bugs.launchpad.net/ubuntu/+source/gtk-vnc/+bug/711442 plz. Need to get the patch in Natty :)
<ubottu> Ubuntu bug 711442 in vinagre (Ubuntu) "vinagre crashed with SIGSEGV in g_socket_send()" [Medium,New]
<Laney> if the versions are equal then it will be copied when it is accepted into proposed
<hyperair> oh nice
<seb128> dupondje, you should subscribe ubuntu-sponsors if you want a patch reviewed and sponsored
<ScottK> hyperair: I'd upload to Natty, make sure it builds OK and then do the SRU.
<ScottK> It doesn't have a retry button because it doesn't have a natty build record.
<dupondje> seb128: done
<seb128> dupondje, thanks
<dupondje> its a cherrypicked patch btw, so should be quite safe :)
<ari-tczew> cjwatson: there is a diff which could go into lilo by merging -10 revision: http://paste.ubuntu.com/567798/ what do you think, is it worth to merging?
<ari-tczew> TheMuso: is alsa 1.0.24 going to be in natty?
<ari-tczew> doko: do you know whether Debian is going to use gcc 4.6.* ?
<kees> ari-tczew: yes.
<TheMuso> ari-tczew: Yes, thats the plan.
<ari-tczew> kees: yes for?
<kees> ari-tczew: using gcc-4.6 in Debian
<ari-tczew> kees: ok
<mvo> csurbhi_: hey, I think we can mark the n-btfs-support implemented for this cycle
<kees> TheMuso: I find it very strange that we both unidled in this channel at exactly the same time. :)
<TheMuso> kees: Yeah thought the same when I saw your reply.
<ari-tczew> kees, TheMuso: in the first minute I thought that my connection is busy :-)
 * mneptok starts the "Kess and TheMuso are acutally THE SAME PERSON" rumor
<mneptok> Kees, even.
<kees> hehe
<tedg> GunnarHj, Unstacking... are you still around?
<fatninja> Jordan_U : I'm here.
<Jordan_U> fatninja: What experience do you have with programming in general?
<fatninja> Hm
<fatninja> Jordan_U : I'm a college student in first year in Computer Science, so it's not that good.
<fatninja> The interesting thing is, that after I run Wubi and restart to complete instalation everything works with Ubuntu just fine, after the first restart
<fatninja> It simply doesn't work, at first I thought that it cannot mount the NTFS Partition that I use
<fatninja> but if the loader couldn't do that, then it couldn't complete the instalation
<Jordan_U> fatninja: Then to be honest Wubi is probably not the best project to start contributing with. Especially this particular set of bugs will probablyy require working with many programming languages and advanced concepts.
<fatninja> I see..
<fatninja> Too bad NTFS isn't like HFS+ Extended, I can't resize it ...
<micahg> fatninja: you can resize ntfs
<fatninja> micahg that's what I said .
<mneptok> HFS. *snort*
<Jordan_U> fatninja: You should be able to resize hfsplus.
<sconklin> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: open | 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 | Current Friendly Patch Pilots:
#ubuntu-devel 2011-02-17
<slangasek> Riddell: ping
<Riddell> slangasek: I'm asleep
<slangasek> Riddell: then I suggest putting down the keyboard, you don't want to wake up with keyboard marks on your face ;)
<slangasek> Riddell: I was wondering what your take was on jcrigby's response that the kernel packages aren't really building the common headers package despite it being listed in debian/control.  Could these be accepted as-is with that explanation, or do you need us to get debian/control fixed up?
<Riddell> slangasek: oh aye, sorry, I ment to process that today, his explanation seems reasonable enough
<slangasek> Riddell: no worries! just wanted to make sure whether action was still needed on our side
<Riddell> slangasek: I'll accept it now
<slangasek> thanks! :)
<twb> Is there a way to point rmadison at the partners repo?
<cjwatson> twb: it already does by default
<twb> rmadison -uubuntu opera ==> no hits
<cjwatson> let me clarify that, it's already supposed to by default :-/
<twb> Is that an ubuntu-only patch to devscripts?
<cjwatson> rmadison talks to a server CGI script
<cjwatson> it's up to the server what it shows
<twb> Yeah, I thought maybe "by default" meant something bad like "we patched it to ask -uubuntu and -usomethingelse by default"
<cjwatson> -uubuntu is the default if you're running rmadison on Ubuntu, but that's all
<cjwatson> opera is genuinely not in partner
<cjwatson> https://launchpad.net/ubuntu/+source/opera/+publishinghistory
<cjwatson> try 'rmadison -uubuntu -S skype' instead as an example
<twb> Hmm.
<twb> http://archive.canonical.com/pool/partner/o/opera/
<twb> That existed, which confused me
<twb> skype works in rmadison, so it's A-OK
<ScottK> Opera used to be there.
<vorian> http://vorian-ubuntu.blogspot.com/feeds/posts/default
<nukem> hey im trying to compile the vanilla linux kernel using make-kpkg however every time make-kpkg goes to make the actual Debian package I get a really weird error
<nukem> it says dpkg-gencontrol: error: package linux-image-2.6.37-anfs+ not in control info
<nukem> i never added the +
<nukem> can someone please help me
<poolie> if it's the vanilla kernel why does it have the anfs+ suffix?
<nukem> I'm planning on adding some stuff to NFS(I havn't yet) so i added -anfs with the --apend_to_version arugment
<nukem> to + got there on its own
<nukem> which is really confusing me
<nukem> the only thing I can think of is because I did a git checkout of the kernel source
<poolie> i don't know, you'd have to trace into make-kpkg
<poolie> see where it's getting that version from
<nukem> so you think its a bug with make-kpkg?
<poolie> mm, not necessarily
<poolie> i wonder if you're meant to add that to the control file yourself
<nukem> when I used make-kpkg on Debian(awhile ago I admit) I just had to run make-kpkg
<poolie> just for curiousity, what is anfs?
<nukem> I'm working on a senior design project which will add redundancy to NFS
<nukem> RAID 1 like with multiple servers
<nukem> we're also adding encryption and compression
<poolie> interesting
<poolie> have you done make-kpkg clean after changing the option?
<nukem> every time
<poolie> maybe it's a bug there then
<nukem> hmm ill try debians kernel-package then
<poolie> nukem, are you doing that in-kernel
<poolie> personally i would be inclined to make a userspace client side proxy first
<poolie> of course maybe that's not interesting enough for your project
<nukem> it seemed easier to just add it to the kernel itself
<nukem> plus I really want to get more into kernel development
<poolie> it will be a bigger learning experience for sure
<poolie> probably harder to debug though
<startagainlol> elky here too darling
<mneptok> startagainlol: please stop.
<startagainlol> amazing somebody with manners
<mneptok> elky: did you just see that?
 * mneptok needs a reality check, STAT!
<poolie> amazing indeed
<Tm_T> prolly just got bored
 * mneptok waves maniacally at poolie 
 * elky blinks.
<dholbach> good morning
 * poolie waves more sedately
<elky> Exceedingly amazing considering the homocidally racist chant he had going.
<mneptok> elky: hold me. my reality is crumbling.
<elky> Just find someone else's to substitute.
<mneptok> i could probably borrow Jono's, but i'm not sure i want to live in a world of beer-dispensing electric guitars.
 * maco2 suspects dholbach is now very confused
<dholbach> hm
<dholbach> ?
<mneptok> dholbach: problematic user discussion.
<mneptok> dholbach: set the alarm for 10m later and you can avoid this. :)
<maco2> mneptok: nice euphemism
<didrocks> good morning
<dholbach> if you're on the ubuntu-sponsors mailing list, sorry for the spam - I'm reassigning old bugs from ubuntu-main-sponsors to ubuntu-sponsors, so we can get the team deleted
<cdbs> dholbach: that ain't spam :)
<cdbs> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: open | 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 | Current Friendly Patch Pilots: cdbs
 * dholbach hugs cdbs
 * cdbs hugs dholbach 
<jibel> cjwatson, ev when you have a minute can you look at my comments (21,22) in bug 650703 . I think the problem comes from the upstart job which starts too early and there's a race for some reason. Now I don't know the right fix.
<ubottu> Launchpad bug 650703 in ubiquity (Ubuntu Lucid) "oem-config-prepare works, but oem-config fails to start after reboot" [High,Triaged] https://launchpad.net/bugs/650703
<ev> jibel: will do, thanks
<lool> barry: computer-janitor-gtk depends on gir1.2-pango-2.0, but probably you meant gir1.2-pango-1.0?
<dholbach> lool, where we go there's no room for "1.0" versions!
<dholbach> lool, comment Ã§a va? :)
<lool> dholbach: Good good  :-)   you?
<dholbach> great :)
<lool> bah can't commit to the Vcs branch
<dholbach> mvo and pitti maybe can?
<lool> Ah didn't think of pinging mvo on that one
<lool> pitti didn't seem to be around today
<ogra> just upload, merge later ?
<lool> ogra: I've uploaded commenting out Vcs-Bzr, yes
<ogra> tsk
<ogra> Riddell, is teher any trace of the new QT soon ? i really need NEON runtime detection now that unity-2d is on the armel images
<janimo> ogra, upstream bugtracker shows 3 more bugs that need to be fixed
<ogra> hrm
<janimo> but that is the case for the past weeks I think
<ogra> janimo, thanks
<Riddell> ogra: doesn't seem to be
<ogra> do you think it will arrive in time for natty ?
<Riddell> I would expect so yes
<ogra> or should we look at backporting the patch
<ogra> iirc rsalveti pointed to a patch with only a few lines
<Riddell> or just package a git snapshot
<janimo> right
<Riddell> also "Qt" :)
<ogra> afaik the autodetection hasnt been tested even upstream yet
<ogra> so getting it in asap would surely help
<rsalveti> and maybe get it working for non neon devices for alpha 3
<ogra> ++
<ogra> so git snaphot would be good. yeah
<ScottK> How about git snapshot in a PPA?
<ScottK> Tossing semi-random Qt git snapshots into the archive is not a recipe for success, IMO.
<ogra> ScottK, doesnt help building images
<ogra> we really need that feature tested on the current images
<ScottK> ogra: No, but it can be used to test NEON support.
<ogra> well, if its clear that it makes natty a git snapshot wont do harm imho
<ScottK> There are a LOT of packages in the archive that use Qt and we ought to be careful about introducint non-released versions of it.
<ogra> if that isnt clear indeed then we should instead start backporting and testing the fix
<ogra> in any case feature freeze is soon and we need it working
<ScottK> I disagree it's OK to upload an untested Qt snapshot because it will get fixed eventually.
<ogra> its a development release
<ScottK> It won't work any better in the main archive than in a PPA test package.
<ogra> if the bugs are fixed by release it should be fine
<ScottK> There's no need to potentially break a lot of unrelated things and affect other people's work to see if this is fixed.
<hallyn> jdstrand: jumping from libvirt 0.8.7 to 0.8.8, debuild gives me:
<hallyn> dpkg-source: error: cannot represent change to libvirt-0.8.8/po/hr.gmo: binary file contents changed
<hallyn> (lots of those)  what's the normal way to handle that?
<jdstrand> hallyn: are you using the pristine upstream tarball?
<hallyn> jdstrand: yes, as fetched by 'uscan'
<jdstrand> hallyn: so, you should snag the upstream tarball, rename it libvirt_0.8.8.orig.tar.gz, untar it, drop debian/ into it, adjust debian/changelog, and then use debuild -S -sa
<hallyn> i thought that was what uscan did
<jdstrand> hallyn: actually, debuild -S -sa -v0.8.5-0ubuntu5
<jdstrand> hallyn: I've not used uscan enough to advise on its use
<hallyn> ok.  trying manual
<hallyn> -v?
<jdstrand> hallyn: that makes sure that the changes file has all the changes since that version
<jdstrand> hallyn: it is useful for merges with Debian for example, where we want apt-listcahnges and update-manager to show all the changes
<jdstrand> since the last version in Ubuntu
<jdstrand> hallyn: you might want to look at 0.8.7-2 from Debian, and merge in those changes, rather than just grabbing 0.8.8 and using the updated ubuntu debian/ directory
<smoser> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: open | 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 | Current Friendly Patch Pilots: cdbs, smoser
<jdstrand> hallyn: http://packages.debian.org/changelogs/pool/main/libv/libvirt/libvirt_0.8.7-2/changelog
 * dholbach hugs smoser
<smoser> dholbach, is that an automated response ? i feel like i'm getting a hug from a machine :)
<dholbach> man - that's an original dholbach hug
<dholbach> a machine, tststs :)
<mvo> hallyn: I tend t use bzr-builddeb that automatically puts stuff into a build dir (and uses uscan if there is a tarball missing). very convinient IMO
<hallyn> jdstrand: ok, my first version (without -v, as i'd started before you said that) seemed to succeed.  Which makes me wonder what the heck uscan does beyond what i need it to
<mvo> d'hugmachine'holbach
<hallyn> mvo: last time i tried a major new release merge (in qemu) with udd i got into trouble :)  so until i have more time to devote to it, i'm doing it the non-udd way
<hallyn> mvo: i'll try it again,j ust not this week
<mvo> hallyn: yeah, its quite different from the "normal" workflow, but once you get used to it I found it to be a real time-saver
<mvo> (except for the slow initial setup when getting the branch(es) ready)
<jdstrand> mvo: libvirt is source format v3 quilt
<jdstrand> and we've not been able to get that working right with udd
<hallyn> mvo: I really like it for bugfixes
<jdstrand> (we as in us libvirt mergers)
<mvo> jdstrand: aha, indeed
<hallyn> jdstrand: i wonder how much ive been messing things up by not doing -sa and -v
<hallyn> anyway, that worked.  shoulda done that from the start i guess
<hallyn> jdstrand: thanks
<jdstrand> hallyn: -sa ensures that the orig.tar.gz is uploaded. It may be added automatically with -0ubuntu.. and -1. I don't recall off-hand. -v isn't critical, but nice
<barry> lool: i grabbed that dependency from pitti's branch.  i should have checked that more closely.  i see your fix this morning - thanks for that, i'll merge it and make sure you can commit to the branch
<jdstrand> hallyn: so looking at the Debian changes, I think the way to go is -> perform 0.8.7-2 merge with Debian and get the debian/ dir in order, then create 0.8.8-0ubuntu1 based on the merged debian/ dir
<lool> barry: ty
<jdstrand> hallyn: what do you think?
<jdstrand> (it is certainly what I would do)
<jdstrand> hallyn: if we don't, we'll be diverging pretty far from Debian
<lool> barry: Just tested the fixed packages, start fine; I've spotted a minor issue with them: (computer-janitor-gtk:29179): Gtk-WARNING **: Could not load image 'computerjanitor-24x24.png': Impossible d'ouvrir le fichier Â«Â /usr/share/computer-janitor/computerjanitor-24x24.pngÂ Â»Â : Aucun fichier ou dossier de ce type
<lool> barry: This seems to be missing from debian/computer-janitor-gtk.install
<hallyn> jdstrand: i think...  that sounds like in the short term making a lot of work for ourselv es given that we have a working build
<hallyn> jdstrand: but long term it may pay off
<lool> barry: Hmm actually, the issue is that the .ui uses the 24x24 filename instead of just computerjanitor
<hallyn> jdstrand: I'm goign to upload what I have now to people.canonical.com.  When I finish some other stuff I"ll look at the debian package
<jdstrand> hallyn: well, that is the nature of merges. I think you have permanently forked qemu-kvm iirc. That is not normal operating procedure, and I personally have strived to stay close to Debian
<jdstrand> hallyn: and by 'you' I mean the server team
<jdstrand> hallyn: but since you, hallyn, work on that and libvirt primarily, it might seem like a not bad idea...
<hallyn> jdstrand: yes, I do prefer being close to debian for many reasons.
<hallyn> I'm just saying I don't have time for that right now
<jdstrand> hallyn: the problem is that things will get very weird if we upload an 0.8.8-0ubuntu1 without Debian's changes, and then 0.8.8-0ubuntu2 that does
<hallyn> jdstrand: how far have we diverged so far?
<jdstrand> hallyn: I wasn't aware that Debian had 0.8.7 until Daviey mentioned it this morning
<hallyn> hm
<jdstrand> hallyn: 0.8.5-1 entered experimental in November
<hallyn> all right, then I guess forgetabout what I've uploaded so far
<jdstrand> hallyn: our 0.8.5-0ubuntu1 predated that
<hallyn> I'm 100% in favor of reducing packages for which we have to have custom bug handling :)
<barry> lool: gotcha, i'll check that too
<jdstrand> hallyn: so we did the right thing in november. but they have 0.8.7 now, we don't. the right thing to do is to merge, then pull in 0.8.8
<hallyn> jdstrand: any good reason not to just merge 0.8.7 and ask debian to take any other patches we need on top of that?  (like the arm tests failures)
<jdstrand> hallyn: would you have time before FF?
<hallyn> jdstrand: iow, ignore 0.8.8 for now
<hallyn> jdstrand: is that next tuesday?
<jdstrand> hallyn: we should be pushing everything back if possible
<jdstrand> hallyn: they don't have apparmor yet, so those can be skipped
<hallyn> jdstrand: I don't know, bc you have a boatload of patches in there :)
<jdstrand> hallyn: that boatload predates me btw :)
<hallyn> <sigh>  I"ll aim to do that tomorrow
<hallyn> ok, s/you/our libvirt package/ :)
<jdstrand> hallyn: hehe
<jdstrand> hallyn: but giving everything back to Debian is another issue
<hallyn> jdstrand: yes, I like the fact that this roadmap makes it *feasible* to send the patches back to debian
<jdstrand> hallyn: that is long-standing
<hallyn> (so far it hasn't been)
<lool> barry: LP #720743
<hallyn> all right, i put that in my tickler file for tomorrow.
<ubottu> Launchpad bug 720743 in computer-janitor (Ubuntu) "Could not load image 'computerjanitor.png'" [Undecided,New] https://launchpad.net/bugs/720743
<jdstrand> hallyn: it has been difficult because we have been ahead of Debian a lot with that package
<barry> lool: thx!
<lool> barry: I'm thinking the quickest way is adding the 24x24 to the setup.py + gtk.install file
<lool> but that might not be the most correct way
<hallyn> cjwatson: the grub2 in qemu with VBE bug (bug 717445) is bisected down to the offending commit, fwiw
<ubottu> Launchpad bug 717445 in grub2 (Ubuntu Karmic) "grub2 in lucid doesn't work in qemu with '-vga std'" [Medium,Confirmed] https://launchpad.net/bugs/717445
<jdstrand> hallyn: so, your plan is merge Debian 0.8.7-2, maybe snag the upstream patch for that kernel/virtio bug, and then have me review?
<hallyn> jdstrand: yup (i'll also need those two patches for the arm+ppc tests failure)
<jdstrand> hallyn: sure. definitely include your 0.8.7 work as part of the new ubuntu delta
<jdstrand> hallyn: I think your plan is good. it'll actually give us the opportunity to get in sync with Debian again, and have them take our delta. that wasn't really possible before since the patches changed each time
<hallyn> jdstrand: actually that reminds me.  FOr the last few days, 'debuild' has been adding a 'debian-changes-xyz' patch at the top of my quilt patchset.  What is that about?
<hallyn> jdstrand: \o/  :)
<jdstrand> hallyn: you have changes made outside of debian/. the source format v3 noticed this and helpfully created a patch for you
<jdstrand> hallyn: you should loke at that patch and make a proper quilt patch
<jdstrand> s/loke/look/
<hallyn> jdstrand: feh.
<cjwatson> hallyn: hmm, that is pretty big
<hallyn> (I just deleted all and re-did dpkg-source x whenever that happened)
<hallyn> cjwatson: yeah :(
<cjwatson> hallyn: what I really need is a way to reproduce this with grub-mkrescue
<hallyn> cjwatson: but it's clearly VBE related
<hallyn> cjwatson: bc it affects all the bioses built with VBE (-vga std, -vga vmware)
<cjwatson> hallyn: having to build an entire lucid ISO image for it is going to take too long
<hallyn> cjwatson: ok, I was goign to look at the patch in more detail, just wanted to check if something obvious spring out at you
<jdstrand> hallyn: one thing about quilt source v3 is it makes sure that you use quilt as the patch mechanism rather than letting you sneak in things outside of it
<hallyn> cjwatson: as for grub-mkrescue - i just need to go RTFM and learn how to use it
<cjwatson> hallyn: BTW that also doesn't explain why it's allegedly broken in maverick
<jdstrand> hallyn: anyhoo, sounds like you are on track. thanks for all your work on it! :)
<hallyn> cjwatson: why, is that commit in maverick's grub?
<cjwatson> yes
<hallyn> jdstrand: thanks, hopefully i'll be checking in with you tomorrow afternoon :)
<hallyn> cjwatson: #(*&$(*#&$
<hallyn> then i should probably un-dupe that other bug
<cjwatson> hallyn: TBH it seems a bit coincidental to me
<cjwatson> hallyn: adding those extra drivers might cause GRUB to use them rather than VBE
<cjwatson> (they're preferred if available)
<cjwatson> hallyn: but that would still leave the VBE module itself broken
<jdstrand> hallyn: and I will be more responsive :) (I had a couple of security updates I'm trying to get out before tomorrow)
<cjwatson> this is why it needs to be cut down to a situation with grub-mkrescue
<hallyn> ok, let me send out this patchset i have to get out, then i'll go RTFM on grub-mkrescue
<cjwatson> because that isolates us from changes in the configuration file machinery
<hallyn> jdstrand: np.  keep me safe :)
<barry> lool: just wondering too, if you know anything about the dbus.proxies.Introspect error (bug 715707).  it's new in natty - same code in maverick does not produce that error
<ubottu> Launchpad bug 715707 in computer-janitor (Ubuntu) "Error:dbus.proxies:Introspect error" [Low,Confirmed] https://launchpad.net/bugs/715707
<cjwatson> with an upstream tree of lucid vintage, we're probably talking something like:  PATH=.:$PATH ./grub-mkrescue --output=grub.iso disk
<cjwatson> where disk is a directory containing boot/grub/grub.cfg as you see fit
<cjwatson> the syntax changed around later, but that was post-maverick
<cjwatson> sorry, no, between lucid and maverick
<cjwatson> in maverick vintage, it's:  ./grub-mkrescue --grub-mkimage=./grub-mkimage --override-directory=. --output=grub.iso disk
<cjwatson> and nowadays that would be --override-directory=grub-core instead
<lool> barry: It's quite certainly some dbus policy which is missing, not sure where
<barry> lool: yep, probably from the janitord policy, but it has to be some change to dbus or python-dbus since mav
<barry> lool: oh well, no worries
<hallyn> cjwatson: thanks
<JordiGH> I created an i386 .deb, compiled on 10.10 machine, but when I install it on a i368 machine with Software Center, I get a large warning that the architecture is wrong, but the package installs anyways. Any clues?
<cjwatson> show us the package
<JordiGH> The binary, or just the debian/ directory?
<cjwatson> both, for preference
<JordiGH> Okay... the actual source is like 500 megs, so I'd rather not upload that
<cjwatson> no need for the full upstream source
<JordiGH> Ok, uploading, this is gonna take a while...
<JordiGH> ze debian/ dir: http://jordi.platinum.linux.pl/debian.tar.gz
<JordiGH> ze .deb http://jordi.platinum.linux.pl/goweb_0.9.1_i386.deb
<cjwatson> the second is 404
<JordiGH> Durr...
<JordiGH> http://jordi.platinum.linux.pl/goweb_0.9-1_i386.deb
<azeem> I read that as platform and thought you'd be running for DPL
<cjwatson> JordiGH: what's the exact error message you get?
<JordiGH> Nah, Stefano is doing a good job.
<cjwatson> the source and binary there look fine
<JordiGH> cjwatson: It's in Spanish... Uhm, a big warning flashes on top of Software Centre and say the architecture is wrong... Let me find it again.
<cjwatson> I'd rather have the exact Spanish message than anything else
<cjwatson> at least I can look that up in .po files
<cjwatson> also, does this package live in an apt repository?
<JordiGH> No, it's for a small startup.
<cjwatson> that seems like a non sequitur, but OK
<JordiGH> Like, we're not doing this properly.
<JordiGH> We just have one giant package that should include most of everything in one place.
<JordiGH> It's a rebranded/modified xbmc, and Marillat has packaged this properly.
<JordiGH> I'm about to leave the startup, so I want to give them a monolithic package that will be easier for them to understand.
<cjwatson> was the error "No se encuentra disponible para su arquitectura hardware."?
<JordiGH> Hm, no.
<JordiGH> It was "PerdÃ³n, Â«gowebÂ» no estÃ¡ disponible para este equipo (i386)"
<JordiGH> Now that I read that, it's not about architecture?
<JordiGH> It sounds like it's about architecture because it's mentioning it.
<JordiGH> But I think it's complaining that the package isn't available from an apt source?
<cjwatson> I can't find that string in software-center
<JordiGH> Well, without Â«gowebÂ», that's the name of te package.
<JordiGH> the
<cjwatson> sure
<Chipzz> one giant package... ugh. /me has nightmares about zimbra :/
<cjwatson> I know enough to avoid the obvious substitution elements :)
<JordiGH> cjwatson: Is the .po available via web?
<cjwatson> probably
<cjwatson> don't ask me where
<cjwatson> what version of Ubuntu is this?
<JordiGH> 10.10
<cjwatson> the system where you're running software-center, I mean
<Chipzz> cjwatson: could it be an error from apt/python-apt or sth of the sort?
<jpds> That does sound like an architecture problem.
<cjwatson> Chipzz: certainly possible, but I also grepped apt and came up with nothing
<cjwatson> I'll grep the language pack in a minute
<Chipzz> doesn't rosetta have a search function?
<JordiGH> Ugh, I gotta login to launchpad in order to download a translation?
<JordiGH> https://translations.launchpad.net/software-center/trunk/+pots/software-center-doc/es/+translate
<JordiGH> And looks like it needs javascript as well.
<JordiGH> wtf
<cjwatson> complaining about LP here is useless - we don't work on it
<cjwatson> are you sure it wasn't "... para este tipo de equipo"?
<JordiGH> That could be it, I might have omitted a word when I was copying it.
<JordiGH> It flashed rather quickly on the screen.
<cjwatson> #: ../softwarecenter/db/application.py:420
<cjwatson> #, python-format
<cjwatson> msgid "Not available for this type of computer (%s)."
<cjwatson> msgstr "No disponible para este tipo de equipo (%s)"
<JordiGH> Yeah, that sounds like it could be it. Except it's missing the apology.
<cjwatson> ah, sorry, different one
<cjwatson> msgid "Sorry, '%s' is not available for this type of computer (%s)."
<cjwatson> msgstr "PerdÃ³n, Â«%sÂ» no estÃ¡ disponible para este tipo de equipo (%s)."
<JordiGH> Yes, that's it!
<cjwatson> how are you getting this solitary .deb that isn't in an apt repository into software-center?
<JordiGH> I double click on it from nautilus.
<cjwatson> bug 694963
<ubottu> Launchpad bug 694963 in software-center (Ubuntu) "Package is not available for this type of computer" [Undecided,Confirmed] https://launchpad.net/bugs/694963
<cjwatson> I think that you can very probably work around this by putting it in an apt repository
<cjwatson> that's my guess from drive-by reading the source, anyway
<JordiGH> Hm.
<JordiGH> I see.
<cjwatson> mvo: ^- FYI
<JordiGH> Thanks again, quite helpful.
 * JordiGH still feels in very foreign lands in Ubuntu.
<JordiGH> cjwatson: Btw, re the Octave thing the other day...
<JordiGH> http://octave.1599824.n4.nabble.com/Ubuntu-and-Debian-packaging-td3299300.html
<ari-tczew> next bintuils upgrade?
<ari-tczew> I noticed package which built yesterday, today is not buildable
<cjwatson> JordiGH: I can understand his viewpoint
<ari-tczew> good idea a week before feature freeze
<JordiGH> cjwatson: Maybe, but it's distressing for me to know that most of the users of my package see a buggy version of it.
<cjwatson> it's great when people are happy to read our bugs directly, but it's fair to say "sorry, I'm already swamped"
<JordiGH> I'd like to just *hear* about it. I could have done something about that bug in the 6 months nobody looked at it.
<cjwatson> if you want to get reports yourself, and other folks on pkg-octave-devel don't want to, then the right answer seems to be for you to subscribe yourself directly to the derivatives keyword (or whatever) in the PTS
<JordiGH> I may have not, but it's distressing when a bug in a package I worked on doesn't even get an acknowledgement in six months and most of my users are experiencing that bug.
<JordiGH> Well, there only seems to be one other person besides me and Thomas.
<JordiGH> I'll ask them.
<JordiGH> Well, him.
<cjwatson> if I were in your shoes, I would just subscribe directly
<cjwatson> it seems the course of least resistance, given that Thomas has explicitly objected
<cjwatson> why have that argument when you don't need to? :)
<JordiGH> Because I don't want to become an Ubuntu developer either.
<cjwatson> uh
<JordiGH> And I *do* want other members to at least know about Ubuntu bugs.
<cjwatson> sorry, I don't see the connection
<JordiGH> I don't want to feel responsible for Ubuntu bugs either.
<cjwatson> anyone can subscribe to keywords in the Debian PTS - that facility isn't even offered by us
<JordiGH> I'd start to feel like that if I knew I was the only one in the DOG that was reading Ubuntu bugs.
<cjwatson> I'm not sure I can really help you with this, then. :)
<cjwatson> perhaps create another mailing list?
<JordiGH> I'll ask SÃ©bastien. If he objects to that as well, then it's clear.
<cjwatson> pkg-octave-derivatives or something
<JordiGH> pkg-octave-ubuntu, let's call a space a fucking shovel.
<JordiGH> It's not derivatives, it's Ubuntu, because that's where the vast majority of our users are.
<micahg> !ohmy | JordiGH
<ubottu> JordiGH: Please remember that all Ubuntu IRC channels share the same attitude of providing friendly and polite interaction with all users of all ages and cultures. Basically, this means no foul language and no abuse towards others.
<cjwatson> whatever you like, it was just a suggestion
<JordiGH> micahg: A Ð¿Ð¸Ð·Ð´Ð°ÑÐ°Ñ shovel.
<micahg> JordiGH: :)
<SpamapS> JordiGH: that makes me wish I had an auto-translator in my chat client so I didn't have to figure out what it means in.. I'm guessing Russian due to the Cyrillic chars.
<JordiGH> SpamapS: Probably, unless I misspelled.
<JordiGH> My Russian spelling is terrible.
<JordiGH> cjwatson: I find the argument of comparing Ubuntu to 120 derivatives very facile. It's not just another distribution, and paying attention to Ubuntu doesn't mean you have to pay attention to 120 other derivatives.
<cjwatson> if you don't mind, I would rather not have this argument
<cjwatson> I didn't name the PTS keyword
<cjwatson> and as an Ubuntu developer I would prefer to be gracious to other derivatives, anyway
<cjwatson> but as I say, just a suggestion, the name is unimportant to me
<canesin> Hi all... I have added Spinbottoms for my project in Glade but it looks like it is "not spinning" when running it
<mvo> thanks cjwatson, let me read scrollback
<mvo> JordiGH: that was for goweb you said?
<JordiGH> mvo: Yeah. The download link is above, if you want to try it.
<JordiGH> It's a pretty simple package, and I want to keep it that way, because I have to pass it on to people who barely know their way around bash. ;-)
<mvo> JordiGH: I get a 404 for http://jordi.platinum.linux.pl/goweb_0.9.1_i386.deb
<JordiGH> I corrected the link... :P
<mvo> aha, have it now
<canesin> Hi all... I have added Spinbottoms for my project in Glade but it looks like it is "not spinning" when running it
<mvo> canesin: try .start() on the spinner
<canesin> mvo: In the glade itself ??
<canesin> mvo: or should I add a signal to it ?
<mvo> in the py or C code
<canesin> AttributeError: 'gtk.SpinButton' object has no attribute 'start'
<mvo> ups, sorry, misread. I though it was a  gtk.Spinner()
<canesin> mvo: =) ..
<canesin> mvo: Do you know how i should proceed ?
<h0ar3> guys I have cloned Linus' kernel branch
<h0ar3> how can I compile and install it for ubuntu
<penguin42> h0ar3: https://wiki.ubuntu.com/KernelTeam/GitKernelBuild
<ricotz> cjwatson, hello :), is there a bzr packaging branch of gnupg?
<h0ar3> penguin42: awesomely helpful
<h0ar3> thanks
<ricotz> cjwatson, if not perhaps could look at this merge http://people.ubuntu.com/~ricotz/gnupg/
<smoser> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: open | 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 | Current Friendly Patch Pilots: cdbs
<chrisccoulson> "On 2005-02-16 00:00z (2192 days 18 hours 31 minutes ago), you uploaded a translation template for firefox in Ubuntu Maverick package "firefox" in Launchpad. The template has now been imported successfully."
<chrisccoulson> nice!
<chrisccoulson> about time ;)
<micahg> ah, not just me :)
<chrisccoulson> lol
<micahg> that date seems a little off though ;)
<chrisccoulson> yeah, i must have uploaded to the future
<dpm> chrisccoulson, I was just explaining it to micahg on #launchpad :)  that's because a bug was fixed yesterday in Firefox translations in LP and we needed to upload a new template to clean up the one imported last. We noticed that yours had never been imported and that manually approving them would be much easier than regenerating a new one. The funny date is because we bumped the priority in the imports queue by making it much older (oldest templates are
<dpm>  imported first)
<dpm> there were two templates pending import, approving one made the other one be approved as well
<cjwatson> ricotz: no idea.  sorry, doing too many things right now to be able to look at it.  perhaps you could add it to the sponsors queue
<ricotz> cjwatson, ok, do i need special rights to upload there? could you point me to a wiki howto?
<ricotz> cjwatson, nvm, i will file a bug
<GunnarHj> tedg: Hello Ted, new attempt today?
<tedg> GunnarHj, Sure
<tedg> I'm only making kenvandine's life difficult today -- I can take a little break from that. ;)
<GunnarHj> tedg: Ok. :) It's https://launchpad.net/bugs/636693 I'd like to discuss with you.
<ubottu> Error: Could not parse data returned by Ubuntu: list.index(x): x not in list (https://launchpad.net/bugs/636693)
<kenvandine> thx tedg
<tedg> GunnarHj, Yes, /usr/bin/guest-session should definitely not be locking the session :)
<GunnarHj> tedg: But why not? The argument you initially mentioned on the bug, that there might be situations when no screen locking should take place, is not valid any longer, since locking now is a condition for launching a guest session.
<tedg> GunnarHj, Why is it a condition?
<ohsix> hm, why does aptitude try and remove everything i've installed via apt-get the first chance it gets; clean install (my old install didn't, i suspect it had to do with some Recommends related setting)
<GunnarHj> tedg: Because the whole idea with gdm-guest-session is to restrict access - if you wouldn't lock the session from where the guest session is launched, you could as well let the guest use the regular session.
<tedg> GunnarHj, I use guest session all the time where restriction isn't the issue, it's having a clean set of preferences to make sure a package works.
<tedg> GunnarHj, I think there's also a use case for "don't mess up my settings" more than "restrict access"
<GunnarHj> tedg: Hmm... Then you use it as a developer tool, which is not wrong, of course, but it's not the intended use. If you as a developer want to use it that way, you can easily disable the locking code in /usr/share/gdm/guest-session/guest-session-launch
<GunnarHj> tedg: Besides, how would using gdm-guest-session that way be a reason for _not_ removing the locking code from indicator-session?
<tedg> GunnarHj, Indicator session does a more nuanced view of when to lock the session -- for instance if the user has disabled screen locking -- so it makes a better choice.  Sure, guest-session could be updated to do the same, but I think it violates the unix philosophy of "Do one thing, and do it well".  guest-session should "start a guest sesion" no "and" after that.
<tedg> GunnarHj, If guest-session enforces locking, there's no way around it, while if it doesn't we get a choice.
<GunnarHj> tedg: Making it easier to provide options is the original reason why I suggested that locking is dropped from indicator-session, and I mentioned choosing the guest session language as one example.
<GunnarHj> That kind of option is more likely appreciated by the average user than the option to not lock the regular session.
<GunnarHj> There are people who would like to see a guest session feature that you can launch from gdm's login screen, but then we are talking about a different kind of feature IMO.
<tedg> GunnarHj, Well, as you noted there is a blueprint (only half implemented) to provide for other types of items there.   One of the ones we were considering is "Unity Smoke test" where you could launch a guest session into a session where Unity ran a smoke test on your graphics hardware.  For that my intention was to provide a "configure" command and a "do it" command so those use cases could be supported.
<tedg> GunnarHj, If the guest-session command automatically locks, it's hard to use it in higher level scripts like the unity-smoke script as well.
<GunnarHj> tedg: I didn't know that. Have a feeling that you and Martin P. ought to talk it over. From my Ubuntu newbie perspective, I see that the way it currently works is not optimal. As an example, at http://ubuntuforums.org/showthread.php?t=1566078 I need to advise people to not launch guest sessions from indicator-session.
<tedg> GunnarHj, Certainly, I think the best thing at this point is to provide for a "--no-lock" option on guest-session.
<GunnarHj> tedg: It sounds reasonable to me, but that would not make it less important to remove the locking code from indicator-session. Shall we make a deal? ;-)
<tedg> GunnarHj, Well, I think it'd be better to separate out the configuration and execution, so I'll try to get that working.  Then you can build exactly what you want, and infact, several of the different combinations :)
<kirkland> slangasek: cjwatson: where can i find documentation as to building a server installation ISO locally?
<slangasek> kirkland: you need a copy of debian-cd; probably the forked version that runs on the Ubuntu CD buildserver
<kirkland> slangasek: where abouts do I find that ?
<GunnarHj> tedg: Ok, thanks. :-)  But I do think that a --no-lock option is a good idea, so I'll propose the addition of it. Then, if you want to use the guest session as a testing environment when developing things, you can do it without a need to edit a program file.
<slangasek> kirkland: I think https://code.launchpad.net/~ubuntu-cdimage/debian-cd/ubuntu might be it
<slangasek> kirkland: documentation is probably upstream in Debian
<persia> kirkland, slangasek: that is indeed the branch you want
<kirkland> persia: okay, thanks;  got it;  i'm looking at the README in there;  is that the best place to learn how to build an Ubuntu Server ISO?
<persia> kirkland, How much do you like reading make?
<highvoltage> heh
<kirkland> persia: somewhere above Emily Bronte but below Neal Stephenson
<persia> Right.  Let me look about a bit to make sure I'll give you the right reference then.
<persia> kirkland, Quick'n'dirty (so, when it breaks, fix that, rinse, repeat): bzr branch lp:ubuntu-cdimage; ubuntu-cdimage/for-project ubuntu-server cron.daily
<dobey> any archive admin around?
<persia> You will need to have the debian-cd branch identified above available locally for this to even pretend to start working properly.
<dobey> hi persia :)
<persia> hey dobey
<dobey> how's it going?
<persia> It's Thursday :(
<dobey> yes it is
<dobey> and i just made a dumb mistake, but is easily redactable
<persia> What sort of mistake needs an archive-admin?
<sebner> persia: isn't that a good thing as weekend is in sight?
<dobey> persia: disapproving my upload to lucid-proposed. i made a brain fart and it was supposed to be to maverick-proposed (which i subsequently fixed the changelog and uploaded to)
<persia> OOps.  I'd recommend mentioning that in the relevant bug as well, just in case it ends up getting looked at by one of the ubuntu-sru folks, rather than someone catching it here.
<ScottK> I can remove it.
<ScottK> dobey: What package?
<dobey> ScottK: ubuntuone-client
<ScottK> dobey: You want it removed from lucid, right?
<ScottK> removed/rejected
<dobey> ScottK: yeah, the lucid-proposed upload was an oops
<ScottK> dobey: Done.
<dobey> ScottK: thanks much!
<Keybuk> one day, somebody should explain the whole ubuntu-virt-manager thing
<Keybuk> until then I'll run the much simpler kvm one-liner to run ubuntu in a virtual machine ;)
<mok0> Keybuk: amen to that
<soren> Keybuk: You mean virt-manager, right?
<ogra> isnt that a redhat app anyway ?
<mok0> soren, trigged a keyword huh :-)
<Keybuk> soren: might be ubuntu-vm-builder & virt-manager :p
<maco> i'll just keep using virtualbox
<maco> virt-manager requires that i go read a wiki page every time i want to use it
<ogra> yu could print it out and stick it to the back of your laptop ;)
<soren> Keybuk: They're quite different beasts. Both have their set of idiosyncracies.
<soren> Keybuk: ...so I can't really explain them as one, is my point.
<kirkland> soren: i seem to recall you knew how to build the server ISO...
<kirkland> soren: i have lp:cdimage local
<kirkland> soren:  ... now what?
<soren> kirkland: Long forgotten, sorry.
<kirkland> soren: k
<soren> kirkland: ...and I never bothered doing it locally. I just triggered it on the build servers.
<mathiaz> SpamapS: hi!
<mathiaz> SpamapS: do you know if using the restart command will pick up a new upstart job?
<mathiaz> SpamapS: it seems that if the memcached.conf file is updated and then restart memcached is called
<mathiaz> SpamapS: the command from the old memcached.conf file used
<mathiaz> SpamapS: rather than the new one
<soren> mathiaz: It won't.
<soren> mathiaz: restart by design uses the in-memory definition of jobs.
<mathiaz> soren: ok - so start, stop would do the job?
<soren> mathiaz: Yes.
<mathiaz> soren: great - thanks
<soren> mathiaz: upstart knows there's a new job definition. It just considers it a branch new definition, not a redefinition of the old one.
<soren> err..
<soren> s/branch/brand/
 * soren uses bzr a lot... Can you tell? :)
<hallyn> is there a standard way to add a mount entry when a package is installed?
<hallyn> i need a tmpfs mounted at /sys/fs/cgroup/
<hallyn> Daviey: ^
<hallyn> oh, prolly too late for him
<soren> hallyn: If it's not something that is generally applicable (and thus could be put in the standard fstab for everyone), you'd probably mount it from an upstart job (so not use fstab at all).
<hallyn> soren: hm.  ok, that sounds simple enough from pkg point of view
<hallyn> soren: though i hate the idea of random programs mounting junk all over the place :)
<hallyn> soren: thanks, i'll do that until someone yells at me
<soren> hallyn: It's Linux. It's a patch work of random programs doing random things all over the place. Noone will notice one more or one less.
<hallyn> lol
<hallyn> "long as they haven't noticed my little backdoor"
<soren> Noone will notice one more or one less.
<soren> :)
<hallyn> I like my programs to be as transparent as possible - but adding a mount to fstab seems intrusive and will still leave ppl wondering where it came from :)
<penguin42> pity fstab hasn't gone to a .d type arrangement like most other stuff
<bryceh> penguin42, maybe they're waiting on a patch from you?  ;-)
<bryceh> penguin42, but yeah, my fstab's are crufted over with mounts for chroots, nfs shares, ... so a .d for configuration would make things a lot tidier
<penguin42> I guess quite a few things would need to be updaed, but I guess not too bad
<broder> hallyn: -1 for adding to fstab. i think doing it from an upstart/init.d job sucks, but is the best current option
<broder> until somebody writes up fstab.d support :)
<a3Dman> why natty daily images is forced to the gnome-icon-theme?
<hallyn> broder: ok, thanks.
<hallyn> heh, maybe i'll try my hand at dh_fstab :)
<hallyn> fstab.d, not so much
<jbernard> hallyn: why is tmpfs needed? Is this an integration issue, or are you seeing failure that I can fix in teh debian package?
<jbernard> hallyn: also, if there's anything I can do to help, please do let me know
<hallyn> jbernard: i'ts for libcgroup.  They want to (are encouraged to) create directories under /sys/fs/cgroup
<hallyn> but you can't do that
<hallyn> so they're supposed to mount a tmpfs under there
<hallyn> admittedly we could just use /cg or /cgroup or /mnt/cgroup, but general consensus has been that /sys/fs/cgroup should exist for that purpose
<hallyn> jbernard: thanks
<hallyn> anyway i think i've just about got libcgroup yanked out of the garbage dump
<jbernard> it should mount them in /sys/fs/cgroup, is that not occuring?
#ubuntu-devel 2011-02-18
<hallyn> jbernard: no, it's not.  because first it wants to create some subdirectories.  and that isn't allowed
<psusi> hrm... what happened to external media being auto mounted with -o uid=,gid=?  I thought that had been working for some time to override the permissions on broken filesystems... where is that implemented these days?  udisks right?
<persia> psusi, Yes.
<hallyn> (sorry, didn't mean to sound harsh - libcg itself has just somehow never struck the right chord with me.  it *should*, except i prefer scripts to magic fragile configfiles)
<psusi> hrm... I'll have to take a look at the code then.. I have been sorting through some old dvd+rw discs and I couldn't access this one because it wasn't mounted with the uid,gid options...
<hallyn> jbernard: I'm waiting for confirmation from two bug reporters, but I expect to be doing a merge request for https://code.launchpad.net/~serge-hallyn/ubuntu/natty/libcgroup/upstart/
<hallyn> jbernard: (or I can send it as a debian bug report?  dunno what you prefer)
<\sh> moins
<broder> hallyn: is this different from /dev/cgroup/cpu?
<jbernard> hallyn: a bug would work well, but i don't have a strong perference
<poolie> scottk, i will make the LEP and bug more clear re the celebrity thing
<poolie> btw, dkim stuff is on the back burner but not totally cold
<poolie> i hope to enable it for your domain soon
<ScottK> OK.
<ScottK> It seemed like a jargon term that would have been well understood by the LP people on the list and I didn't want to mis-guess what it meant.
<poolie> sure
<poolie> undoubtedly there will also be some ubuntu jargon that goes over my head too, or lp devs heads
<poolie> biab
<ScottK> Certainly, that's why it's important to check on such things and make sure we have a common understanding.
<YokoZar> ScottK: I've been getting lots of spam from forged @ubuntu.com addresses...would you take it personally if Canonical wasn't running SPF on the ubuntu.com domain? ;)
<ScottK> Not sure what you mean?
<ScottK> YokoZar: There is no SPF record for ubuntu.com
<YokoZar> Right
<YokoZar> I vaguely remember a conversation at an airport with you about you having a big role in SPF
<ScottK> I was involved in it's development.
<ScottK> The trick is that to publish a useful SPF record, Canonical would have to give Ubuntu members a way to send through an authorized outbound relay.
<YokoZar> And thus it seems silly that we don't use it ;)
<ScottK> I doubt they're up for that.
<maco> forging is how i send emails from my @ubuntu.com address
<maco> kmail makes it easy!
<YokoZar> Yeah, true
<micahg> yep, me too :)
<maco> (my dad was really really O_O when i said i could send an email from him from my computer instead of from his lotus
<maco> )
<broder> ScottK: wait, i thought there was a relay server i could send mail through for ubuntu.com...
<ScottK> Is there?
<broder> apparently not
<broder> i thought i remembered configuring gmail with one, but i'm looking at it and i clearly didn't
<maco> i use gmail as a relay
<maco> nah all you're doing in the case you make gmail able to send from it is telling gmail to forge it
<broder> right, right
<maco> they at least check that you actually have access to the account (by sending a confirmation email) first
<ScottK> We can use indium to send mail to LP, but that's all I know of.
<broder> clearly we need an implementations of gmail's oauth sasl extension in postfix and major clients so we can authenticate against launchpad to an ubuntu.com MTA
<persia> I'm not sure I'd like to see SPF for @ubuntu.com.  I don't mind as much if someone pretends to be me when there's no confirmation that they are indeed me.
<persia> broder, Hrm.  I suppose that might work.
<broder> persia: except for the part where client support is guaranteed to be awful for the next N years
<ScottK> persia: SPF makes no assertion that mail is really from us, just that it came from a relay authorized by the domain owner.
<ScottK> So your deniability is still secure.
<persia> broder, All mail clients have been miserable and bad for the past 40 years.  I don't see why that would change.
<broder> touche
<persia> ScottK, I know that, and you know that, but being the sort of person who regularly needs to defend deniability, I prefer when there isn't even an implication.
<ScottK> persia: If they ever corner you, you can also pull out DNS cache poisoning.
<ScottK> (as an added reason why it wasn't you)
<persia> Heh.  It won't come to that.  I just don't see the value in a relatively open SPF-certified relay.
<ScottK> Also bad and miserable does have degrees.  If not, evolution wouldn't exist.
<persia> Something like oauth could do it, but that's awkward to implement.
<ScottK> I think it's not mostly interesting for the ones that might be OK, it's interesting for the ones that probably aren't.
 * persia hugs bug #110840 and continues not to use evolution
<ubottu> Launchpad bug 110840 in evolution (Ubuntu) "Evolution stores mail insecurely" [Low,Triaged] https://launchpad.net/bugs/110840
<maco> persia: is that a reference to how im able to grep my emails if i use evolution instea of waiting for it to load and search?
<persia> maco, No, it's a reference about how I'm able to grep your mail in evolution without even pretending to be you.
<maco> persia: if home dirs were 700 this wouldnt be a problem...
<persia> ScottK, How do you mean (re: mostly interesting)?
<ScottK> I rarely find "It passed SPF" very interesting except for a very restricted set of domains.
<persia> Ah.  For those domains that are mostly-spam, it becomes an interesting way of identifying potential ham?
<ScottK> OTOH, "It failed/didn't pass (those aren't quite the same thing) is broadly interesting.
<persia> failed means it originated from a non-certified host, and didn't pass means that there are no certified hosts?
<ScottK> Didn't pass includes Fail, Softfail, Neutral, and error results.
<ScottK> So failed is a subset.
<ScottK> Finding bad domains isn't very interesting.
<persia> Ah.  That makes sense.  What's the difference between Fail and Softfail?
<ScottK> Softfail is like "We think it's not authorized, but we're not ready to commit to the completness of our list yet"
<ScottK> persia: The formal definition is http://www.openspf.org/RFC_4408#op-result-softfail
 * persia was starting with http://www.openspf.org/FAQ/What_is_SPF :)
<ScottK> Anyway, bad domains are boring because they send nothing but crap whether it passes or not.
<ScottK> Good domains are interesting because threat/not threat tends to match very closely with SPF result.
<persia> And most domains are neutral?
<ScottK> The published statistics I've seen seem to say that ~half of email has an SPF record for it.
<ScottK> Most large domains don't want to take the hard line of saying "If it's not from an authorized source, treat it badly" since they don't want complaints.
<persia> That's interesting.  I read that as "most spammers have adopted SPF"
<ScottK> A lot of people have on both sides of the fence.
<ScottK> The nice thing about spammers adopting SPF is that it makes it possible to automatically construct reliable domain black lists.
<ScottK> "Gee, all crap from that domain and it passes SPF, so they sent it - next time I'll just reject it after mail from"
<persia> Indeed.  makes the construction of rule semantics that much richer.
<ScottK> It you look at just SPF pass, domains tend to be either virtually all ham or all spam.  The middle ground is very small.
<persia> Isn't that the point?
<persia> I presume that domains without useful control over sending relays (e.g. @ubuntu.com) mostly choose not to participate currently.
<ScottK> Yes.
<ScottK> It also turns out to be hard for large entities to delpoy accurately just because they don't know their outbound architecture very well.
<wgwinn> has ubuntu 10.10 removed kmalloc.h from the kernel source? i'm trying to install the hyper-v v2 drivers and it's failing on kmalloc , and i cant find the function defined anywhere
<broder> wgwinn: looks like it's in <linux/slab.h>
<wgwinn> i dont see it there, but i will reread it
<Darxus> Where can I vote for Obnoxious Orangutan?  :)
<ScottK> Can't vote on that.  This is not (mostly) a democracy.
<persia> Darxus, We don't vote.  One of the privileges of the self-appointed benevolent dictator for life is the selection of the codenames for each release.
<wgwinn> using linux-headers-2.6.35-22/include/linux/slab.h has references to kmalloc() but does not define it.
<broder> wgwinn: well, there are lots of comments in the linux source tree to the effect of "#include <linux/slab.h> /* for kmalloc, kfree */", so i suspect it's included from there or something
<Darxus> Yeah, I figured I couldn't actually vote, but I'd love to see that name happen.
<Yanks> !ops
<Yanks> you know ur motherboard has 250$ worth of gold in it?
<Yanks> you know ur motherboard has 250$ worth of gold in it?
<Yanks> !staff
<hallyn> weird
<psusi> hallyn, were those -part changes only for the symlinks in /dev/by-id, or did they also change the name in /dev/mapper?
<achiang> any network-manager hackers around?
<achiang> or for that matter, people who know how to debug dbus/python stuff?
<persia> achiang, Try asking the question you would ask if someone said "yes"
<Yanks> you know ur motherboard has 250$ worth of gold in it?
<achiang> using maverick, playing around with the NetworkManager dbus api, and getting a rather basic error when trying to run some of the sample code --getting a dbus error: "ListConnections" with signature "" on interface "org.freedesktop.NetworkManagerSettings" doesn't exist
<ohsix> mine has none, it has molybdenum :[
<Yanks> you know ur motherboard has 250$ worth of gold in it?
<Yanks> !ops
<achiang> basically, i'm wondering if the NM in maverick presents that interface or not; it seems like it should, since we have NM 0.8+ and that is a 0.8 API
<Yanks> !ops
<Yanks> !ops
<Yanks> !ops
<Yanks> !ops
<Darxus> QQ
<broder> achiang: yeah, that should work. i'm pretty sure i've used it before. can you pastebin the command/code you're trying to call it with?
<achiang> broder: i was just kinda playing around and fixed my own problem
<achiang> broder: thanks though
<broder> achiang: cool
<didrocks> good morning
<didrocks> ogra: I think the unity team will need your armel knowledge: bug #721118 :)
<ubottu> Launchpad bug 721118 in nux (Ubuntu) "Nux FTBFS on armel" [High,Triaged] https://launchpad.net/bugs/721118
<dholbach> good morning
<didrocks> good morning Mr Holbach :)
<dholbach> bdrung, pulled lp:ubuntu-sponsoring
<dholbach> salut didrocks - comment Ã§a va mon ami?
<didrocks> dholbach: Ã§a va trÃ¨s bien, merci! et toi?
<dholbach> trÃ¨s bien aussi, merci beaucoup :)
<tkamppeter> pitti, hi
<jamespage> Morning
<jamespage> any chance that a member of the MIR team could review bug 676904 for me
<ubottu> Launchpad bug 676904 in jansi-native (Ubuntu) "[MIR] jansi" [Medium,Confirmed] https://launchpad.net/bugs/676904
<seb128> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: open | 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 | Current Friendly Patch Pilots: cdbs, seb128
<cjwatson> persia: can you update the developer-membership-board@ list membership when you have a chance?  I just realised I forgot to do this before resigning moderator access
<ogra> didrocks, well, stop casting bigger types into smaller ones and it will build i'd say :)
<didrocks> ogra: tell that to the dx team :p can you give them an help (not really confident with thoses)?
<ogra> i havent looked at the code yet, only at te error, but its likely that the target type is simply smaller under arm
<ogra> (int vs long or something like that)
<ogra> janimo, didnt you fix that before ? (bug 721118) or was that something else
<ubottu> Launchpad bug 721118 in nux (Ubuntu) "Unity FTBFS on armel due to Nux" [High,Triaged] https://launchpad.net/bugs/721118
<janimo> ogra, I fixed one instance, but there may be new ones. I'll check
<Daviey> asac, kees, doko__ , didrocks: jamespage's MIR (bug 676904) is pertinent to other things he needs to work on for release, so if you could look at the MIR soonish - it would be appreciated.
<ubottu> Launchpad bug 676904 in jansi-native (Ubuntu) "[MIR] jansi" [Medium,Confirmed] https://launchpad.net/bugs/676904
<Daviey> thanks :)
<ogra> janimo, gracias :)
<janimo> ogra, this is another issue. Sigh, nux reimplements a lot of stuff that is already handled by glib
<ogra> oh my
<ogra> do we know why ?
<janimo> unicode, timers, threads
<janimo> legacy
<ogra> tsk
<janimo> but mainatiner said they at least consider moving to glib
<ogra> good
<janimo> it started out as a from scratch project maybe without any external deps, so implements a lot of basic win/unix stuff
<ogra> yeah, that should be fixed
<ogra> reinventing the wheel doesnt really save time
<seb128> hum, wth, on a fresh natty install I get no keyboard working on the gdm screen
<seb128> but keyboard works in a vt and on the livecd image
<RAOF> Uuuh, Xorg.0.log would be the first candidate for a debug hunt.
<RAOF> That's a kinda important piece of functionality :)
<seb128> startx returns
<seb128> X: user not authorized to run the X server, aborting
<seb128> wtf
<RAOF> Run as root?
<seb128> why do I need to?
<RAOF> It needs root to do VT switching properly, at least.
<seb128> startx always worked?
<RAOF> But have we stopped installing it setuid, I wonder?
<seb128> sudo startx works
<RAOF> I have to admit to not testing startx very often.
<seb128> RAOF, http://paste.ubuntu.com/568688/
<seb128> that's the Xorg log
<seb128> seems to configure the keyboard, wth
<seb128> bah and the box crash on vt switch
<RAOF> Hm.  Well, it certainly looks like it's loading evdev for what it believes to be the keyboard, so it's not that.
<seb128> keyboard works in a sudo startx session, go figure
<seb128> oh, the gdm log has some clue
<seb128> "This incident has been reported.
<seb128> Error: No Symbols named "oss" in the include "us""
<seb128> seems like ubiquity did set up a broken keyboard config
<seb128> ok, works now after tweaking the keyboard config
<ogra> TheMuso, how does the alsa upgrade to new upstream go ?
<PetrHH> Hello
<PetrHH> I'm trying to package my program into deb. It is my first deb package ever. Package is creating without any problem but lintian utils still writes some errors. These errors: http://pastebin.com/HQPvL5UM
<PetrHH> but I have no idea what does it means. Could anybody help me, please?
<Laney> PetrHH: run lintian with --info and you'll get more explanation of each of those warnings
<PetrHH> Laney, thank you!
<shadeslayer> kees: sorry for pinging you again but, https://bugs.launchpad.net/ubuntu/+source/dcmtk/+bug/702026/comments/6
<ubottu> Ubuntu bug 702026 in dcmtk (Debian) "[MIR] dcmtk" [Unknown,Confirmed]
<PetrHH> Laney, do you know what file in debian directory is called maintainer script? I  have to add there #DEBHELPER#.
<asac> PetrHH: typically debian/*.{post,pre}{inst,rm}
<cjwatson> the term "maintainer script" is defined in the Debian Policy Manual: http://www.debian.org/doc/debian-policy/ch-maintainerscripts.html
<PetrHH> asac, thank you! Now I solved all warnings of lintian util
<asac> PetrHH: read what cjwatson gave you though
<PetrHH> cjwatson, Thank you for link, I'll look at it.
<asac> ;)
<asac> np
<ari-tczew> what do you think about version *ubuntu1b1 for rebuild?
<dholbach> how about just ubuntu2?
<Laney> dch --rebuild will give you a reasonable version string to use
<cjwatson> oubiwann: whom should I talk to about a utouch packaging problem that's breaking debian-installer builds?
<cjwatson> oubiwann: I can fix it, just want to make sure I'm not stepping on anyone's toes
<oubiwann> oubiwann: cnd is the first person
<oubiwann> which package?
<oubiwann> cjwatson: er, don't know why I just called you myself...
<cjwatson> utouch-frame - it needs to have a udeb added, then utouch-grail needs rebuilt against that
<cnd> cjwatson, ahh yes
<cnd> I thought we added one
<cnd> oubiwann, is bregma free to handle it?
<cjwatson> utouch-evemu and utouch-grail have udebs, but -frame doesn't
<cnd> yeah
<cnd> cjwatson, btw, I thought we didn't use d-i?
<cjwatson> we do
<cjwatson> (we had this discussion before :) )
<ogra> oubiwann, thats because all of us want to be like cjwatson ;)
<cjwatson> I can just submit a branch if that's easiest
<oubiwann> ogra: hahaha
<cnd> cjwatson, then my memory is failing :)
<cnd> cjwatson, that's easy enough
<bregma> what have I done this time?
<cjwatson> 14:30 <cjwatson> utouch-evemu and utouch-grail have udebs, but -frame doesn't
<cjwatson> breaks the debian-installer build - I think I'll just send you a branch for it
<cnd> cjwatson, once you submit, we'll review and approve, then you can merge it and push to ubuntu proper
<cnd> is that reasonable for you?
<cnd> as a core dev you have write access to our packaging branch
<cjwatson> np
<bregma> hmpf, rydberg was asked to remove the udeb from utouch-frame to get it into universe
<cjwatson> whoever asked him that was wrong
<cnd> bregma, who told him to do that?
<bregma> jeez, I can;t remember that, it was weeks ago
<cnd> heh :)
<cnd> we must have a witch hunt!
<cnd> just throw out a name
<cnd> any name
<bregma> burnings!
<cnd> as long as it's not me :)
<oubiwann> hehe
<oubiwann> no bus throwing!
<oubiwann> we'll just make sure we'll share the good info next time :-)
<bregma> as long as it gets fixed
<cjwatson> bregma: looking at bzr history, the prior problem was that 'DEB_DH_MAKESHLIBS_ARGS_libutouch-frame1 = --add-udeb=libutouch-frame1-udeb' was in debian/rules, but there was no declaration for that package in debian/control
<cjwatson> and no .install file for it
<bregma> yeah, the udeb was removed prior to that but the packaging was not cleaned up properly
<notch> hi, im trying to customize gajim package from ppa. In the rules file there is "ubuntu-prepare" target. I dont see any place where is it called. Is it standard target? Where can i find some documentation about it?
<jibel> mvo, Hi, we receive lot of reports from users failing to upgrade from 10.04 to 10.10 because of xorg-xserver-video-nouveau like bug 721306. Usually purging xserver-xorg-video-nouveau does the trick. Can we do something with update-manager to fix that ?
<ubottu> Launchpad bug 721306 in update-manager (Ubuntu) "Can't upgrade from 10.04LTS to 10.10" [Undecided,New] https://launchpad.net/bugs/721306
<ara> cjwatson, remember the testing that you asked us to do in a broad set of HW, looking for corruptions in the splash screen?
<ara> is this still needed? and if it is, what exactly do you need?
<cjwatson> ara: yes, I'd basically like a summary of hardware that "looks wrong" during the splash screen process
<cjwatson> especially cases where it fails to get successfully to X
<ara> cjwatson, OK, thanks
<cjwatson> but also cases where the splash is something other than a correct-looking aubergine graphics-mode screen or a correct-looking aubergine text-mode screen
<cjwatson> and I'd like to know whether the GRUB menu (hold shift at boot) is legible
<cjwatson> on many systems there will still be a black screen for some period during boot; I don't need to know about that, for the time being
<mvo> jibel: sure
<mvo> jibel: I can add code for tihs
<ara> cjwatson, all noted, thanks a lot for your input
<cjwatson> great, appreciated
<jibel> mvo, this is probable caused by the fix for bug 614993
<ubottu> Launchpad bug 614993 in xorg-server (Ubuntu) "10.04 -> 10.10 upgrade fails: pkgProblemResolver::Resolve generated breaks: xserver-xorg-video-v4l demoted to universe" [High,Fix released] https://launchpad.net/bugs/614993
<seb128_> jdstrand, hey, do you want to sponsor the lucid security update on bug #718127?
<ubottu> Launchpad bug 718127 in squid3 (Ubuntu Lucid) "CVE-2010-2951 and CVE-2010-3072 still exists in Lucid and CVE-2010-2951 still exists in maverick" [Undecided,New] https://launchpad.net/bugs/718127
<mvo> jibel: thanks, that is indeed anoying if this is caused by a regression
<seb128> zul, hey, do you think you could sponsor https://code.launchpad.net/~hudson-ubuntu/ubuntu/natty/libcommons-collections-java/bug-717157/+merge/49397?
<zul> seb128: of course give me a couple of minutes
<seb128> zul, thanks
<zul> seb128: merged do you want me to upload it while im at it
<seb128> zul, would be nice, thanks
<cjwatson> persia: should I adjust ~developer-membership-board's membership in light of the recent election?
<zul> seb128: done
<seb128> zul, thanks
<mvo> ScottK: hey, the backports-not-automatic stuff is finally making some progress again (apt had landed, python-apt support as well)
<ScottK> mvo: Great to hear.  Very cool.
<ScottK> mvo: Is that all of it at the tool level?
<ScottK> I know software center and other applications could use some U/I to support it.
<mvo> ScottK: the missing bits now are sofware-center ui and/or update-manager ui. plus support in aptdaemon
<mvo> actually aptdaemon needs to come first, then s-c and/or u-m
<ScottK> OK.
<mvo> for u-m there is a branch already thats sort of working
<ScottK> Cool.
<mvo> but the hard work was done (donkult is as always the guy to thank)
<ScottK> Excellent news.
<ScottK> I guess I should figure out how to get the relevant Launchpad change done now.
<ScottK> (I assume it still needs one)
<mvo> oh, indeed
<ScottK> I'll work on that then.
<mvo> that needs to be done as well (also it should be the smallest amount of work, fingers crossed)
<ScottK> I'll see what I can find out about that.
<mvo> ScottK: time is short (unfortunately) until FF, but lets see what we can do. in any case, the important groundwork is done now (that blocked us)
<ScottK> Yep.
<didrocks> is there some known eglibc issue reported from today's upload?
<DBO> doko__, I am here for blood
<didrocks> DBO is hitting http://sourceware.org/bugzilla/show_bug.cgi?id=12454
<DBO> and is here for blood
<didrocks> :)
<DBO> gah, half my stuff wont start
<didrocks> I don't want to screw my box for testing :)
<DBO> dont worry
<DBO> I already did that for you
<DBO> its borked
<didrocks> DBO: downgrade on your box first
<DBO> downgrade worked
<DBO> but... 2.13 sounds sexy
<didrocks> cjwatson: doko__ ^^
<DBO> and my update manager wishes me to upgrade again
<didrocks> DBO: it's a trap!  :-)
<DBO> its a tarp!
<doko> hmm, I did build a compiler with it
<DBO> doko, I couldn't start quite a few applications with the new glibc
<DBO> it basically broke a large (but seemingly random) percentage of my apps
<DBO> doko, are you running 32 or 64 bit?
<kees> shadeslayer: I've updated the bug report to point out the duplicated code
<hallyn> when i do 'bzr branch lp:debian/experimental/multipath-tools', it works. but when i do 'bzr branch lp:debian/unstable/multipath-tools', that doesn't exist.  Likewise, I can't "pull-debian-source multipath-tools".  Can anyone explain why?  The package does seem to exist by that name as per http://packages.debian.org/unstable/admin/multipath-tools
<jelmer_> hallyn, hi
<jelmer_> hallyn, does lp:debian/sid/multipath-tools work?
<hallyn> jelmer_: jinkeys, it does, thanks.
<hallyn> but so why does pull-debian-source not work?
<jelmer_> hallyn: there's an open bug about supporting the unstable, testing and stable aliases in launchpad (don't have the bug # here though)
<seb128> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: open | 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 | Current Friendly Patch Pilots: cdbs
<jelmer_> have a nice weekend seb128 :)
<seb128> jelmer_, thanks!
<seb128> you as well ;-)
<hallyn> jelmer_: thanks
<jelmer_> hallyn: How does pull-debian-source fail?
<jelmer_> hallyn: it fetches 0.4.8+git0.761c66f for me
<jelmer_> seb128: Thanks :)
<hallyn> jelmer_: well what the heck.  I tried three times and got 'Unable to find mulitpath-tools in unstable'.  Now it fetched it
<hallyn> thanks, looks like I"m all set now :)
<doko> DBO: did you test this patch?
<DBO> i did not
<bdmurray> doko: I've run into the same issue with evolution on x86_64
<marcrouse> hi
<marcrouse> i suche logari81
<Chipzz> marcrouse: first of all the official language of this channel is English; you're highly unlikely to get an answer in a different language
<marcrouse> i m sorry
<marcrouse> i search logari81
<Chipzz> 2nd, my last log shows no occurence of that name; it's not very likely you'll find some random user here (unless of course there's good reason to believe he frequents this channel; which I doubt there is)
<Chipzz> (I read the backlog of this channel regulary, and I don't recall seeing anyone by that name talk here either recently or at all)
<doko> bdmurray, DBO: just uploaded a test package to https://launchpad.net/~ubuntu-toolchain-r/+archive/test/ currently building
<DBO> okie dokie
<Chipzz> marcrouse: I see the guy has a PPA; I would suggest you ask in #ubuntu-motu, chances are ppl over there have seen him
<Chipzz> marcrouse: (#ubuntu-devel is mostly (99%) about the development of ubuntu main; discussion of PPA's (unless they contain software which is in main) is done in #ubuntu-motu)
<doko> bdmurray, DBO: amd64 build finished
<DBO> doko, will test in a bit
<doko> bdmurray, DBO: away for the evening
<ScottK> hallyn: pull-debian-source works fine here.
<DBO> doko, understood
<ScottK> Ah, I see you got it working.
<ScottK> Chipzz: PPA's aren't on topic in #ubuntu-motu either.
<didrocks> ScottK: hey
<didrocks> ScottK: did you follow the eglibc issue?
<ScottK> didrocks: I've read the stuff on IRC.
<ScottK> (and I'm not updating anything just now as a result)
<didrocks> DBO: did you try the patched version? will be nice to know before the week-end if the new one is working
<didrocks> ScottK: just trying to figure if we should revert or not for amd64 users (I'm on i386, so can't test)
<DBO> i will test in a minute
<DBO> mmm cheese and mustard are a good combo
<Chipzz> ScottK: ah k. thought they were
<ScottK> Chipzz: We do Ubuntu in there too.
<Chipzz> ScottK: universe and multiverse that I know of idd
<ScottK> Chipzz: Yes.  In Ubuntu.  PPA's aren't part of Ubuntu, so they're no more on topic there than here.
<micahg> PPA packaging can be discussed in #ubuntu-packaging, PPA support would be in #launchpad
<dobey> i guess problems with a particular PPA should be discussed with the PPA owner though, not #launchpad or #ubuntu-packaging, in general
<dobey> which is what i guess the guy was trying to do, but the owner wasn't in here
<Chipzz> and the chance of him being in #ubuntu-motu was higher
<cjwatson> didrocks: please do not revert libc6
<cjwatson> didrocks: the dependency chaos would be horrible
<cjwatson> we need to go forward there, not backward
<didrocks> cjwatson: that's why I didn't want to do that on my own :)
<didrocks> (and was waiting)
<dobey> i don't know if that's true, but /whois should answer whether someone is on irc or not
<cjwatson> if somebody can confirm the upload doko referred to, I can upload it
<didrocks> I think DBO will test in a few
<DBO> I am testing hold on
<DBO> I dont like installing ppas is all...
<cjwatson> (well, not right now because it's my daughter's bathtime, but this evening)
<DBO> gah
<DBO> there are other thing in that PPA
<DBO> time to download debs
<hallyn> ||http://pastebin.ubuntu.com/568876/
<hallyn> oops, sorry
<hallyn> misfir
<DBO> cjwatson, the fix does not work
<seb128> cjwatson, doko: since the update doesn't work and natty is broken should we consider asking to block the binaries from being downloaded?
<janimo> which package sets up the 'Restart Needed' notification after certain kernel upgrades?
<ohsix> good question, you could look in the debian dir in the source package
<janimo> ohsix, I was hoping someone knows so I don't have to look in the various kernel related packages :)
<ohsix> i think i might have it laying around already, one sec
<ohsix> ah nope i rm'd it
<cjwatson> seb128: I'm not happy with that either, that would be massive disruption
<cjwatson> DBO: do you have any more details?
<cjwatson> DBO: which architecture are you using?
<seb128> cjwatson, we got Jason and bdmurray to confirm and bug reports with duplicates
<seb128> cjwatson, using amd64
<cjwatson> does it happen on i386?
<soren> Sorry, which binaries are we talking about?
<seb128> cjwatson, i.s got asked to block the amd64 binaires
<cjwatson> soren: eglibc
<soren> Erk.
<cjwatson> argh
<seb128> soren, https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/721469
<ubottu> Ubuntu bug 721469 in eglibc (Ubuntu) "program startup fails with "Inconsistency detected by ld.so: dl-deps.c: 622: _dl_map_object_deps: Assertion `nlist > 1' failed!"" [Critical,Triaged]
<soren> I was *just* about to update my laptop and test systems. Phew.
<jcastro> soren: likewise
<highvoltage> jcastro: you're an omg!ubuntu writer now?
<jcastro> heh
<cjwatson> DBO: did you get literally the same error message with the upgraded libc?
<cjwatson> DBO: I'd appreciate a copy-and-paste of the error you get with the new libc packages
<ricotz> soren, hello, are you the right one who can look at a plymouth package?
<DBO> DBO, its the exact same error
<DBO> cjwatson,  Inconsistency detected by ld.so: dl-deps.c: 622: _dl_map_object_deps: Assertion `nlist > 1' failed!
<soren> ricotz: Not really, sorry.
<cjwatson> that's odd, because I would have expected at least the line number to change or something
<ricotz> soren, who might be?
* soren changed the topic of #ubuntu-devel to: eglibc broken in Natty. Bug 721469 | Archive: open | 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 | Current Friendly Patch Pilots: cdbs
<seb128> ricotz, subscribe ubuntu-sponsors
 * cjwatson hunts down the diff
 * soren actually didn't think he'd be able to set the /TOPIC
<seb128> cjwatson, http://launchpadlibrarian.net/64652847/eglibc_2.13~pre1-0ubuntu1_2.13-0ubuntu1~ppa1.diff.gz
<seb128> cjwatson, that's doko's upload
<cjwatson> it's OK, I can drive LP, it just takes a while :)
<seb128> cjwatson, well I had it in a tab open so I figured I would spare you to search for the ppa etc
<cjwatson> doko only applied one of the two patches in the upstream report, by the looks of things
<cjwatson> perhaps he thought it was one or the other; my reading is that it's a two-parter
<DBO> its two parts
<seb128> cjwatson, right, c.f what I copied on the other channel
<seb128> sorry for dispatching the info in 2 channels
<cjwatson> I'll do another test upload in a bit
<cjwatson> just want to do some reading here
<kees> the first patch could probably do s/assert (nlist > 1)/assert (nlist > 0)/ with s/while (1)/while (nlist > 1)/ to reduce the indentation insanity
<cjwatson> yes
<robbiew> seb128: so we've blocked the download now, right?
<seb128> robbiew, yes, downloads and mirroring are blocked
<robbiew> ok, thnx
<cjwatson> just putting all the pieces together here, since doko's previous test upload included a bump to 2.13 proper and a new .orig.tar.gz
<didrocks> DBO: it worths to wait and warn people :)
<bdmurray> seb128: this won't get caught by apport is that right?
<cjwatson> fortunately that's in Debian experimental so the orig exists publicly
<seb128> bdmurray, not sure but the people who reported it did without apport and it's an assertion and not a crash
<seb128> so it's likely apport will not report those
<ohsix> would be nice if apport did assertion reports, it catches them but then says they're not supported
<bdmurray> okay, I can't find any apport-crash tagged bugs about it either
<bdmurray> I was hoping to stop any from coming in
<soren> ricotz: What do you need, exactly?
<seb128> ohsix, it does support them if they have an assertion description as well
<seb128> but right, it's suboptimal
<ricotz> soren, i wanted to propose an update of the pretty old upstream version of plymouth, since 0.8.3 is pretty old too, i might be useful to take the current git version, i already packaged and using it
<cjwatson> if you do that make sure the quilt patches are intelligible
<cjwatson> and make extra sure that all the patches we still have on top of upstream are still there
<kees> seb128: apport is _supposed_ to catch asserts.
<cjwatson> catching asserts in the dynamic loader might be more of a challenge than usual ...
<soren> ricotz: Yeah, I'm totally not the right person to talk to about that. I just did a couple of drive-by's on Plymouth.
<kees> yeah, I think the dl asserts aren't actually hooked up to the glibc assert framework.
<kees> in which case, apport will ignore it
<ricotz> soren, so slangasek might be the right person?
<ohsix> seb128: ah
<ohsix> seb128: the most pernicious ones are assertions, too :]
<slangasek> ricotz: well, I'd be willing to review any proposed merges.  cjwatson has the gist of it though
<cjwatson> I don't have time for such a plymouth merge at the moment, unfortunately
<slangasek> ricotz: also I'm not thrilled about updating plymouth the week before feature freeze... if that was going to be done this cycle it would've been better to merge it sooner
<ricotz> slangasek, yeah i dont wanted to bug cjwatson, he seems pretty busy ;)
<cjwatson> (one of the problems for me with sponsoring merges is that I always find that reviewing them takes much, much longer than doing it myself)
<slangasek> ricotz: sorry, I meant: I don't have much to say on the subject besides what cjwatson already said
<slangasek> and by review merge I mean reviewing a UDD merge request, btw
<slangasek> anything short of that, and the comments about reviewing merges taking longer than doing merges apply
<lifeless> cjwatson: what takes up the bulk of that time?
<cjwatson> sorry don't have time to explain right now
<lifeless> cjwatson: another time then
<cjwatson> conversation too wide for this irc channel
<ricotz> slangasek, ok, i see
<cjwatson> eglibc 2.13-0ubuntu1~ppa2 uploaded to the same PPA
<cjwatson> amd64 built inside 20 minutes last time, so hopefully it'll do so again
<TheMuso> ogra: Started working on it yesterday, and will be finishing and uploading it first thing next week, if not sooner.
<arand> Complete RE history is ~2G, surprisingly small...
<ogra> TheMuso, awesome, thanks, TI was asking :)
<slangasek> cjwatson: hi, put two and two together and read through scrollback here; as it happens I was just about to push the orig.tar.gz for eglibc 2.13~pre1 onto the pristine-tar part of the UDD branch, is that going to slow you down if I do?  (Alternatively, is there something else you'd rather I be doing with my time in order to help rather than hinder? :)
<cjwatson> slangasek: I think that should be OK, as long as doing so doesn't change lp:ubuntu/eglibc itself?
<slangasek> cjwatson: it does because it adds a no-change commit to lp:ubuntu/eglibc to add the reference to the upstream tarball
<slangasek> cjwatson: so I'll just cool my heels until you're done, so I don't slow you down :)
<cjwatson> argh, upload rejected
<cjwatson> a no-change commit won't make a difference
 * cjwatson grabs the orig from LP instead
<cjwatson> slangasek: please note that the orig in Debian and the one in Ubuntu aren't the same - I think because of the manual
<slangasek> it's no change on the tip, it has a *large* batch of metadata :)
<slangasek> well, the upstream version number between Debian and Ubuntu isn't the same either
<cjwatson> I mean it won't slow me down
<slangasek> ok
<cjwatson> slangasek: it wasn't in the last upload - it will be in the next
<slangasek> ah
<cjwatson> at least I believe so.  2.13 in both, right?
<slangasek> he labelled it '2.13~pre1', I assumed that was deliberate?
<cjwatson> in the PPA he bumped to 2.13
<slangasek> ok
 * slangasek again, keeps his hands off
<slangasek> the tarball I imported is the one he labelled 2.13~pre1
<cjwatson> https://launchpad.net/~ubuntu-toolchain-r/+archive/test/+files/eglibc_2.13.orig.tar.gz
<slangasek> if there's a different one for 2.13, I can do merge-upstream again as needed
<cjwatson> ^- the above is the one I'll be using, anyway
<cjwatson> uploaded again, hopefully won't be rejected this time
<cjwatson> good, building
 * cjwatson goes off for a bit to watch Bones
<slangasek> cjwatson: so do I have this right that you're doing a ppa build first to verify the fix, and the upload goes to the archive only if it checks out?
<charlieS> slangasek,cjwatson: /me notes that someone needs to tell IS when to re-enable publishing syncing, so things can actually hit the archive.
<charlieS> if that ETA is within ~3.5 hours, no problem.
<slangasek> charlieS: I guess it *should* be within that time, but I don't know the full plan here
<slangasek> I came into this by accident because I was prepping a new eglibc upload to my multiarch ppa
<slangasek> cjwatson: I'm definitely at a loss to understand why doko built a new tarball rather than using the one already in Debian; are we sure that's deliberate?
<slangasek> doko: ^^ ?
<slangasek> cjwatson, doko: n/m, I see that there's an added GFDL manual on the Ubuntu side, that explains it
<slangasek> DBO: are you the designated tester for this fix? :)  The amd64 packages of eglibc are built: https://launchpad.net/~ubuntu-toolchain-r/+archive/test/+buildjob/2271568
<DBO> slangasek, I am not the designated tester, but I will do it in a little bit
<DBO> :)
<slangasek> DBO: cheers :)
<cjwatson> slangasek: tarball> GFDL divergence - we ship the manual
<slangasek> yep
<cjwatson> oh, you saw
<cjwatson> slangasek: and yes, PPA to verify
<slangasek> ok
<cjwatson> also the PPA has the testsuite disabled
<cjwatson> (for speed, I think)
<slangasek> ah :)
<ohsix> is vino supposed to turn off desktops effects when you connect? it's reaaaaally hard to use when compiz is running
<cjwatson> bdmurray: I don't suppose you would have time to test the amd64 libc6 in https://launchpad.net/~ubuntu-toolchain-r/+archive/test?
<RoAkSoAx> cjwatson: fwiw i just installed it and evolution doesn't crash anymore (which is what crashed in my case)
<bdmurray> cjwatson: sure I could do that
<cjwatson> the upstream commit that introduced this was 968dad0ab1f367a087ff4ad503b511dd0c565adc
<cjwatson> "Fix ordering of DSO constructors and destructors."
<cjwatson> FWIW I suspect LD_PRELOADing something random and pointless is a workaround
<cjwatson> oh, here, I bet that's it
<cjwatson> hypothesis: any dlopen will fail
<cjwatson> maybe only a dlopen of a sufficiently simple object
<cjwatson> e.g. one with no DT_NEEDED entries of its own
<cjwatson> anyway, this is basically just guesswork from code inspection
<aroman> hello, does anyone know how to change the "You may wish.." text as seen here: http://i.imgur.com/6yOIE.png In ubiquity? I've been ripping through its source tree looking for it, but i can't find it. Thanks :)
<cjwatson> just grep for it
<cjwatson> try not grepping for the whole string though, since there's markup around "release notes"
<cjwatson> bdmurray: anything?
<bdmurray> cjwatson: do know of any applications I should test?  evolution is behaving badly in a different way
<cjwatson> I'm planning to upload shortly on the strength of RoAkSoAx's test
<cjwatson> how does it misbehave?
<cjwatson> I have no idea, I'm just shuffling patches :P
<aroman> cjwatson: think this'll do the trick: find . | xargs grep -i "You may wish to read" (In the root directory)
<bdmurray> (evolution:1154): evolution-plugin-lib-WARNING **: can't load plugin '/usr/lib/evolution/2.32/plugins/liborg-gnome-exchange-operations': libexchange-storage.so: cannot open shared object file: No such file or directory
<cjwatson> hmm
<cjwatson> aroman: just use grep -r
<cjwatson> no need to mess about with find and xargs
<bdmurray> that happens on old with the old version of eglibc though
<aroman> lol i didn't even realize it had that param
<cjwatson> bdmurray: could you run 'strace -etrace=file -f -o evolution.trace evolution' and post evolution.trace?
<cjwatson> bdmurray: actually, never mind, that seems like a package bug to me; the linkage is there but the library is nowhere to be found
<bdmurray> cjwatson: okay
<cjwatson> I'm going ahead and uploading
<cjwatson> (to natty)
<kees> cjwatson: yeah, it doesn't seem to eat my VM, and ogg123 runs.
#ubuntu-devel 2011-02-19
<cjwatson> kees: thanks.  this was your modified approach for a much more compact patch, BTW
<cjwatson> so it's not what people on the forums have probably tested
<cjwatson> but the smaller it is the happier I am TBH
<kees> cjwatson: yeah. I forwarded this version to the upstream bug too
<slangasek> kees: you wouldn't happen to know why the WI tracker is sending me mails that "milestone "ubuntu-11.04-beta-1" is unknown/invalid", would you?  (I'm assuming it's the main WI tracker and not the Linaro one, based on the return address)
<kees> slangasek: not off the top of my head
<slangasek> mmk
<kees> slangasek: was that milestone removed from LP maybe?
<slangasek> no, I checked
<cjwatson> kees: oh, great, thanks
<kees> np
 * cjwatson taps fingers waiting for the .orig to upload.  I should have done this from chinstrap
<kees> hah, owchy
<cjwatson> ah, there it is
<cjwatson> aroman: can you lay off the nick changes, please?
<bryceh> heh
<cjwatson> (would have assumed it was pure spam if not for the prior reasonably on-topic question)
<bryceh> probably fscking around on some other channel
<cjwatson> yeah
<cjwatson> charlieS: ETA an hour or so until https://launchpad.net/ubuntu/+source/eglibc/2.13-0ubuntu1/+buildjob/2272038 finishes; we'll want the publisher run after that (which starts at :03) to be able to push to mirrors
<slangasek> cjwatson: publisher running manually?
<cjwatson> yes
<cjwatson> it's a bit slow 'cos it's been off for several hours
<slangasek> aha
<cjwatson> doing ls-lR now, push will be a few minutes from here
 * slangasek nods
* cjwatson changed the topic of #ubuntu-devel to: eglibc/amd64 fix pushing to mirrors | Archive: open | 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 | Current Friendly Patch Pilots: cdbs
<docdo90> how might I change a string in ubiquity?
<docdo90> after it's been installed, that is. i figure it's python, so that should be easy
<docdo90> anyone?
<gaurav_pawaskar> Hi guys, a doubt. After doing code change I am using diff command to get difference of files then using patch command to create a patch. It just updated the new file. Is that correct?
<__Midor> Hi, I'd like to contribute to Ubuntu. I'm fluent in C/C++, and know Java, Python and PHP. I have seen many revision controlling systems, but haven't submitted any patches. So where should I start to get used to the revision systems? any help?
<ari-tczew> __Midor: https://wiki.ubuntu.com/UbuntuDevelopment
<ari-tczew> https://wiki.ubuntu.com/MOTU
* ari-tczew changed the topic of #ubuntu-devel to: The channel topic is "eglibc/amd64 fix pushing to mirrors | Archive: open | 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 | Current Friendly Patch
<ari-tczew> @pilot in
* udevbot changed the topic of #ubuntu-devel to: The channel topic is "eglibc/amd64 fix pushing to mirrors | Archive: open | 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 | Current Friendly Patch 
<ari-tczew> @pilot out
* udevbot changed the topic of #ubuntu-devel to: The channel topic is "eglibc/amd64 fix pushing to mirrors | Archive: open | 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 | Current Friendly Patch 
* ari-tczew changed the topic of #ubuntu-devel to: "eglibc/amd64 fix pushing to mirrors | Archive: open | 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 | Current Friendly Patch Pilots: ".
<ari-tczew> @pilot in
* udevbot changed the topic of #ubuntu-devel to: "eglibc/amd64 fix pushing to mirrors | Archive: open | 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 | Current Friendly Patch Pilots: "., ari-tczew
<ari-tczew> @pilot out
* udevbot changed the topic of #ubuntu-devel to: "eglibc/amd64 fix pushing to mirrors | Archive: open | 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 | Current Friendly Patch Pilots: ".
<jmarsden> The "., looks odd in there ... ?
<ari-tczew> yes, pretty wrong
<ari-tczew> I guess @pilot bot should be improved.
<broder> why are there quotes in the topic?
* ari-tczew changed the topic of #ubuntu-devel to: eglibc/amd64 fix pushing to mirrors | Archive: open | 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 | Current Friendly Patch Pilots:
<ari-tczew> @pilot in
* udevbot changed the topic of #ubuntu-devel to: eglibc/amd64 fix pushing to mirrors | Archive: open | 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 | Current Friendly Patch Pilots: ari-tczew
<ari-tczew> @pilot out
* udevbot changed the topic of #ubuntu-devel to: eglibc/amd64 fix pushing to mirrors | Archive: open | 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 | Current Friendly Patch Pilots:
<jmarsden> That's better :)
<ari-tczew> without quotes looks ok
<ari-tczew> but why bot can't ingore quotes?
<broder> why should it have to? we've never had quotes in the topic
<ari-tczew> broder: it has*
<ari-tczew> broder: in order to avoid human error
<ari-tczew> cjwatson: I know it's weekend but if you could consider fix Merge-o-Matic while week... it can't update anymore.
<ScottK> ari-tczew: Code is here: https://code.launchpad.net/~ubuntu-core-dev/merge-o-matic/trunk  any core dev can push a fix if you get one.
<ari-tczew> ScottK: I don't have even error output.
#ubuntu-devel 2011-02-20
* cjwatson changed the topic of #ubuntu-devel to: Archive: open | 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 | Current Friendly Patch Pilots:
<psusi> cjwatson, can I pick your brain for a second about the 'p' partition separator issue for dmraid device paths?
<cjwatson> no point picking my brain at 2am
<ohsix> hi, it is _very_ hard to profile things without a frame pointer on x86_64, is there a way someone could be convinced to put actual binaries with them enabled in the dbgsym packages?
<cjwatson> there's not much of it to pick
<psusi> hehe... ok... maybe I'll catch you tomorrow ;)
<cjwatson> you always seem to try to find me on IRC at this kind of time
<cjwatson> it's not really very doomed to success - even if I'm here I'm only doing mindless things :)
<psusi> hehe... I'll look for you in the morning ;)
<psusi> was out of the house most of today... friend's had a baby
<cjwatson> congratulations (by proxy)
<psusi> hehe
<ohsix> is there an x86_64 "debug team"? it makes apport retracing pretty ugly too
<ohsix> right now i have to build everything myself or use 32bit, which isn't my daily driver
<psusi> why is it any harder on x86_64?  I thought the debug symbols had enough information to reconstruct the stack trace without frame pointers?
<cjwatson> dbgsym packages are just stripped symbols, not a separate build pass
<cjwatson> they can't use compiler options that the original binaries didn't use
<psusi> for that matter, why is -fomit-frame-pointer even used on x86-64?  makes sense with x86 since it has so few registers to begin with, but x86-64 has plenty.. how much difference does one more really make?
<cjwatson> I'm not aware of it being the default; some package must be turning it on
<cjwatson>      `-O' also turns on `-fomit-frame-pointer' on machines where doing
<cjwatson>      so does not interfere with debugging.
<ohsix> psusi: it's part of the calling convention
<cjwatson> unless that's the case on amd64, I don't know
<cjwatson> but if it is, there should be no problem by definition
<psusi> ohsix, eh?
<ohsix> ok here it is in another form: can someone be persuaded to enable it unconditionally for all packages
<ohsix> psusi: the x86_64 calling convention has something to say about frame pointers
<cjwatson> I think we need a more specific report
<psusi> ohsix, you mean it doesn't have one at all?
<cjwatson> e.g. which packages have this problem?
<ohsix> cjwatson: all of X and its peripheral packages, pixman, cairo, transmission, rhythmbox (but this is just for now, i've tried profiling/debugging other packages to the same end)
<psusi> ohsix, it looks like it has ebp to me... so it should be used
<cjwatson> the x86-64 ABI does not specify whether a frame pointer is used or not.
<ohsix> ehhhh
<psusi> that's what I thought...
<psusi> just like x86
<cjwatson> "%rbp  callee-saved register; optionally used as frame pointer"
<psusi> the register is there and it is suggested you use it, but you don't have to
<ohsix> ok
<cjwatson> http://www.x86-64.org/documentation/abi.pdf
<ohsix> right, thanks for looking it up; some windows brain damage might still be muddying my thoughts on the subject
<psusi> hehe
<ohsix> so how to get me some -fno-omit-frame-pointer, in a manner that supersedes -On
<psusi> I'm still curious though why it is any more annoying on 64 bit than 32?  I thought that on 32 bit without frame pointers, you just couldn't get a back trace without debug syms, but with them you could?  why is that any different for 64 bit?
<cjwatson> looks like it's the default on x86-64, which implies (from the gcc documentation) that it is possible to do stack frame analysis without a frame pointer on x86-64
<cjwatson> so I think you need a better way to drive gdb or whatever, not -fno-omit-frame-pointer
<ohsix> sampling profilers need the frame pointer to figure out the calling sitel and it can unwind with them in each sample cheaply as well
<ohsix> well, it's sysprof, perf, oprofile
<cjwatson> if you want to build with -fno-omit-frame-pointer, you'll need to rebuild stuff yourself
<cjwatson> we're not going to make an Ubuntu-specific change to diverge from the general GCC world's defaults on this
<ohsix> if that were the case why don't up to date tools work at all? like, none of them
<cjwatson> "if that were the case"> which statement of mine are you casting doubt upon?
<ohsix> you figure it might be one or two that work without frame pointers but with the "extra" undefined steps to the same end, but none of them do
<psusi> profiling is usually the sort of thing a developer does, not an end user, so you are expected to just build with the frame pointer I think...
<cjwatson> I've not noticed particular problems with gdb
<ohsix> the implication by gcc documentation
<cjwatson> debugging != profiling
<ohsix> heh
<cjwatson> http://gcc.gnu.org/ml/gcc-patches/2010-08/msg00300.html and thread is related
<ohsix> looking into why the packages are doing something in situ is debugging, and yo generally do it with a profiler
<cjwatson> I agree with psusi.  rebuild things locally if you need additional profiling facilities.
<ohsix> i just don't have _hours_ to find trivial problems that i want to report
<psusi> hrm... yep, looks like -O2 definitely does turn off frame pointers...
<ohsix> rebuilding to get the information that you'd get with a frame pointer, for the stuff i'm looking at, rebuilds half the system
<cjwatson> sorry
<cjwatson> looks like the frame-pointer decision was taken at a level well above Ubuntu in the toolchain world, and I don't think it would be appropriate for us to undo it
<psusi> hrm... interesting.. I just compiled int main() { int x = foo(); return x; } with -O2 and it is only 2 instructions: xor %eax, %eax, and jmpq <foo>
<ohsix> it's not undoing it heh
<ohsix> it's "can you do this in situ" or not
<psusi> if the profiler requires frame pointers, then no, you will have to rebuild locally to get them
<ohsix> rebuild the entire system
<psusi> no, just what you are trying to profile
<cjwatson> you can't add frame pointers to all the dbgsym packages without undoing the toolchain decision for the distribution in general
<ohsix> i'm just talking about the magnitude of the work in order to look at trivial things
<psusi> getting detailed timing measurements on a function by function basis is hardly looking at trivial things ;)
<ohsix> psusi: the 3 applicatioins that are involved need like 50 packages rebuilt
<cjwatson> only if you need to profile the entire stack, which isn't usually the case
<ohsix> i understand your position but i really can't belive you don't accept that it would be nice for fixing things if it was the other way around
<psusi> it would be nice, but it's not going to happen ;)
<ohsix> need the X server, libdrm libdrm-intel cairo pixman libc6 gtk some gtk engines, transmission and some of its deps, and rhythmbox
<cjwatson> there are many things I accept, but they generally tend to involve things where it's kind of in time to fix them
<cjwatson> in this case it is far too late; the discussion should've been had way back
<psusi> though I am curious why gcc decided to turn on omit-frame-pointer with -O2 on amd64... it doesn't seem like it would add much so I would have left it off
<cjwatson> psusi: the people who did the x86-64 port thought it was a good idea
<cjwatson> not so much "gcc decided"
<ohsix> cjwatson: i'll look into this some more; i've already read the old threads some time ago, but for a distro the cost in debugability is probably too high for any point made in them
<cjwatson> ohsix: I have to say, this is never something I have run into
<cjwatson> so I don't see it as a major cost
<ohsix> well you're not me, i try and triage every little bug i find with performance and there are a lot of them, and i can't often get satisfactory answers without days of work for even the most trivial among them
<cjwatson> you're trying to make statements about the cost to the distribution for debuggability in general
<broder> i'm still confused about not having a frame pointer is a problem - gdb can give me a backtrace for anything if i have the debugging symbols
<cjwatson> and I'm saying that I don't think the cost is that general
<ohsix> broder: sampling profilers sample ip and the frame pointer to unwind later
<ohsix> cjwatson: it makes perf useless
<cjwatson> and that people doing this kind of sweeping performance work are likely to need to build substitute versions of packages anyway
<broder> so why couldn't they just capture the stack insted
<broder> ?
<psusi> jesus christ, how the hell did gcc optimize this that much?  this function doens't even have a stack frame!
<cjwatson> unless you're doing performance analysis but not changing anything, which seems less useful
<ohsix> broder: 1000, 10000 times a second, even if they could, how would you read the traces?
<cjwatson> set up an autobuilder to do the builds for you, it wouldn't take long
<micahg> !ohmy > psusi
<ubottu> psusi, please see my private message
<broder> ohsix: you can post-process for a stack trace easily enough if that's what you want
<ohsix> psusi: leaf functions are beholden to their calling sites, and if they're idempotent they can be replaced entirely
<ohsix> broder: if you could, why doesn't perf, sysprof, oprofile or the other profilers do it?
<broder> presumably because nobody's implemented it yet?
<ohsix> broder: they need point in time samples, thats how they work
<broder> right. they need point in time samples of the stack trace. so take point in time samples of the stack, and backsolve
<ohsix> you know every monotonic time x and the information it yields is statistical
<cjwatson> in any case, this discussion should be had with the gcc x86 backend maintainers and the maintainers of the profiling tools in question.  Ubuntu's too narrow a forum.
<broder> ohsix: yes, i understand how statistical profiling works. you're still not explaining to me why it's not possible to do that after the fact if you can extrapolate a stack trace, which debuggers experimentally can
<ohsix> cjwatson: i don't propose changing the toolchain, that'd actually be pretty silly, it's just desirable for the stuff you actually run to let you introspect a bit
<psusi> wow... well now I understand why amd decided that the caller should clean up the stack... that kind of upset me at first since caller cleanup usually generates smaller code.. I didn't think caller cleanup could generate both smaller and faster code sometimes
<cjwatson> the stuff you actually run != the stuff somebody else actually runs
<ohsix> broder: if it was possible i'm pretty sure you could pick a maintained profiler today and get useful output with it
<cjwatson> you can't make a coherent argument for which packages should have this treatment.  this is why it's a toolchain decision
<ohsix> cjwatson: i guess, but not on anything else than ubuntu
<ohsix> it's a distro decision, they either care or don't
<cjwatson> it would be unhealthy for Ubuntu to diverge from the rest of the x86-64 wowrld here
<cjwatson> *world
<cjwatson> while in principle distros can change anything, I don't agree that this should generally be a distro decision
<ohsix> the only argument i could make, which i haven't; is that i find i need to do this very often, and its with lots of packages
<ohsix> so you don't see the value in not having to rebuild half your system locally to do something that should be trivial?
<psusi> ohsix, why do you frequently need detailed timing measurements for every single function that a large, complex program calls?  usually you only profile the functions in the program, not every library it calls as well
<ohsix> psusi: while its not every, it is still a _lot_
<ohsix> psusi: case in point 2 applications are making a third go nuts, and theres little indication which part it is
<cjwatson> ohsix: I see the value, but it doesn't override other considerations
<ohsix> are there others?
<cjwatson> there's also value in having our general optimisation strategy be at least vaguely similar to other distributions and to upstream!
<ohsix> sure
<ohsix> theres value in everything going upstream
<cjwatson> http://old.nabble.com/x86_64-callgraph-support-td21947441.html is relevant
<cjwatson> (sorry, nabble is annoying but I didn't find a better URL quickly)
<cjwatson> points out that oprofile should be fixed to use dwarf2 unwind information
<ohsix> hm
<cjwatson> and Andi Kleen knows what he's talking about for x86-64
<ohsix> what about perf? it has it already
<cjwatson> fix that, and now the profiler works better for everyone
<psusi> cjwatson, since your brain seems to still be working pretty well, I'm going to throw the 'p' problem at you and see if you have any thoughts on it tonight, or can sleep on it.  to sum up: dmraid and parted now always add 'p' before the partition number when figuring the device name for the partition.  gparted and kpartx only add the 'p' if the previous char is a digit.  They need to agree, so which method is right?
<cjwatson> I don't have a clue, I've never been able to keep this straight :)
<psusi> hehe
<ohsix> brb
<cjwatson> I would tend to trust the lower-level tools, if that's the upstream behaviour
<psusi> I know I need to patch something to fix this for natty, but I'm having trouble deciding which
<cjwatson> does the kernel code have an opinion on this?
<psusi> which is lower?  dmraid and parted or kpartx?
<psusi> the kernel just does what it is told... it doesn't care what you name it
<cjwatson> hm, I would probably have said dmraid but I suppose I'm not certain
<cjwatson> the kernel sometimes has defaults for device names
<psusi> but someone said that other devices the kernel used ot have to name that could end in a digit it added the 'p' only if it already ended in a digit
<ohsix> cjwatson: since you talked me down a bit i'm gonna do more due diligence wrt. the tools i've been trying to use
<cjwatson> perf: http://lwn.net/Articles/409797/
<psusi> that makes sense to me and to the gparted maintainer... so I'm tempted to patch dmraid and parted to do that
<cjwatson> psusi: it's certainly more aesthetically pleasing the kpartx way
<ohsix> cjwatson: yar i saw it in the git log for the kernel
<psusi> I agree
<cjwatson> I'm a bit worried about the continuing device name transitions though
<cjwatson> s/continuing/repeated/
<psusi> and causes less disturbance than always adding it...
<ohsix> ah, the clincher: - only support for x86-32. I need to split some arch specific code from
<ohsix>   generic and add at least x86-64 support.
<cjwatson> ohsix: right, but no suggestion that it isn't possible
<ohsix> well now i'm just angry :D cuz i have to rebuild anyways
<cjwatson> psusi: who was it that made a comment on parted-devel about several different bits of software having been carefully lined up upstream to do the right thing here?
<cjwatson> was it one of the LVM guys or something?
<ohsix> the real problem is the rhythmbox guys aren't taking my traces and the proof i've offered in many forms as evidence thatit's doing what i say it's doing; and i'd like to get it fixed
<ohsix> i think its the theme engine, transmission does the same thing but to a different degree; transmission just really pegs the x server doing it
<cjwatson> if I were debugging that sort of thing I think I would work at the X protocol level rather than at the C call graph level
<cjwatson> but perhaps I shouldn't armchair-quarterback you
<ohsix> my laptop is my daily driver & spending a dayor two building stuff is not my idea of fun, not to mention i don't have the bandwidth to commit to get the patches
<ohsix> i tried xtrace, it shows the operations but not why it takes so long in the server
<ohsix> perf would show traces all the way through if it worked
<cjwatson> psusi: you seem to be already having the conversation upstream, anyway, and there've been quite a few knowledgeable responses on parted-devel etc. already
<ohsix> plus the fix wouldn't come from trace info from X, you'd sooner look to pixman/cairo, then the theme poking at it
<ohsix> that there are lots of probably useless messages at the connection level should be moot; cuz theres probably fixes in that area needed inboth the video driver and the theme engine
<ohsix> i might just have to throw my hands up until circumstances are different, fetching/building so much stuff is a blocker
<cjwatson> psusi: Hannes' "linux scheme since the dawn of time" is the more aesthetically pleasing one, which is good I guess
<cjwatson> ohsix: sounds like you have great motivation to improve perf :)
<ohsix> cjwatson: i don't know enough to judge if the effort is worth it; also the aforementioned "evidence", perf isn't good enough
<ohsix> oh, i do have a good suggestion for apport information to gather
<ohsix> get the theme engine name!
<ohsix> it has a ridiculous impact on things
<cjwatson> the apport maintainer is not currently logged in hre - if you want to suggest apport changes, you'll need to file a bug
<cjwatson> *here
<cjwatson> sounds like a reasonable thing to collect
<ohsix> first bug i'll file is against rhythmbox :]
<ohsix> so how easy is it to rebuild everything without making a mess for a subset of the packages? i messed with apt-build to do it on a handful of packages, but that seems generally untenable
<cjwatson> quite a bit of work's gone into sbuild et al; I'd use that if I needed this kind of thing
<ohsix> from what i do know i'd want to set the origin so it'd be easy to downgrade when i'm done, and at best provide just top level package names & have the deps handle themselves like apt does
<psusi> cjwatson, if you mean a few days ago, that would be me ;)
<psusi> cjwatson, I'm kind of disappointed at how few responses there have been though, especially from the redhat guys that maintain dmraid... I think the right thing to do is patch dmraid and parted, but I'd like some upstream approval
<ohsix> o noes skew
<ohsix> another question: is there a warning displayed when partman is having its way with the disk in ubiquity
<cjwatson> I don't understand the question
<ohsix> resizing or rather, interrupting a partition resize is something that's bad to do
<cjwatson> normally resizers are actually very careful to ensure that interruptions are safe
<cjwatson> they have to be in case of power loss
<ohsix> i haven't seen the installer since 10.10 & i haven't resized since ever, but someone on the support channel interrupted it during a resize and lost his disks
<cjwatson> then that should be a bug on the resize program, not patched around by UI in the installer
<ohsix> even if the resizer is perfect there are sill operations that aren't atomic and will trash the drive
<ohsix> its just bad luck for it to happen, but it's a real risk
<psusi> oh nevermind... I see some responses now.. damn redhat mailing lists mangle reply-to header.. I didn't get the replies directly
<cjwatson> such as?
<ohsix> heh
<ohsix> filesystems have metadata that aren't in sync in the same manner as they would be if they're mounted in the resizer
<ohsix> stopping in the middle of messing with the mft on ntfs can lose all of the directory entries on ntfs
<cjwatson> ah, ok, an abort in resize2fs when moving the inode table would be a problem, true
<cjwatson> I hate having to resort to UI warnings, but I suppose it might be necessary here
<cjwatson> file a bug then
<ohsix> just a general question anyways, i know a warning would look bad and 99.99% of the time supefluous
<ohsix> alright
<cjwatson> ideally we would determine when the resizer is in the dangerous bit
<cjwatson> that may not be feasible
<psusi> wait, how is it not interruption safe?  resize2fs only adds or removes inode tables, not moves them afaik
<ohsix> i'd just hate for my grandma to lose photos or anything on the computer, even though its supposed to be a safe-ish operation
<ohsix> psusi: power interruptions can come after the OS has asked the disk to flush something, but before it has
<ohsix> thats not "
<ohsix> er, that's not
<ohsix> "vghfy89uhcgfyug
<ohsix> not the problem but it is the bottom line, sorry about that
<cjwatson> psusi: see comment in e2fsprogs/resize/resize2fs.c above move_itables
<ohsix> key hitting enter with my pinky :]
<cjwatson> search for "This is scary"
<ohsix> cjwatson: i dunno if the documentation is out there to find what operations are unsafe in reality on ntfs, and that'd be the big one
<cjwatson> ohsix: in some modes, ntfsresize emits a warning when it's about to start with the unsafe operation
<cjwatson> s
<ohsix> a power removal warning would suffice
<cjwatson> search for resize_warning_msg in the source
<ohsix> cjwatson: ah cool
<psusi> I thought that everyone understands that resizing a partition is inherently a dangerous operation and bad things happen if the power goes out in the middle, but that resize2fs tried to make sure it would be ok, and generally did a fairly good job of it
<ohsix> i will; you've giveb me a lot to do tonight
<ohsix> psusi: my mom doesn't, i do
<cjwatson> psusi: the bulk of the resize (copying data around) is safe, but there's twiddling at the end that isn't
<psusi> ARGH!@$
<ohsix> psusi: i figure ubiquity is more for her than me :]
<psusi> that single pixel border can't resize thing is really starting to get on my nerves
<cjwatson> ohsix: the same problem would exist in d-i
<ohsix> cjwatson: sure, but i didn't help her put debian on the netbook i gave her
<cjwatson> (d-i's used in Ubuntu too)
<psusi> cjwatson, by move inode table, this code means evict inodes from the tables that are going away right?  shouldn't they be copied to the destination, then the directories updated with the new inode number?  so if interrupted then at worst you have the inode duplicated and either fsck should deal with that, or resize2fs should be able to resume?
<cjwatson> the code comment says it's moving things in place
<cjwatson> probably best to read the code if you have questions about it
<cjwatson> I'm willing to take it at its own word that it's dangerous
<ohsix> ultimately it can't be done perfectly safely like a filesystem can make some failure assurances in how it works
<cjwatson> the reason I don't want a warning throughout resizing is that the time-consuming part of resizing is typically implemented safely
<ohsix> what a real fs driver can do though, is have the inode in core while its messing with the file
<ohsix> cjwatson: right
<ohsix> something that just says anything about removing power should suffice
<psusi> there's no reason it CANT be done safely... you might have to do some more work that will take longer, but...
<ohsix> psusi: you need some things to be atomic or restartable to be completely safe, you can't get that
<cjwatson> resize2fs is not notorious for emphasising performance over safety
<psusi> ohsix, sure you can
<cjwatson> if you can make its phase 5 safe, I'm sure they'd take a patch
<ohsix> if resize2fs put shadow copies in the new place then updated metadata it could be safe_r_
<psusi> that's basically what I just said I thought it did
<ohsix> but like i said, the lowest common denominator is power removal
<ohsix> right
<ohsix> for smaller structures it might be fine
<ohsix> the mft on ntfs is a large part of the drive, you could fragment it in the process to make it safer, but i'd have to see what it actually does
<ohsix> i've never had an mft split on any resizes i've donr
<psusi> as long as the mft doesn't have extents in the region you are truncating, you should not need to mess with it much when resizing
<ohsix> not with gparted anyways
<ohsix> right, but its supposed to be a percentage of the drive, the volume size & the mft is set as a ratio to support a certain number of files/directories
<psusi> that's just a mkfs default thing... don't have to maintain it when resizing
<psusi> it gets enlarged as needed
<ohsix> if you don't touch the mft you might not have any space for new files afer a resize
<ohsix> its moot though, if that's not what it does, i'll have to look
<psusi> also iirc, there was a registry key or something you could tweak to change that default size so you could decrease it to leave more free space or reserve more for many files... basically like when you set the inode ratio with mke2fs, only the mft can grow dynamically
<ohsix> in fact i've got storage available i could just try it out
<ohsix> psusi: i know, but the thing is it takes 20% of the disk or more, depending on how many files are on it, my point was that if you hit the mft you could have taken all the space for actual files, and to grow the mft
<psusi> OHHH!  when enlarging a fs, the bg descriptor table grows larger, so for block groups that contain a copy, that will shove the inode table to the right
<ohsix> split mft is another problem
<ohsix> it by chance can end up in the end, and need to be moved; iirc ntfsresize takes this into account wrt. what it is able to resize, and wont let you shrink it lower than the end of the mft
<psusi> ohsix, yea, that's what I thought
<ohsix> unless something is restartable theres always a power danger
<ohsix> it'd be awesome if they were though :D i see no reason why they couldn't, aside from lots of extra io for bookeeping and needing storage for it somewhere
<psusi> I've been giving some thought to making e2defrag restartable, but it would make it so much slower and more complicated...
<ohsix> can't you just go by inode, then a restart is start at x? :D
<psusi> it builds an entire new drive map in memory first, then starts relocating blocks from the old locations ot the new locations....
<ohsix> xfs goes by AG then inode and it's just 2 integers to restart, but it's cheap to start again as well
<ohsix> ah
<ohsix> maybe you can whip up a magic hash to get rid of the map
<psusi> that's why it's so fast ;)
<psusi> if you have enough memory no block gets written more than once
<psusi> and almost all of the IO is in large blocks... minimum seeking
<ohsix> right
<psusi> if you have enough memory to hold it all, it can actually manage to rewrite the whole fs in one big read and one big write
<ohsix> that's the best way to do it if you have some guarantees about interruptions
<ohsix> copying and leaving metadata to be updated until the last moment then marking the old area empty takes extra copies
<psusi> yea... and extra seeks... right now it reads all of the inodes, updates them, writes them back, then starts relocating blocks
<psusi> err, wait.. that's what the resize inode is for..
<psusi> is that only needed for online resize?  can resize2fs still work offline without the resize inode?
<ohsix> no idea
<cjwatson> yes
<psusi> ok, that makes sense then.. yea, phase 5 it says only runs if neccesary... not needed if you have a resize inode it sounds like
<psusi> whoa... copyright ted and powerquest inc?... interesting...
<ohsix> cjwatson: http://lwn.net/Articles/380582/
<ohsix> broder: you might like that as well
 * psusi wonders what ever happened to that project to make a Linux equivalent of WinIce... that was one slick debugger
<SchizoBunny|home> how do you get it to do that ^^
<psusi> ?
<ohsix> SchizoBunny|home: prefix your message with /me
<SchizoBunny|home> ok thank you
<psusi> ohh, hehe
<ohsix> anyways, with perf and sysprof the idea is to profile from the app all the way through the kernel, or between stuff in the kernel, the time it samples, how often it samples, and what it samples are hard constraints :[
<ohsix> perf is _great_ too, it's a shame
<psusi> someone posted an interesting problem this week with gdb on askubuntu.com... if you tell gdb to print strlen(something) you get garbage results... if you assign strlen to another pointer and use that to call it instead in the gdb expression, it works...
<ohsix> different calling convention from the gdb stack frame setup to make the call from the sound of it
<ohsix> apparently systemtap works, but only with -fasynchronus-unwind-tables; how can i find out of that's set on ubuntu
<ohsix> http://gcc.gnu.org/ml/gcc-patches/2010-08/msg00337.html uhuhuh
<ohsix> http://gcc.gnu.org/ml/gcc-patches/2010-08/msg00342.html <- by who indeed
 * ohsix keeps looking
<ohsix> it looks like h.j. lu just did it by fiat
<ohsix> cjwatson: apparently the 386 abi says the same thing about the frame pointer register and its optionalness, people writing unwinders just used it if it was there; and that didn't make it to x86_64
<ohsix> http://gcc.gnu.org/ml/gcc-patches/2010-08/msg00223.html
<ohsix> http://gcc.gnu.org/ml/gcc-patches/2010-08/msg00354.html google engineers uncondtionally enable it on x86_64
<psusi> ohsix, from that mail it sounds like it's been the default on x86 for some time too and it suffers the same problem.. they are saying that profilers just need fixed to deal with not having a frame pointer
<ohsix> nah it was a proposal to enable it on x86
<ohsix> sampling profilers that work in the kernel aren't going to be fixed for that
<psusi> umm... I read it as a proposal to enable it on -64 and the response was that x86 has been doing it for a while and not had complaints?
<ohsix> exactly the opposite
<psusi> and that if you fix the profiler for -64, x86 would benefit as well
<ohsix> yes
<ohsix> because _64 already has the proposed change
<ohsix> which is unconditional -fomit-frame-pointer
<psusi> >>> Can we find if oprofile works with -fomit-frame-pointer on 32bit Linux/x86.
<psusi> >> It doesn't for user space. The problem is that you would need
<psusi> x86 already had it enabled
<ohsix> apparently async unwind tables are enabled on x86_64 by default too
<ohsix> psusi: that refers to oprofile, not gcc; it's a gcc list, the posts are about enabling -fomit-frame-pointer for x86
<psusi> ohh, I see now
<psusi> I was going to say, I thought that if you wanted -fomit-frame-pointer you used to have to explicitly enable it
<psusi> at least for -O2... -O3 turned it on iirc
<ohsix> it was discussed in 2004 as well http://gcc.gnu.org/ml/gcc-patches/2004-08/msg01033.html
<ohsix> unfortunately there doesn't appear to be much discussion other than gdb working with dwarf info; gdb has an opportune time to read such things indeed ;]
<ohsix> http://gcc.gnu.org/ml/gcc-patches/2004-08/msg01124.html holy hyperbole batman
<ohsix> poor guy
<ari-tczew> ttx: ping
<gaurav_pawaskar> Hi guys, anybody knows algorithm to convert UTF-16 to UTF-8?????
<artfwo> in python, I'd just call something like unicode(a, 'utf-16').encode('utf-8')
<gaurav_pawaskar> anything in c or c++..
<artfwo> gaurav_pawaskar, there are quite a few libraries for unicode conversion, like libicu
<artfwo> you might also want to use something like http://utfcpp.sourceforge.net/ for a lightweight solution
<gaurav_pawaskar> thank you artfwo...
<penguin42> gaurav_pawaskar: I'm not sure, but iconv might be able to do it - man 3 iconv
<Turl> hi all
<Turl> can someone take a look at https://bugs.launchpad.net/ubuntu/+source/libva/+bug/595661 ?
<ubottu> Ubuntu bug 595661 in mplayer (Ubuntu) "please support h264 hardware acceleration on certain intel video cards" [Undecided,Confirmed]
<Turl> it would be great if libva could be synced from debian
<lamont> ScottK: https://launchpad.net/~lamont/+archive/ppa should have 2.8.0-0.1 once it finishes cranking through the process
<lamont> ScottK: it passed my smoketest, but it really needs a more thorough looksee before I'm comfortable uploading it, and that won't happen today while I'm sleepy...  care to take a gander?
<lamont> and actually, that's 2.8.0-0.1~lucid1
<debfx> Turl: libva sync has already been requested: bug #721978
<ubottu> Launchpad bug 721978 in libva (Ubuntu) "Sync libva 1.0.8-3 (main) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/721978
<Turl> debfx: nice, let's hope it makes it in time then
<Otacon22> humm.. I would like to know why the indicator-applet-session is taking 468MB of ram on mu ubuntu 10.04
<Otacon22> *my
<ohsix> Otacon22: is that what smem says?
<Otacon22> smem?
<ohsix> Otacon22: apt-get install smem
<Otacon22> ok wait
<Otacon22> in the meanwhile
<Otacon22> USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
<Otacon22> otacon22 22433  0.0  6.0 829112 492468 ?       Sl   Feb06  17:23 /usr/lib/indicator-applet/indicator-applet-session --oaf-activate-iid=OAFIID:GNOME_FastUserSwitchApplet_Factory --oaf-ior-fd=32
<Otacon22> and i have 8 GB of ram.
<Otacon22> otacon22@PhoenixDesktop:~$ smem | grep indicator-applet
<Otacon22> 22434 otacon22 /usr/lib/indicator-applet/i     1132    27228    27629    35312
<Otacon22> 22433 otacon22 /usr/lib/indicator-applet/i    14852   484856   485257   492504
<Otacon22> The second one should be the right one
<ohsix> hm odd
<ohsix> can you post the output of /proc/22433/smaps to a pastebin
<Otacon22> sure
<Otacon22> http://pastebin.com/X0yNzxcB
<ohsix> nearly 500mb heap heh, that's probably a bug, is there something you can do to make it consume a bit more ram each time you do it?
<Otacon22> I don't know, i'm looking
<Otacon22> I'm looking the strace in real time
<Otacon22> Humm, nothing interesting
<Otacon22> What could i do to investigate more about it?
<ohsix> no idea, do you even use fast user switching?
<Otacon22> never
<Otacon22> i just lock the screen
<ohsix> theres some stuff on dbus exposed by it but i don't exactly know what, something could be using that
<ohsix> it's only using 5 megs here
<Otacon22> but i use to keep the pc on for long time, and it seems to happen after long time
<Otacon22> otacon22@PhoenixDesktop:~$ uptime
<Otacon22>  19:38:41 up 16 days,  3:45, 25 users,  load average: 0.83, 0.88, 0.77
<ohsix> 25 users?
<ohsix> terminals right
<ohsix> you're using maverick right, and just regular gnome?
<Otacon22> no, 10.04 lts
<Otacon22> yes, regular gnome, standard theme
<ohsix> whatever it is, for only being 16 days it's happening pretty often, or it's a huge leak, dbus-monitor can show what might be invoking the indicator applet; and if it's not there i can't say much about what's left to look at :\
<Otacon22> signal sender=:1.72 -> dest=(null destination) serial=484535 path=/org/ayatana/indicator/session/menu; interface=org.ayatana.dbusmenu; member=ItemPropertyUpdated
<Otacon22>    int32 19
<Otacon22>    string "restart-label"
<Otacon22>    variant       string "Riavvia..."
<Otacon22> there are a lot of this
<Otacon22> "riavvia" is italian and means reboot
<ohsix> ok
<ohsix> install d-feet, you can look at :1.72 and see what binary it is coming from
<Otacon22> (the ram used by the indicator is growing up)
<ohsix> sounds like you installed an update that changed the menu to restart, i dunno why it keeps being told to change it tho
<Otacon22> Connect to session bus?
<Otacon22> and then search for :1.72 ?
<ohsix> yea
<Otacon22> Unique Name: :1.72
<Otacon22> Command Line: /usr/lib/indicator-session/indicator-session-service
<Otacon22> indicator-session-service humm
<ohsix> hm i'm mistaken then, i don't know what a null destination means
<Otacon22> following the strace of indicator-session-service i see:
<Otacon22> read(18, "\1\0\0\0\2\0\0\0\0\0\0\0 \0\0\0openvpn.client.s"..., 1024) = 48
<Otacon22> read(18, 0x26372e0, 1024)               = -1 EAGAIN (Resource temporarily unavailable)
<Otacon22> maybe some trouble with a vpn?
<Otacon22> (the ram used by the indicator is still growing up)
<ohsix> could be, i dunno why session service is taking all the memory though
<Otacon22> What should i do? just kill and restart it or do you have some others ideas to try?
<ohsix> i'm getting about 2 messages a minute to my session indicator
<ohsix> ehh, you can kill it; i was more looking into an out & out direct cause of the memory growth
<ttx> ari-tczew: pong?
<ari-tczew> ttx: is it worth merging maven-ant-helper 7.2 from Debian?
<ttx> ari-tczew: looking
<ttx> ari-tczew: it's worth it only if we need it as a build-depend on something else
<ttx> ari-tczew: so I'd wait until we actually *need* it
<ari-tczew> ttx: there is no DEPWAIT on maven-ant-helper.
<ttx> ari-tczew: right, so my answre would be: no. :)
<ari-tczew> ttx: OK.
#ubuntu-devel 2012-02-13
<ScottK> That seems to happen to me about every 10th startup.
<lamont> [pid  8787] +++ killed by SIGSEGV (core dumped) +++
<lamont> so... I'm gonna go with something a shade more drastic
<ScottK> That'll do it.
<ScottK> Cutting torch?
<lamont> [ 2123.191192] soffice.bin[8681]: segfault at 238 ip 00007fe5d314bdca sp 00007fffe2cc9338 error 4 in libvclplug_genlo.so[7fe5d30e7000+8a000]
<lamont> amusingly, 4 pids, 4 segvs
<RAOF> lamont: Do you have two monitors?
<RAOF> lamont: If you do, you're looking at bug #916357
<ubottu> Launchpad bug 916357 in libreoffice (Ubuntu) "[Upstream] soffice.bin crashed with SIGSEGV in X11SalGraphics::GetResolution()" [Medium,Fix committed] https://launchpad.net/bugs/916357
<RAOF> (ie: libreoffice crashes early in startup if you've got two displays enabled)
<lamont> RAOF: interesting
<lamont> and yes
<poolie> zul, can you tell me anything about replacement of keystone with keystone-light in precise?
<lamont> I'd also be interested in knowing what I did to make unity (3d) panel not show up when I login that way... I was going to give 3d a try again and see if video could keep up with it now
<RAOF> Log in what way?  With two monitors enabled?
<lamont> hrm... I wonder if that's it
<lamont> 2d works just fine, panel on far left like it wants to be
<RAOF> You mean the launcher?
<RAOF> Works fine for me :)
<lamont> yeah, launcher.  'tever
<lamont> and given that it doesn't work on my laptop either, I suspect that I removed some package that it cares greatly about
<lamont> or something
<lamont> but that was 6 months ago
<RAOF> Possibly?  It should depend on everything that's absolutely necesary for, though.
<lamont> it's possible that I stabbed it in a config file as well
<freeflyi1g> its ok to do it this afternoon
<poolie> is there a policy about installation of ubuntu packages not being interactive by default?
<psusi> the only kind of interactive they can be is having debconf questions
<poolie> right, but there should be no debconf questions at the default level?
<psusi> well, don't go asking questions that aren't required at the low priority
<poolie> right
<psusi> if it must have an answer to install, then use high priority to force it to be asked... but if it's more of an optional thing you can do with sensible defaults, use low priority to prevent it from being asked on normal installs
<poolie> the specific thing is that bug 930444 complains (amongst other things) keystone asks a question
<ubottu> Launchpad bug 930444 in keystone (Ubuntu) "keystone-manage: error: argument command: invalid choice: 'db' from postinst" [Critical,In progress] https://launchpad.net/bugs/930444
<poolie> for which it could probably reasonably guess a default
<poolie> i'm trying to work out if that is bad by definition, or just undesirable
<psusi> afaik it's undesirable to have non low priority questions that aren't really required
<poolie> i think so too, i just wondered if that was written down
<lifeless> poolie: the installer experience needs TB ack to change IIRC
<lifeless> poolie: packages not installed by default on desktop or server or cloud could ask more but its desirable not to ask questions unless really needed
<poolie> i agree
<poolie> i wondered if the TB had ever stated this
<poolie> not a big deal, just wondered
<poolie> https://bugs.launchpad.net/ubuntu/+source/keystone/+bug/931236
<ubottu> Ubuntu bug 931236 in keystone (Ubuntu) "keystone install is unnecessarily interactive" [Undecided,New]
<bkerensa> slangasek: Were having a loco meeting and I brought up you talking at our global jam
<slangasek> bkerensa: which channel's that on?
<slangasek> oh, I've fallen off the loco channel, haven't I
<slangasek> silly proxy crashes
<bkerensa> slangasek: I figured you had too many channels and needed a break :) I do that sometimes
<pitti> Good morning
<ajmitch> morning pitti
<pitti> hey ajmitch
<micahg> pitti: would it be possible to deNEW amarok (breaking dist-upgrades) and libindicate (preventing a bunch of other rdeps from building)
<pitti> sure, I'll do some poking at NEW
<micahg> thanks
<malkauns> wtf my xorg is at 100% :( :(
<alkisg> How can I lock down gsettings? The "lockdown" paragraph from http://live.gnome.org/dconf/SystemAdministrators doesn't seem to apply to precise, e.g.:
<alkisg> $ dconf update
<alkisg> fatal: Error opening directory '/etc/dconf/db': No such file or directory
<dholbach> good morning
<apw> pitti, then that probabally accounts for it, just more off it, therefore i have noticed
<apw> heh and you getting fingered for the uploads is funny
<bkerensa> dholbach: If a package has "Standards-Version: 3.8.2
<bkerensa> " it should be bumped up?
<dholbach> bkerensa, if it's a package which exists in debian it does not make sense to just update the string - it's a diff we would have to carry on our own
<dholbach> in that case just leave it to the maintainer to update it
<bkerensa> ok
<dholbach> if it's an ubuntu package and you want to update the standards version make sure you have a look at what changed from that version of debian policy to what's current and make adjustments to the package if necessary - then you can go and update it if you like
<cjwatson> there's an upgrading checklist in Debian policy
<cjwatson> the point isn't to have the string current at all costs, it's to act as a reminder for what version of policy the package has been checked up to
<bkerensa> I see
<cjwatson> and yes, I agree with dholbach, don't in general update it as an Ubuntu delta
<bkerensa> I was mostly looking for some small work to do before bed and I saw a package that had a outdated standards version and had never heard about the policy
<bkerensa> :)
<seb128> thanks to whoever helped to get webkit built during the w.e and sorry it was so bumpy and that I screwed up the .symbols stuff on friday evening
<dholbach> bkerensa, /usr/share/doc/debian-policy/upgrading-checklist.* might be interesting then :)
<bkerensa> dholbach: Does harvest take awhile to update? I have noticed that it lists quite a bit of potential work that already has fixes released and is not really potential :)
<dholbach> bkerensa, it should be updated every 30m
<bkerensa> :D
<bkerensa> dholbach: Hmm well I have been checking it for a few days now and I see plenty of Bugs that have been fixed months ago
<bkerensa> :)
<bkerensa> https://bugs.launchpad.net/ubuntu/+source/banshee/+bug/905260 <-- for example is listed under banshee on harvest and was fixed quite awhile ago
<bkerensa> :D
<ubottu> Ubuntu bug 905260 in banshee (Ubuntu) "typo located ../src/Extensions/Banshee.OpticalDisc/Banshee.OpticalDisc.Dvd/DvdService.cs:92 " [Undecided,Fix committed]
<dholbach> bkerensa, can you please file a bug on harvest with a few examples which are listed?
<bkerensa> surely
<cjwatson> that's fix committed not fix released ...
<dholbach> it can be a bug in harvest or in one of its data providers
<cjwatson> although one might argue that's not a particularly interesting opportunity in some contexts
<bkerensa> :D
<dholbach> hum, if apport does not open the firefox window correctly, how can I report the bug?
<dholbach> "firefox is already running blah blah blah..."
 * dholbach just had X crash a couple of moments ago
<bkerensa> https://bugs.launchpad.net/harvest/+bug/931343
<ubottu> Ubuntu bug 931343 in harvest "Harvest lists opportunities which likely are not real opportunities" [Undecided,New]
<ricotz> YokoZar, hello :), no wine 1.4~rc2-0ubuntu1~ppa1 for lucid in the ppa?
<MacSlow> mvo, ping
<ScottK> pitti or Riddell: sip4 just hit binary New on i386 only due to a new arch:all package.  It'd be nice to get it let out soon so we don't have archive skew problems.
<ScottK> python-qt4 will hit binary New as well, but for all archs, so it's less urgent.
<mvo> MacSlow: welcome back
<MacSlow> mvo, thx
<pitti> ScottK: NEWed
<pitti> Sweetshark: do you happen to know about the current status on libo on armhf?
<Sweetshark> pitti: no progress there, unless it magically solved itself without a patch
<Sweetshark> pitti: bug 900636
<ubottu> Launchpad bug 900636 in libreoffice (Ubuntu Precise) "libreoffice ftbfs on armhf" [High,Confirmed] https://launchpad.net/bugs/900636
<ogra_> pitti, linaro is supposed to be working on it
<ogra_> (no idea who, or whats the status, ask rsalveti)
<pitti> ah, thanks for the pointer
<herton> pitti, hi, there were some issues in the copying of the lucid kernel to -proposed (https://bugs.launchpad.net/kernel-sru-workflow/+bug/921562/comments/5). I did some new checking, so some issues probably happened before but only now the stable bot is checking them.
<ubottu> Ubuntu bug 921562 in Kernel SRU Workflow "linux: 2.6.32-38.85 -proposed tracker" [Undecided,In progress]
<pitti> herton: ah, nice work on these checks! will clean up now
<pitti> herton: fixed; does your bot query archive.u.c., or launchpad directly?
<pitti> hallyn: you uploaded two diffferent qemu-kvm versions to lucid-proposed, rejecting both; please merge and reupload
<pitti> jdstrand: do you want to re-evaluate bug 673925 with the current version?
<ubottu> Launchpad bug 673925 in freerdp (Ubuntu Precise) "[MIR] freerdp" [Medium,In progress] https://launchpad.net/bugs/673925
<pitti> jdstrand: or were you already involved enough with the fix to say "ok now"?
<pitti> ScottK: new python-qt4 pulls in pyopengl; do we really want this in main?
<pitti> ScottK: also, pyopengl uses python-support
<herton> pitti, thanks. It queries archive.u.c just for the latest version in -proposed, but uses launchpad api to check the components
<pitti> herton: ah, then you might already be able to run it again with the updated results
<herton> pitti, ack, will take a look here
<pitti> ScottK: oh, nevermind; python-qt4-gl wants to go back to universe
<herton> pitti, some new things came up now on the component check for the lucid -proposed: http://pastebin.ubuntu.com/840458/
<pitti> herton: -preempt is not supposed to be in main
<pitti> need to run out for some errands, bbl
<pitti> I'll check the others later
<herton> pitti, right, just referring to the new matches on the pastebin I posted
<herton> ok
<herton> pitti, this -preempt is a issue with an old copy of the bot running, I reported to brad (bjf) already, just ignore it for now
<yofel> mterry: hi, do you have time to look at these MIR's? 930384 and 930112. They're required for gtk3 support in kubuntu.
<mterry> yofel, k, I'll either look at them or assign them with a day or two
<yofel> thanks
<jdstrand> pitti: wrt 673925> I spent quite a bit of time iterating with upstream on the fix in 925657, so yes I think it is fine. I commented in the bug
<pitti> jdstrand: great, thanks!
<pitti> herton: I promoted the non-preempt stuff from your pastebin
<herton> pitti, nice, thanks. Launchpad still doesn't report the changes yet, will wait some minutes and check again.
<seb128> how do I tell bzr bd-do (debian dir only vcs) to no fail because a patch doesn't apply ... I want to use it to refresh patches which is the whole point of using that command
<theozaurus> Hi, I'm attempting to package up Passenger with Ruby 1.9.3 on Lucid using packages taken from Precise and dotdeb. I've got stuck though in that when I upload to PPA and it attempts to build it cannot find the rake command. Running it locally is fine and it has the correct build dependencies to get Rake, however when running dh_clean it just gives me "Command not found" on the PPA build server. How can I better debug the situation?
<cjwatson> check your Build-Depends
<cjwatson> no doubt locally you just already have that package installed
<theozaurus> cjwatson: I'll have another look!
 * cjwatson looks at the failed build logs
<cjwatson> No sign of rake in your Build-Depends; that'll be the problem
<cjwatson> also I think I'd recommend calling rake simply as rake, not as '/usr/bin/rake1.9.3'
<cjwatson> "Remove rake as a dependency, this is included in Ruby 1.9.3
<cjwatson> " - it's still a separate binary package
<theozaurus> cjwatson: In my Ruby build it packages it
<theozaurus> cjwatson: I've switched it to rake1.9.1 which seems to be working. I think the issue is that it creates symnlinks to rake1.9.3 which Make doesn't pick up. Could that be possible?
<theozaurus> cjwatson: That was very fast work in finding the repo!
<cjwatson> theozaurus: perhaps you need a ruby-defaults upload in your PPA if you want the unversioned symlinks to be present
<cjwatson> theozaurus: Google is occasionally my friend :-)
<theozaurus> Ah i'll have a look at the ruby-defaults package. As you may have guessed debian packaging is very new to me so just trying to feel my way through.
<cjwatson> hm, the business of rake shipping /usr/bin/rake (as a real file, not a symlink!) and ruby1.9.1 shipping /usr/bin/rake1.9.1 even in the primary Ubuntu archive is kind of odd
<cjwatson> so having ruby-defaults do that would introduce an awkward file conflict
<pitti> cnd: are you aware of the non-applying patch in xserver-xorg-input-evdev? are you working on it ATM, or need help:?
<cjwatson> I wonder what the motivation behind that was
<cnd> pitti, no, I'm not aware
<cnd> which patch?
<pitti> cnd: see https://launchpadlibrarian.net/92570339/buildlog_ubuntu-precise-i386.xserver-xorg-input-evdev_1%3A2.6.99.901%2Bgit20120126-0ubuntu1_FAILEDTOBUILD.txt.gz
<cnd> hmm... why didn't I get an email about the build failure?
<cjwatson> theozaurus: maybe you are better off calling it as rake1.9.1 for now; if you want rake1.9.3, you need a Build-Depends on ruby1.9.3 which contains it (in your PPA)
<cjwatson> theozaurus: the builders start off with basically a blank slate - a very minimal system which is only able to build minimal C packages - and only install what they're told to install
<cnd> pitti, I'm fixing it right now
<cnd> thanks!
<pitti> cnd: thank you!
<cnd> pitti, I should have received an email about the build failure, right?
<pitti> yes
<cnd> hmm...
<cnd> pitti, any ideas why I didn't?
<pitti> cnd: not off-hand; usually both the uploader and the changed-by: addresses get the mail
<cnd> ok
<micahg> cnd: no build failure mails on syncs from Debian made with syncpackage ATM
<cnd> micahg, this wasn't a sync though...
<micahg> ah
<bonks> when are new versions of subversion added to apt? just curious because v1.7.* has been out for a while but apt only has 1.6.17
<micahg> bonks: when they're added to the archive for that particular release
<bonks> micahg: do you guys have eta's?
<micahg> I don't know what it's planned for precise, feature freeze is in 3 days
<cjwatson> subversion's mostly maintained by Debian
<micahg> s/what/that/
<cjwatson> the packaging, I mean
<cjwatson> we'd generally not update before they do
<herton> pitti, I fixed the checks for -preempt on the script which checks components, there are still 2 mismatches now: http://pastebin.ubuntu.com/840578/
<cjwatson> and yeah, I expect too late for precise now
<cjwatson> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=656966 is a Debian bug of sorts for the upgrade
<bonks> cjwatson: thanks
<ubottu> Debian bug 656966 in libsvn-java "libsvn-java: New version available" [Important,Open]
<cjwatson> ah, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=621692 is clearer
<ubottu> Debian bug 621692 in src:subversion "Please package svn 1.7" [Wishlist,Open]
<herton> pitti, as I understand, linux-versatile should be in main as well, since the linux image and other versatile meta packages are also in main
<herton> the other is one preempt case I got now checking properly the -preempt packages
<pitti> herton: linux-image-versatile is, linux-versatile isn't
<pitti> herton: but linux-versatile was in universe in lucid final, too
<cjwatson> I wouldn't be opposed to getting subversion 1.7 merged in if the Debian maintainer got it uploaded, but it's a bit complex to duplicate the work
<bonks> cjwatson: understood
<herton> pitti, any reason linux-versatile shouldn't be moved to main? Seems an error it being on universe
<pitti> herton: mostly for consistency; it wasn't in final
<herton> pitti, ok, I'm ignoring the linux-versatile then on the script, just linux-headers-lbm-2.6.32-38-preempt then must be moved to universe
<pitti> herton: ack, done
<pitti> good night everyone!
<herton> pitti, thanks, I think everything is sorted now
<cjwatson> Sweetshark: hmm, does there exist a usefully current branch for the LO packaging?
<Sweetshark> cjwatson: a git branch on http://anonscm.debian.org/gitweb/?p=pkg-openoffice/libreoffice.git;a=summary
<cjwatson> gotcha, thanks
<cjwatson> Sweetshark: if I just send a patch for the Debian branch are you likely to merge it before precise?
<cjwatson> I'm working through everything on http://lintian.ubuntuwire.org/tags/preinst-uses-dpkg-maintscript-helper-without-predepends.html but don't want to upload LO frivolously
<Sweetshark> cjwatson: yes, I am rebasing on debian-experimental-3.5 regularly.
<cjwatson> cool.
<hallyn> is apt-get autoremove supposed to be smart?  should it never remove packages which were manually installed?
<hallyn> (cause boy did it mess up on saturday on my lucid server)
<Ampelbein> It is supposed to only remove packages that were automatically installed and are neither Depends or Recommends of another package.
<SpamapS> Hm, the new bzr package merging stuff seems to work quitew ell
<hallyn> Ampelbein: wonder if landscape messed with the db or something
<SpamapS> slangasek: ping? I need your opinion on a merge conflict in cyrus-sasl2..
<SpamapS> slangasek: http://paste.ubuntu.com/840754/
<SpamapS> slangasek: seems like the wildcard is safe enough here.
<ScottK> pitti: Thanks.
<infinity> SpamapS: I see nothing wrong with the wildcard.
<infinity> SpamapS: Just makes it easier to rev the packaging.
<SpamapS> infinity: agreed, ok, that makes me feel better about it.
<infinity> SpamapS: (I'd probably back it up even further, in case the major changes, to be honest, since that's the sort of thing people are prone to forget about)
<infinity> But meh. :)
<SpamapS> can't fix the world.
<infinity> I try.
<infinity> Then I get tired and nap.
 * SpamapS hears a guitar strumming in the background and wonders if we're about to hear infinity's rendition of What's Going On
<infinity> I'll spare you.
<slangasek> SpamapS: wildcard looks safe to me
<randomuser> i know this is inappropriate here, the other channels seem to address mostly cut-and-paste issues; I'm looking for a reason why a default NM controlled interface would spam DHCP requests
<SpamapS> slangasek: thanks
<SpamapS> so now I need to figure out how this works when I do a package merge and some, but not all, patches were applied. do I do a debcommit w/ all 'unapplied', then another one subsequently, with patches applied?
<slangasek> SpamapS: I would apply all the patches before committing, personally
<SpamapS> slangasek: tried that.. failed miserably
<slangasek> how do you mean?
<SpamapS> slangasek: .pc is "gone" now.. so I'd be adding it again..
<slangasek> why is .pc gone?
<SpamapS> slangasek: because the merge came from a place where the patches were unapplied
<SpamapS> so .pc is marked as removed in the merge
<slangasek> did the maintainer change the source format?
<slangasek> and switch back to v1?
<SpamapS> slangasek: definitely not.. but the merge appears to remove .pc/*
 * slangasek scratches his head
<slangasek> barry: ^^ do you know what's going on with this package merge?
<SpamapS> you can see it very easily if you merge lp:debian/cyrus-sasl2 into lp:ubuntu/cyrus-sasl2
 * barry reads scrollback
<SpamapS> http://paste.ubuntu.com/840797/
<SpamapS> (that is after resolving the 2 conflicts)
<slangasek> I expect the patches to be unapplied as part of the merge because of the new bzr-bd quilt handling, but not to try to remove .pc
<barry> SpamapS, slangasek: i'll bet it's bug 929164
<ubottu> Launchpad bug 929164 in Ubuntu Distributed Development "Build problem after `bzr merge`ing source packages" [Undecided,New] https://launchpad.net/bugs/929164
<barry> SpamapS: if you can confirm, and possibly hold off on uploading a new version, we can get the bzr guys to help us diagnose the problem
<slangasek> barry, SpamapS: I just checked, and .pc is present in the source branch
<slangasek> so I think this is related to bzr-bd quilt
<SpamapS> barry: yes I had that problem too.. worked around it by doing 'debcommit'
<barry> really.  that's interesting
<SpamapS> but of course, that committed unapplied patches
<barry> yep
<slangasek> SpamapS: why does 'quilt push -a' not work?
<psusi> cjwatson: was it /boot/efi or /boot/grub/efi where the efi system partition needs to be mounted?
<barry> SpamapS: probably, the conflicts prevented the patches from getting applied at the end of the merge
<SpamapS> slangasek: it only applies a few of the patches.
<SpamapS> slangasek: I didn't investigate further why that is
<slangasek> SpamapS: is debian/patches/series bustificated?
<barry> SpamapS: so the package is cyrus-sasl2?
<SpamapS> yes
<slangasek> I would expect 'quilt push -a' to be the right thing to do after the merge, to get it back to the state UDD wants
 * barry tries it locally
<SpamapS> err
<SpamapS> barry: yes its cyrus-sasl2
<SpamapS> slangasek: not sure, looking now
<SpamapS> slangasek: except then you'd like, re-modify all the files, and add new untracked files into .pc ..
<slangasek> perhaps?  maybe bzr manages to pick them up in .pc automatically?
<slangasek> but 'bzr add' in any case
<barry> SpamapS: so to resolve the conflicts i just took the debian version
<SpamapS> I'm going to try setting the quilt-commit-policy to 'applied' and see if that resolves it
<barry> SpamapS: so, i've confirmed that when bug 929164 is hit, all you need to do is `bzr rm` (no arguments) to be able to build the source package (no debcommit required, but probably has the same underlying effect on the package)
<ubottu> Launchpad bug 929164 in Ubuntu Distributed Development "Build problem after `bzr merge`ing source packages" [Undecided,Confirmed] https://launchpad.net/bugs/929164
<barry> SpamapS: but this causes failures: quilt push -a && bzr commit -m'quilt push -a'
<SpamapS> where exactly can I set this 'quilt-commit-policy' ?
<SpamapS> There's no docs for it..
 * SpamapS should perhaps ask jelmer
<SpamapS> jelmer: here?
<barry> SpamapS: yeah, i did find them, but i forget where
<barry> you add them to debian/bzr-builddeb.conf which is an ini file iirc
<jelmer> SpamapS: hi
<SpamapS> jelmer: I'm trying to figure out how to set the quilt-commit-policy = applied
<barry> hi jelmer!  more data on bug 929164
<ubottu> Launchpad bug 929164 in Ubuntu Distributed Development "Build problem after `bzr merge`ing source packages" [Undecided,Confirmed] https://launchpad.net/bugs/929164
<SpamapS> seems to me that the policy should be inferred from debian/source/format , shouldn't it?
<jelmer> SpamapS: what are you trying to do exactly?
<jelmer> SpamapS: quilt-commit-policy by default is disabled
<SpamapS> jelmer: I want patches applied to a branch when I commit
<jelmer> SpamapS: ah, ok - in that case you want 'echo [BUILDDEB]\nquilt-commit-policy = applied\n' > debian/bzr-builddeb.conf
<SpamapS> jelmer: mostly for the greater purpose of testing why merging lp:debian/cyrus-sasl2 into lp:ubuntu/cyrus-sasl2 ends up deleting the entire .pc directory
<jelmer> SpamapS: that would probably be because the smart quilt merging kicks in - it unapplies patches during the merge
<barry> SpamapS here's where jelmer describes configuration: http://article.gmane.org/gmane.linux.ubuntu.devel/34747
<barry> jelmer: and when there's conflicts the patches don't get applied because the process stops, which makes sense
<dupondje> Somebody here around with some gdebi/apt knowledge? Got a weird issue with a package, depends are mysql-client-5.1 | mysql-client, but get the following error on install (gdebi: http://paste.ubuntu.com/840803/ or apt http://paste.ubuntu.com/840800/ )
<jelmer> SpamapS, barry: also http://bazaar.launchpad.net/~bzr-builddeb-hackers/bzr-builddeb/trunk/view/head:/doc/user_manual/configuration.rst
<barry> jelmer: thanks, i'll add a link to that from the packaging guide
<SpamapS> ok so the unapply is fine, but how do I magically then tell the smart quilte merging to re-apply ?
<SpamapS> if I quilt push -a myself.. I have to then bzr add ..
 * SpamapS is so confused
<lifeless> SpamapS: orly :P
<SpamapS> Ok, so doing   bzr merge deb ubuntu, then resolving the conflicts, then doing 'bzr rm', then 'quilt push -a', then 'bzr add', then debcommit .. that worked
<jelmer> SpamapS: so, the issue seems to be that if there are conflicts during the patch applying we leave the tree as is
<barry> jelmer: could `bzr resolve` when there are no more conflicts clean everything up?
<SpamapS> to be clear, there were no conflicts during the _quilt_ patching, only during the bzr merge process
<barry> SpamapS: after that last debcommit though, can you still `bzr bd -S` ?
<SpamapS> barry: yes!
<barry> SpamapS: cool.  failed for me, but let me try again with your recipe
<SpamapS> barry: both before and after the debcommit actually
<jelmer> barry: yeah, I guess we could have that apply the quilt patches. It might be a bit odd though
<SpamapS> jelmer: I'd be in support of that.. since that is the point at which the manual merge is over.
<SpamapS> Even if it just reminded me to quilt push -a / bzr add .. :)
<jelmer> SpamapS: ok, that's certainly possible
 * jelmer pastes a bit of IRC conversation in the bug
<barry> SpamapS, jelmer confirmed that SpamapS's recipe works.  which makes sense since that's probably exactly what happens if there are no merge conflicts
<cjwatson> psusi: /boot/efi
<psusi> cjwatson: fixed up the installation-guide again... left in the section about some systems needing /boot, but still got rid of all of the nitty gritty and largely obsolete details about CHS and LBA, and added a section for GPT
<cjwatson> ok
<dupondje> Somebody here around with some gdebi/apt knowledge? Got a weird issue with a package, depends are mysql-client-5.1 | mysql-client, but get the following error on install (gdebi: http://paste.ubuntu.com/840803/ or apt http://paste.ubuntu.com/840800/ )
<dupondje> anyone ? :)
<BenC> dupondje: it's not an issueâ¦you don't have either of those packages installed
<dupondje> BenC: shouldn't gdebi fetch the missing depend ?
<BenC> dupondje: your original pastebin showed you using dpkg -i
<dupondje> http://paste.ubuntu.com/840803/
<BenC> dupondje: that's still dpkg output
<BenC> dupondje: why not just do "sudo apt-get install mysql-client"
<dupondje> jtaylor made the output btw
<dupondje> not having a precise system here
<BenC> dupondje: this is likely a better question for #ubuntu, either way
<dupondje> see https://bugs.launchpad.net/ubuntu/+source/automysqlbackup/+bug/931123
<ubottu> Ubuntu bug 931123 in automysqlbackup (Ubuntu) "Sync automysqlbackup 2.6+debian-1 (universe) from Debian testing (main)" [Wishlist,Incomplete]
<Ampelbein> The "real" question is: Is it a bug in the package to list a non-existend depends first. As in "mysql-client-5.1 | mysql-client", where the former is not available in Ubuntu.
<BenC> It's not a bug at all for that to happen
<BenC> The whole reason for "foo | bar" syntax is for that very reason
<BenC> Well, for similar reasons, but that is one of them
<Ampelbein> See, that's what I thought. But there are developers around who won't sync such a package, because "I like stuff gdebi installable".
<dupondje> It looked just fine to me also indeed ...
<broder> Ampelbein: then fix gdebi
<BenC> Yeah, because apt will likely install it just fine
<Ampelbein> broder: I don't even use gdebi.
<broder> err, in spite of the highlight, that was directed at the abstract "you" :)
<SpamapS> Hm, is a versioned build-depends that will prevent building cyrus-sasl2 against an old buggy version of heimdal enough to keep a delta from Debian?
<BenC> arguably, in this case, I would think that the "mysql-client-5.1" portion of that depend is pretty pointless
<BenC> since it and all mysql-client-x.y packages should provide mysql-client anyway
<SpamapS> BenC: agreed
<SpamapS> in this particular case, just depend on mysql-client
<dupondje> thats maby true
<dupondje> but is it a reason to make a delta with debian ?
<dupondje> as its not really wrong ...
<BenC> dupondje: it is actually not needed, so wrong in a very real sense
<BenC> So I would say delta with Debian and provide the feedback that it's superfluous to depend on mysql-client-5.1 specifically when mysql-client is perfectly fine by itself
<Laney> it's actually a real package too, so yeah
<BenC> The OR syntax was meant for things like "exim4 | mail-transport-agent" where you have competing packages to satisfy the same dependency but one is preferredâ¦this is not such a case
<broder> uh, that may be a design goal, but is it actually documented that it *must* be used that way?
<superm1> BenC: noticed you did a mythtv upload to precise a few weeks ago just now.  can you please ping someone in #ubuntu-mythtv (daviey or myself or tgm4883) to merge changes like that so that they don't get missed on uploads that happen from the VCS?
<dupondje> ok its clear :) going to bugreport in debian
<dupondje> thanks!
<BenC> broder: mucking up the dependency resolution process needlessly is against any design goal, IMO :)
<BenC> superm1: Yeah, sorryâ¦will do next time
<superm1> thanks
<superm1> we've got many more uploads planned for precise so i've merged it and it will just come up on one of those at some point
<SpamapS> barry: so, after all that merging, it turns out that the package can be synced. I figure you guys have the two branches locally that can reproduce the problem.. so once I hear back from you I will sync the package.
<SpamapS> Hey is merge-o-matic broken?
<barry> SpamapS: i'll let jelmer answer about that.  in my original bug report i had lots of problems getting back to a state where the bug showed up.  but i think we now have enough information for jelmer to do awesome things
<SpamapS> I uploaded wget on Friday.. still shows needing a merge
<Ampelbein> SpamapS: Seems last updated: 10-Feb-2012 04:10
<SpamapS> barry: should be easy if we just push the branches to +junk and put the links in the bug
<barry> SpamapS: good idea!  will you do that or do you want me to do it?
<SpamapS> barry: already doing it :)
<barry> :)
<SpamapS> barry: ok, comment posted. syncing
<barry> SpamapS: thanks
<Riddell> TheMuso: what did you find out KDE frontend to orca?
<Riddell> about..
#ubuntu-devel 2012-02-14
<smoser> slangasek, smb i'd appreciate your thoughts on my most recent comments in bug 898373 .
<ubottu> Launchpad bug 898373 in cloud-init (Ubuntu) "fsck.ext3: Device or resource busy while trying to open /dev/xvda2" [High,Confirmed] https://launchpad.net/bugs/898373
<smoser> it seems that cloud-init actually could be causing the fsck race, but i'm not sure how to avoid it.
<MrBusiness> Does anyone happen to have a high-level guide to understand what a GNU/Linux "service" is, and the attendant concerns for someone needing to write one?
<mfisch> MrBusiness: that's a pretty broad question, what are you trying to do?
<MrBusiness> Well, let me see if I can put it into words
<MrBusiness> I've been assigned to convert some manner of program into a service. I see that much of what constitutes a service appears to be a set of commonly accepted scripting interfaces, as outlined in /etc/init.d/skeleton, at least assuming I have not already erred in my understanding.
<MrBusiness> Now, that said, I also notice that in order for these things to work, the services usually write their PID to a file upon launching so that the appropriate PID can be interacted with during later service calls to that process.
<mfisch> MrBusiness: hold on
<MrBusiness> Which gives me cause to wonder: if I wanted to variations on the same binary running as separate services, does this imply that I would need some sort of advanced logic with which to distinguish them and their respective PID identification files?
<mfisch> MrBusiness: so if I were writing a new service, I would use upstart, not the old sysv stuff
<mfisch> MrBusiness: look in /etc/init for examples, and here:  http://upstart.ubuntu.com/
<MrBusiness> Is upstart based on the same sort of thing that came out of RedHat, or is it specific to Ubuntu?
<mfisch> MrBusiness: I do not know the origins, I do know that Ubuntu uses it
<mfisch> MrBusiness: and so did webOS
<geofft> If you're talking about old-style (init.d) services, you may be interested in start-stop-daemon, especially with --pidfile and --make-pidfile
<MrBusiness> hmm, ok
<MrBusiness> Well, that's helpful. At this point, I guess I need to figure out just what it is that I'll be interacting with.
<mfisch> the last service I wrote watched a directory using inotify and responded to changes there
<mfisch> there are dozens of ways to talk to your service of cours
<MrBusiness> I see. That's somewhat less than reassuring, but so it goes.
<geofft> upstart (Ubuntu), systemd (Red Hat), etc. are relatively similar at a high level -- you write a config file describing the service that init uses, instead of a shell script
<geofft> and yes, the init.d style is just a shell script with conventions.
<MrBusiness> Ah, ok. That's probably what I'm dealing with here then.
<mfisch> MrBusiness: you said it's a program, so how do you communicate with it now?
<MrBusiness> at the moment, the only methods of communicating with it are defining its startup parameters
<MrBusiness> after that, it just sits around doing its business periodically
<mfisch> MrBusiness: so it runs on a schedule?
<MrBusiness> yes
<RAOF> Does it perhaps then just want to be called periodically by cron, rather than being a daemon itself?
<mfisch> RAOF: not a bad plan.
<MrBusiness> No, because it was designed to run continuously. There are parts that run as cron jobs, but those parts are not being registered as services.
<RAOF> Ok.
<mfisch> MrBusiness: do you need to change those start-up parameters while the code is running now?
<MrBusiness> Part of what these things do is watch directories, and I don't really have control over their requirements. I was told to make them into services, and so I am attempting, as best I can, to carry out that order, whether it ultimately comes to good or ill.
<RAOF> MrBusiness: http://www.netzmafia.de/skripten/unix/linux-daemon-howto.html seems like a reasonable HOWTO for the nuts and bolts of converting something to a daemon.
<MrBusiness> No, I don't need to change them. I just need to get them installed and running as proper services.
<mfisch> MrBusiness: I wonder if all you need to do is make a simple upstart script and fire it up
<RAOF> Yeah.  If they're already daemonising properly you should just be able to write a very simple upstart script.
<MrBusiness> Might be. I'm working from some legacy code to do this. I haven't quite described what is, in my view, the really onerous aspect of the thing, but it's difficult for me to describe it.
<MrBusiness> Let me see if I can explain it
<mfisch> MrBusiness: my last service was a python script that I wanted running when the system started
<mfisch> MrBusiness: I just put command-line args inside the upstart job, you could use a conf file or gsettings to change params too
<MrBusiness> One common thing I see in most services is that typically they tend to refer to a daemon process, of which there is typically only a single instance executing on a given system.
<MrBusiness> I don't think that is a reasonable assumption for the processes I am attempting to convert into services.
<MrBusiness> In fact, I am certain that there may be multiple instances of these processes, each running to perform similar tasks, but on different locations
<MrBusiness> and that each must be considered its own service
<mfisch> MrBusiness: so you have upstart fire-up either N jobs or have a wrapper that reads a conf file and fires up N instances
<StevenK> So, this sounds more like a deployment problem, rather than related to Ubuntu development ...
<mfisch> MrBusiness: you can put actual shell scripts into upstart so you could read a conf file in there
<MrBusiness> Perhaps it is. Should I be in some kind of #deployment channel?
<RAOF> MrBusiness: Perhaps rather than talking about terminology (service, process, etc) we start talking about *behaviour*.  What do you need to change in their behaviour?  Do you need the ability to monitor them with âstatus $SERVICENAMEâ?  Do you need them to be started on boot?  Do you need them to be restarted when they crash?
<mfisch> MrBusiness: upstart will restart crashed services, which is nice
<MrBusiness> let me think for a minute
<RAOF> #upstart might be a better channel for this, indeed.
<mfisch> MrBusiness: may I suggest that if you truly have N processes watching a bunch of directories that you write a wrapper (python would be easy) to do all the watching (started by upstart) and fire up your program based on what directory changed?
<mfisch> RAOF: agreed.  hopefully we gave him enough to consider
<MrBusiness> mfisch, a nice idea, but unfortunately beyond my power to enact at this point
<MrBusiness> I don't have sufficient control of the requirements. it sounds to me like I get to watch this thing blow up in my face. rather than spend anymore time on it, I think I'll just update my resume.
<MrBusiness> Gotta know when to hold 'em, gotta know when to fold 'em.
<RAOF> MrBusiness: I obviously don't have a good grasp of your requirements, but nothing so far sounds particularly difficult; drop by #upstart and I'm sure we can set you up with something.
<MrBusiness> alrighty
<MrBusiness> Only one thing about it though, is that I'm not even certain that I'll have upstart available to me. I may be rolling with the init.d methods, because that may be the only thing available on the target environment.
<andersk> Depending on what you need, www.supervisord.org (âsupervisorâ package in Ubuntu) might be helpful.
<pitti> Good morning
<dholbach> good morning
<tjaalton> do packages that have not passed the NEW queue need a FFE if they are not accepted before FF?
<pitti> tjaalton: no, usually we count the upload date
<tjaalton> pitti: ok, good
<pitti> NEW processing seems to be a bit on the slow side these days
<tjaalton> no wonder, everyone trying to squeeze things through ;)
<dupondje> Who did the MoM pages again ? :)
<dupondje> cjohnston: ?
<dupondje> cjwatson :)
<tumbleweed> dupondje: launchpad.net/merge-o-matic
<dupondje> tumbleweed: https://merges.ubuntu.com/ is stuck it seems :)
<dupondje> not updated since 10/02
<cjwatson> SpamapS: yes, MoM is crashing at the moment; thanks for noting that, I'll take a look
<tumbleweed> dupondje: ^ there you go, then :)
<dupondje> indeed ;)
 * cjwatson was going through scrollback ...
<cjwatson> ValueError: process failed 2: dpkg-source -x gexiv2_0.3.1-1.dsc /srv/patches.ubuntu.com/unpacked/g/gexiv2/0.3.1-1
<cjwatson> I think I'll just nuke that - the .orig checksum in Debian's .dsc is wrong, but there's a subsequent version which unpacks properly
<cjwatson> it was in experimental anyway
<cjwatson> will need to wait until the current run has finished though
<tumbleweed> dak accepted a .dsc with an incorrect checksum?
<cjwatson> it's dated a while back
<cjwatson> actually I think what happened is that it was correct at the time, but it was removed from experimental and then a new version was uploaded later with a different orig ...
<tumbleweed> yeah, looks likely
<cjwatson> which dak should have caught in principle but evidently hadn't retained the information
 * cjwatson pokes DktrKranz with a spoon
<cjwatson> evil reusing of version numbers
<DktrKranz> huh?
<cjwatson> $ grep '^ .\{32\} .*orig' gexiv2_0.3.1-*.dsc
<cjwatson> gexiv2_0.3.1-1.dsc: 50d15e0f84c799fccea9aa7c28fd971a 29525 gexiv2_0.3.1.orig.tar.gz
<cjwatson> gexiv2_0.3.1-2.dsc: fc2a438af67af7c9f27bbe0c19b31c98 30155 gexiv2_0.3.1.orig.tar.gz
<cjwatson> should've been 0.3.1+<something>, really (but too late now)
<DktrKranz> hhm, right
<cjwatson> so I now need to convince merges.ubuntu.com that it's never heard of 0.3.1-1 and that those aren't the droids it's looking for
<dupondje> apt-get install alzheimer
<dupondje> :)
<apw> does debootstrap honour http_proxy or is there a trick to it ?
<cjwatson> it should just honour it
<cjwatson> I mean it just calls out to wget
<cjwatson> it doesn't have any specific proxy code
<apw> cjwatson, ahh thanks, seems there is a sudo zapping those variables ... sigh
<pitti> apw: set the proxy system-wide in control-center -> network -> proxy
<pitti> that'll write it into /etc/environment instead of just your local session gsettings
<cjwatson> Anyone with some C++/Qt clue fancy making packagesearch build?  I've tried backporting the obvious patch (from http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=639076) from upstream svn but it still fails, and even after I fix up some silly missing-translation bits in upstream svn the current tip fails to build in different ways in both precise and unstable.
<ubottu> Debian bug 639076 in src:packagesearch "packagesearch: FTBFS: keymaker.h:64:10: error: a template-id may not appear in a using-declaration" [Serious,Open]
<cjwatson> I'm on the verge of just removing the binaries from the archive (since they're keeping old libept1 in place) but thought maybe some Qty person might care.
<pitti> Riddell: do you know whether/how I can supply extra cmake build options (-DWITH_FFMPEG=OFF) in a standard dh7 debian/rules?
<nebuchadnezzar> hello
<nebuchadnezzar> anyone to answers some questions about iso generation? there is nobody on #ubuntu-iso :-/
<Riddell> pitti: you need to override dh_configure or whatever it is
<pitti> /usr/share/perl5/Debian/Debhelper/Buildsystem/cmake.pm doesn't say something obvious
<Riddell> override_dh_auto_configure: dh_auto_configure -Skde -- -DCMAKE_USE_RELATIVE_PATHS=ON
<Riddell> pitti: something like that?
<pitti> Riddell: nice, thanks! trying that
<i8x4> Lost most my compiz key bindings with the latest upgrade; anyone else experience this?
<nebuchadnezzar> I would like to use more than one repository in addition to the ubuntu one when generating a CD
<pitti> Riddell: worked like a charm
<Riddell> pitti: now you just need to persuade all the canonical and gnome developers to do the right thing and change to cmake :)
<pitti> -ENOTENOUGHMAGIC :)
<seb128> Riddell, it's not friday, no trolling! ;-)
<Eren> is there a repository for infinality font patches, or should I get the source and compile it with these patches?
<rbasak> I seem to have a package that FTBFS using fakeroot, but works under real root. I can pin down the cause further, but has anybody seen anything like this before? Any advice?
<cjwatson> rbasak: not unheard of; can you narrow that down a bit?
<rbasak> I think it might be a build-dep that provides an executable that segfaults unless it's root. Testing that hypothesis now.
<m4n1sh> ev: there?
<ev> m4n1sh: hi
<m4n1sh> hello Evan
<ev> how's it going?
<m4n1sh> I am trying to integrate diagnostics in alm
<m4n1sh> the thing is that there are two files
<m4n1sh> one is about panel intergation
<m4n1sh> but also contains lots of Panel plumbing code
<m4n1sh> ev: since you have written the code, if you can quickly tell me which all thing is g-c-c specific
<m4n1sh> sot that I can quickly integrate it. Need to get this release out by tomorrow.
<ev> m4n1sh: preferences-panel.c contains the g-c-c bits. whoopsie_daisy_preferences_panel_init is the entry point.
<m4n1sh> okay
<m4n1sh> checking
<m4n1sh> ev: under canonical contributor agreement?
<ev> m4n1sh: that's a good question.
<m4n1sh> if that codebase is under whoopsie then I think it can apply
<m4n1sh> but if I take it and keep it under acitivity-log-manager repo
<m4n1sh> then it should not apply
<m4n1sh> not a lawyer, but I guess that can be the case
<ev> just checking
<m4n1sh> okay
<ev> m4n1sh: I'm checking with the right authorities :). I wouldn't worry too much about getting it merged in today. The code already exists in the archive, and I think moving it from being its own page to being a GtkNotebook page is more of a UI freeze issue than a feature freeze one.
<m4n1sh> yes
<m4n1sh> even I think so
<ev> Especially given that we may be blocked on this contributor agreement issue for a few days.
<m4n1sh> can you confirm with the release team
<m4n1sh> about whether it falls with UI freeze or feature freeze
<m4n1sh> ev: even I feel it to be a UI freeze one, but if you can check out with anyone in release team, it would be great
<ev> sure
<m4n1sh> please update me once you have confirmed
<m4n1sh> ev: I have a feeling that FF applies to this because whoopsie is not enabled by default
<ev> m4n1sh: whoopsie will be enabled just as soon as I finish making the changes requested in its security review
<m4n1sh> it is in main?
<m4n1sh> MIR done?
<ev> m4n1sh: there's a MIR, which will be approved once the changes requested by the security team are made (I'm in the midst of that now)
<m4n1sh> great
<m4n1sh> excellent
<ev> once that's done, I just need to seed it and it will be running by default
<m4n1sh> :)
<ev> m4n1sh: cjwatson (of the release team) suggests it is not a feature freeze matter.
<ev> so by all means, release what you have :)
<cjwatson> not this particular part of it.
<m4n1sh> release yesterday itself
<m4n1sh> Didier uploaded it
<m4n1sh> I uploaded it yesterday since I was not sure if I could complete this one
<m4n1sh> cjwatson: thanks for clarifying
<akgraner> cjwatson, I just updated my notebook  and got a libc6 error - now I have packages with umnet dependencies  - Do I follow the  running -f instructions or do I need to do something else?
<cjwatson> akgraner: can I see the exact error messages
<cjwatson> can't give advice without that
<akgraner> cjwatson, sure one sec I'll get them to you - they are on a different machine than the one I am using for xchat.
<arand> It looks as though someone on #ubuntu+1 has a similar issue?: "can anyone help me fix broken apt? E: Internal Error, No file name for libc6"
<cjwatson> arand: well, once again, would need more details than that ...
<cjwatson> release, architecture, whether multiarch is enabled, full transcript of upgrade attempt, ...
<akgraner> cjwatson,  dropped it to you in a pm along with what I did when and the point at which I was advised to contact you.
<arand> cjwatson: "I'm on P, amd64, with multiarch" which is the upgrade log file to look for?
<arand> cjwatson: "term.log: http://paste.ubuntu.com/841833/"
<cjwatson> arand: bizarre.  'sudo dpkg --configure -a' might help
<cjwatson> Having trouble seeing why apt got the ordering wrong in the first instance there.
 * cjwatson notes that there is nearly a day's gap between the first error there and the attempt that apparently led to this report
<lamalex> cjwatson, yah definitely
<lamalex> too busy to deal with apt most of the time
<lamalex> so usually i just leave it broken until i need to fix it :P
<lamalex> cjwatson, hey that seems to have fixed it
<lamalex> that + apt-get -f install
<cjwatson> ok
<lamalex> thank you
<cjwatson> sadly hard to work back to the cause at this point
<cjwatson> next time, assuming you were using update-manager, 'ubuntu-bug update-manager' should attach a state tarball to the bug that would be enough to let us reconstruct the initial state
<lamalex> nice
<lamalex> thanks
<scott-work> does anyone have a suggestion for a particular person who might be a good candidate to review the lowlatency kernel in REVU (http://revu.ubuntuwire.com/p/linux-lowlatency)?
<scott-work> luke y has already advocated it, so we just need one more person
<tumbleweed> can I have some list-moderation on ubuntu-devel-announce please?
<cjwatson> tumbleweed: done
<tumbleweed> thanks
<dupondje> cjwatson: MoM is still broken?
<cjwatson> dupondje: it's running
<cjwatson> took a while because it had been down for a while
<dupondje> cool :)
<dupondje> mm cjwatson I note some errors in the MoM pages
<dupondje> python-drizzle for example gives 1.0-2ubuntu1 as current version
<dupondje> while 1.0-3 got uploaded weeks ago
<dupondje> same for samba4
<didrocks> apw: hey, around?
<apw> didrocks, hi
<jhunt> cjwatson: Hi - could I trouble you to bump the priority on the 2
<jhunt> builds here: https://launchpad.net/~jamesodhunt/+archive/upstart-testing ?
<didrocks> apw: I'm wonering if you know of any kernel issues which can be stated as "after a period of lot of writing on disk (even swapping maybe), the CPU usage is going crazy"
<cjwatson> jhunt: I don't see any builds there right now?
<apw> didrocks, is that continious writing?
<didrocks> apw: no, the writting ended
<didrocks> but yeah, I has some continious one
<didrocks> right now, my CPU usage is between 60% and 80% on my 2 cores, and if I look at htop, the sum of what is >1% should be at 20% max
<jhunt> cjwatson: sorry - wrong ppa. should be https://launchpad.net/~jamesodhunt/+archive/upstart-job-logging
<didrocks> seems everytime I swapped, I get this
<apw> didrocks, the only diskio and cpu usage issue i have heard of is a possible issue xfs when the cache gets full
<apw> didrocks, otherwise no i am not seeing the same herre on anything
<didrocks> seems that seb128 got something similar somethimes
<cjwatson> jhunt: done
<didrocks> apw: I have such a behavior once a day at least, which forces me to reboot, anyway I can ensre that the CPU usage comes from some kernel threads?
<jhunt> cjwatson: thanks!
<apw> didrocks, get the machine up to date, and if it is reproducible lets get a bug filed please with a good description of your reproduce by
<apw> didrocks, and include w
<stgraber> jhunt: I like that changelog!
<apw> didrocks, and include a ps -ef with the bad processes listed please
<didrocks> apw: well, I'm up to date and getting that for now some weeks :)
<apw> didrocks, yep and we had a pile of stable updates in the last kernel which was just the last day or two, so i want to make sure its not already fixed by that
<NoaHall> Any Jockey devs in here?
<didrocks> apw: ok, let me check I have the latest and greatest
<slangasek> smoser: ah; this cloud script that's looking inside disks certainly fits the bill
<pitti> apw, ogasawara: I binNEWed the new kernel, finally built on armel; can you please upload -meta?
<ogasawara> pitti: yep, will upload right now
<pitti> ogasawara: cheers!
<stgraber> slangasek: hey, I seem to remember you knowing a bit about lvm2 and udev ;) I upgraded two of my servers to Precise and noticed a "sh -c /sbin/lvm vgscan; /sbin/lvm vgchange -a y" and it's child "vgchange -a -y" apparently spawned by udev but never exitting as expected. It's not causing any problem on these machines though but looked weird.
<stgraber> slangasek: a very quick LP search gave me bug 802626 as a potential candidate for that weirdness
<slangasek> stgraber: yes, the bug is still outstanding; there's a proposed fix from hallyn that I haven't managed to find time to review yet
<hallyn> stgraber: yeah, that one's annoying isn't it :)
<stgraber> hallyn: well, in my case it's only annoying when running "ps aux" on my all new server ;) it doesn't actually prevent anything from starting or cause any other issue that I could see
<hallyn> interesting
<stgraber> I have 3 PVs and 3 VGs on that machine, 1 of them is on RAID1 and contains the root LV, the two others are currently empty (no LV at all)
<stgraber> my other server has hardware RAID (HP) but also has 3 PVs (3 RAID volumes) and 3 VGs, though in this case, they all have LVs and are all used
<micahg> barry: in case you haven't seen, sphinx has a bug fix in unstable as well as needs and MIR (or something done) for python-whoosh
<m_3> akgraner: ping
<akgraner> m_3 pong
<beuno> barry, congrats!
<broder> barry: congrats on the dmb election!
<sladen> %rfs
<barry> broder: thanks!
<apw> who owns nm-applet, the below cannot be right
<apw>  2942 apw       20   0 6815m 1.7g 3080 S    2 43.3  21:56.80 nm-applet
<micahg> bug /930491
<micahg> bug 930491
<micahg> ah, bot is awol
<seb128> apw, cyphermox
<seb128> though I guess he could try to blame it on indicators,dx
<cyphermox> apw: I'm aware of it, trying to track it down
<ScottK> barry: Is it you or doko that's supposed to do the lucid update for dh_python2?
<barry> ScottK: doko
<ScottK> Sigh.  doko: Can we get this done?  It's really causing problems.
<slangasek> smoser: would you by chance be willing to test the latest ppa upstart build, to confirm that the logging support works as intended in the various cloud configurations? https://launchpad.net/~jamesodhunt/+archive/upstart-job-logging
<smoser> slangasek, i can look tomorrow. is there a doc on what i'm supposed to see ? is it writing to /var/log/upstart.log ?
<YokoZar> slangasek: is migrating packages to multiarch something that requires a feature freeze exception or is it just a normal bug?
<slangasek> YokoZar: FFe
<slangasek> smoser: /var/log/upstart/, one logfile per job that outputs
<slangasek> smoser: http://www.theorangenotebook.com/2012/02/call-for-testing-upstart-14.html
<kklimonda> hey, I need a place to host a small file for transmission SRU - so called blocklist (a list of ip ranges that BT client does not allow connecting to and rejects connections from)
<broder> kklimonda: what does modern transmission use if the project isn't hosting the file anymore?
<broder> (and can the sru switch to doing that instead)
<kklimonda> broder: they have changed UI providing a way to set custom url instead
<apw> cyphermox, may also explain didrocks symptoms
<broder> kklimonda: is there a default?
<kklimonda> broder: no, it's set to example.com
<kklimonda> or something like that
<apw> cyphermox, mine is growing slowly but surely too:
<apw>  2942 apw       20   0 7165m 1.7g 3116 S    2 45.6  23:09.04 nm-applet
<broder> kklimonda: it sounds like it's not actually mandatory anymore. can we just disable the blocklist?
<kklimonda> broder: but blocklists just don't work in 10.04
<kklimonda> broder: there is no "initial" list so there is no way to use this feature anymore :)
<kklimonda> (it has never been mandatory, but it's a very popular feature of BT clients and we got some reports of it not working)
<broder> i see
<infinity> kklimonda: I'm not sure why we'd need to host a file?  There doesn't need to be a default blocklist (and, in fact, there isn't...)
<kklimonda> infinity: but in 10.04 there is no way to change the blocklist url
<kklimonda> infinity: it's hardcoded to http://update.transmissionbt.com/level1 in code, and the url is gone :)
<infinity> kklimonda: Which is unfortunate, but "oh well"?
<infinity> kklimonda: If you know what was in that file, you could just ship a copy with the package on-disk, and point to that.
<kklimonda> infinity: hmm, that may work
<infinity> kklimonda: But, really, there will be a new LTS in a couple of months, and it seems remarkably unlikely that the intersection of "people who torrent", "people who care about blocklists" and "people who run old releases" is very large.
<kklimonda> infinity: yeah, it's still a bug though and us not fixing it for package in main sucks a little
<YokoZar> slangasek: cjwatson: I just read https://bugs.launchpad.net/ubuntu/+source/libidl/+bug/931388  and it's worrying me because I used depends: wine1.4:any in the new wine1.4 packages as part of multiarching.  Will I need to do the dummy-package-with arch:all workaround?
<ubottu> Launchpad bug 931388 in libidl (Ubuntu) "overenthusiastic adoption of "Depends: cpp:any" syntax" [High,Triaged]
<YokoZar> (relatedly, wine1.4 is still half in the queue because wine1.2 and wine1.3 aren't yet deleted from the archive)
<slangasek> YokoZar: I don't know what workaround you're proposing, but you aren't meant to be using :any yet in depends
<YokoZar> slangasek: the workaround is at the bottom of this page: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=641614
<ubottu> Debian bug 641614 in libidl "please convert to multiarch" [Normal,Open]
<slangasek> YokoZar: ah; ugly, but yes, that would do it
<cjwatson> YokoZar,slangasek: as I said in the Debian bug, I haven't tested that workaround yet, and it's mostly instinct
<cjwatson> YokoZar,slangasek: if that approach works, I think it might be worth documenting in MultiarchSpec for the time being; I forgot this problem myself when talking to TREllis about the libidl implementation
<slangasek> yeah, I've only eyeballed it; I don't see any reason it wouldn't work
<YokoZar> cjwatson: is the wine upgrade case different from the libidl case as wine already requires a new packagename?
<cjwatson> YokoZar: that doesn't make any difference
<YokoZar> cjwatson: slangasek: regardless, I'll have to test it anyway.
<cjwatson> YokoZar: it's still entirely possible that lucid's apt will be called upon to parse it
<cjwatson> or for that matter germinate
<YokoZar> cjwatson: Are you implying Wine will be pulled in by germinate :D
<cjwatson> I think it is dangerous to take approaches that are known to fail
<hallyn> d'oh!  for the life of me i can't figure out why sometimes bzr seems bound when it shouldn't be
<hallyn> (oh well, that forced me to not pussyfoot around for another month fearing to commit :)
<superm1> TheMuso`: is the current plan alsa 1.0.25 for precise or sticking with 1.0.24?  wasn't really clear to me from blueprints
#ubuntu-devel 2012-02-15
<cfhowlett> _Marcus: Devices - Install Guest Additions.
<kklimonda> hey - I have a package dogtag-pki-common-theme with Provides: pki-common-theme and another package pki-common which depends on pki-common-theme
<kklimonda> I can't install pki-common as it complains about pki-common-theme missing
<kklimonda> is there a good read about using Provides with Depends?
<kenalex> hello
<kenalex> which ubuntu version is best for software development 10.04 or 11.10
<RAOF> kenalex: That's not really something that we can answer for you; it depends on your target.
<kklimonda> ah, hmm - it seems you can have versioned dependency on a virtual package (which makes sense if you think about it)
<RAOF> kklimonda: You mean you *can't* have a versioned dependency on a virtual package, right?
<RAOF> And, indeed, if you think about it it makes sense :)
<kklimonda> RAOF: yes, right :)
<maxb_> Does it make sense?
<maxb> It's always struck me as being an implementation shortcoming, but one sufficiently minor that it's no-one's priority to fix
<RAOF> Well, you could make it make sense by also versioning the Provides
<RAOF> ie: Provides: foo-service (2.0) or something.
<RAOF> But if you're doing that you might as well just Provides: foo-service-2.0 and be done with it.
<broder> maxb: what does it mean to Depend: mail-transport-agent (>= 2.3)?
<maxb> Nothing, but what about Depends: java-runtime (>= 5)
<cjwatson> BenC had a go at fixing it years ago (before Ubuntu) but it never made it into production
<TheMuso`> superm1: 1.0.25, assuming the rest of the stack checks out ok with testing, i.e no critical showstoppers.
<cjwatson> There may even still be patches lying around but I doubt they apply to modern apt :-)
<cjwatson> I think his design was that packages could choose to e.g. "Provides: java-runtime (= 5)"
<RAOF> I'm not sure even that really works, because there's no guarantee that java-runtime (= 8) necessarily supports java-runtime (= 5).
<broder> i assume it wouldn't, right?
<broder> you'd have to do provides: java-runtime (= 5), java-runtime (= 8)
<RAOF> ie: if we packaged a JRE with deprecated stuff dropped, and split out a jre-5-compat type package.
<cjwatson> If you have that class of problem then you could change the name of the virtual package
<cjwatson> Don't need to solve every problem with the same hammer
<cjwatson> (But, yes, we seem to have adequate fallbacks for this one already)
<RAOF> I'm not sure what problem is solved by java-runtime (= 5) that isn't solved by java-runtime-5.0
<RAOF> Actually, no, I do know.  When you're providing virtual library packages.
<RAOF> So you've got something that currently depends on libfoo3 (>= 2.3.3) and you want to turn libfoo3 into a virtual package provided by libbar2.
<maxb> Right - again, the workarounds are not exactly hard, but it could be useful to be able to provide a versioned virtual package
<slangasek> stgraber: I'm wondering if it's a mistake for ifupdown to stop running hook scripts at the first non-zero exit
<slangasek> stgraber: cf. bug #932485
<ubottu> Launchpad bug 932485 in firestarter (Ubuntu) "Firestarter breaks networking during bootup" [High,Triaged] https://launchpad.net/bugs/932485
<YokoZar> slangasek: can I use depends foo:any for packages which only exist in Oneiric and later?
<slangasek> YokoZar: as cjwatson said, there are other reasons the lucid tools might have to be able to parse these
<YokoZar> slangasek: How about for a myapps or ARB package?
<YokoZar> (specifically, I want depends: unionfs-fuse:any)
<slangasek> YokoZar: er, not my department; I don't know what the constraints are on packages there
<YokoZar> presumably they aren't going to ever encounter a Lucid tool though
<slangasek> I can't think of any reason specifically that a myapps/ARB package, if distributed for precise, would cause problems with :any
<YokoZar> Yeah me neither
<YokoZar> Thanks :)
<stgraber> slangasek: It was definitely meant as a bugfix for http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=547587
<ubottu> Debian bug 547587 in ifupdown "ifupdown: ifup and ifdown don't abort on a run-parts error" [Normal,Fixed]
<stgraber> slangasek: though I agree it'd probably be safer to re-introduce the "bug" for 12.04
<stgraber> slangasek: and let Debian deal with the problems for a bit then maybe switch it back in 12.10
<stgraber> slangasek: (apparently we'll get a beta3 or rc pretty soon which will hit unstable and I'll merge into Ubuntu)
<stgraber> slangasek: Ubuntu is currently the only distro with --exit-on-error in that run-parts, so we're obviously the first to notice the issues
<slangasek> stgraber: how do you mean, the only distro?  is there an Ubuntu-specific patch turning on --exit-on-error?
<stgraber> slangasek: no, but currently only Ubuntu ships the new ifupdown (0.7), in Debian it's limited to experimental, the rest is still on 0.6
<slangasek> ah, right
 * micahg thought that Multiarch: foreign precluded the need for Depends: foo:any
<cjwatson> Yep, unionfs-fuse could just have Multi-Arch: foreign (it doesn't right now) and then this wouldn't be an issue
<micahg> YokoZar: ^^
<cjwatson> :any is only relevant for M-A: allowed, that is, things where some dependents might require the same architecture but others will be happy with any architecture
<slangasek> oh, unionfs-fuse isn't M-A: allowed?
<slangasek> in that case, :any isn't legal
<cjwatson> It's not and I can't think why it'd ever need to be
<YokoZar> cjwatson: is it really proper to install unionfs-fuse:i386 on an amd64 system?
<slangasek> and :any won't work
<YokoZar> err
<YokoZar> nm
<YokoZar> foreign
<stgraber> slangasek: I'll mention to Andrew on IRC and will decide whether to revert the change or not tomorrow after I talk a bit with him
<cjwatson> YokoZar: If you use M-A: foreign, then you'll get unionfs-fuse:amd64, not unionfs-fuse:i386
<slangasek> stgraber: ok
<cjwatson> YokoZar: although in any case I don't see why it would matter
<cjwatson> by definition if you have an architecture enabled using multiarch then you can execute its binaries
<YokoZar> cjwatson: Yeah foreign is the right way to do it, I can't think of a reason a package would have an arch-specific dependency on unionfs-fuse
<superm1> TheMuso`: i was informed that there are some problems with 1.0.25 and nvidia audio chipsets.  specifically with mplayer and mythtv users.  there's fixes in master but not in 1.0.25, so if you do decide to do 1.0.25 I hope you can also backport those other fixes
<TheMuso`> superm1: In master of alsa-lib?
<TheMuso`> superm1: Because since 1.0.25, I don't see anything in alsa-lib that is to do with anything NVIDIA.
<superm1> TheMuso: this is the thread i was pointed at: http://mailman.alsa-project.org/pipermail/alsa-devel/2012-February/049061.html  Here's some more of the context of the discussion about how it's broke: http://paste.ubuntu.com/842632/
<superm1> the exact patches that fixed it weren't linked in the thread, but takashi indicates at the end that it's fixed in master
<superm1> "The problem of Nvidia HDMI and the buffer-alignment was already fixed in the upstream code"
<superm1> i'll see if jya was able to track down what patches actually did that, but if not, i'm sure takashi can help point at them too
<pitti> Good morning
<TheMuso> superm1: Sounds like kernel, and thats not really my area, but thanks.
<superm1> TheMuso: ah.  well when you're ready to do 1.0.25, are you going to stage on a PPA and call for testing and such?
<TheMuso> superm1: Well the kernel alsa version tends to follow a different process in terms of when it gets updated.
<superm1> oh
<TheMuso> superm1: alsa-lib 1.0.25 was in last week, since I accidentally jumped the gun with that one without calling for testing, however everything else alsa is in the Ubuntu Audio Dev PPA, and the community team put a call out for testing late last week to.
<TheMuso> But kernel 3.2 has a version of 1.0.24, however this is not often always correct, as 1.0.25 commits make their way in, especially if they enable hardware.
<TheMuso> SO kernel wise, the version is not that good a guide.
<superm1> TheMuso: ah i see.  i'll talk it over some more with jya then.  he's got a hand full of hardware so he can hopefully test with what's in precise right now and the other alsa bits in the audio dev PPA
<TheMuso> Ok.
<TheMuso> superm1: TO be clear, we do not use the kernel code found in the alsa-driver package, our alsa kernel code comes from the kernel.
<superm1> TheMuso: right so as this problem seems to be caused by a commit to alsa-driver, it will eventually find it's way into the kernel, but probably at a slower rate
<TheMuso> superm1: Right, or the fixes may already be in 3.2. If they aren't, we can cherry pick them.
<superm1> yeah, really need to identify those commits and figure out where they are right now
<TheMuso> Alsa kernel code is developed agains the kernel first, then alsa-driver packaging/development is done second.
<TheMuso> against
<superm1> TheMuso: okay so crisis averted.  turns out the patch that causes problems for nvidia and the solution for the regression both landed in 3.2, so no worries.  thanks for the help
<cfhowlett> Will the AWN dock make be seen in 12.04?
<TheMuso> superm1: np.
<pitti> superm1: mythbuntu-desktop depends on the NBS mythvideo; can this be dropped?
<superm1> pitti: yes, but i was waiting to make the change until mythtv got out of NEW
<pitti> hm, I just NEWed it an hour ago or so
<superm1> oh, well then i might be behind the times :)
<pitti> superm1: ah, still needsbuild on armel/powerpc, will it be NEW there, too?
<pitti> (the binNEW from this morning was arch:all, the php-* one)
<superm1> there was the php-* one and libmyth-0.25-0.  i'm not sure if that was already cleared on armel or powerpc yet though
<superm1> php-* one was i386 only
<superm1> i still see them both (i386 and amd64) listed in https://launchpad.net/ubuntu/precise/+queue?queue_state=0&queue_text=mythtv is that because publisher run not done yet?
<pitti> superm1: oh, I think that's the previous upload
<pitti> I just NEWed the recent one
 * pitti cleans those up, too
<superm1> oh i see
<pitti> (done)
<superm1> thanks!  i'll get the meta fixed up to take *video out
<pitti> cheers
<broder> could somebody on ubuntu-branches mark https://code.launchpad.net/~jtaylor/ubuntu/oneiric/distribute/fix-910965/+merge/87303 as merged to get it off the sponsorship queue? (it should show up in UNAPPROVED momentarily)
<pitti> broder: done
<broder> (or jtaylor, you could do it, if you're around)
<broder> pitti: thanks :)
<apw> didrocks, i don't know if you saw the discussion on nm-applet eating peoples machines, dunno if that could be the cause of your slowness, cirtainly it makes my machine feel that way and leave kswapd running a lot as well
<didrocks> apw: ah interested, maybe that can be related yeah
<didrocks> apw: didn't see the discussion though, where was it?
<apw> mostly here about 12 hours back, and a bug ... erm
<didrocks> apw: I'll look at my IRC logs then, thanks for the notice :)
<apw> https://bugs.launchpad.net/ubuntu/+source/network-manager-applet/+bug/930491
<ubottu> Launchpad bug 930491 in network-manager-applet (Ubuntu) "Large memory leak in nm-applet" [High,Confirmed]
<apw> didrocks, ^^
<didrocks> apw: looking
<apw> i noticed cause my machine felt like treacle, and was swapping
<didrocks> apw: I didn't notice it in htop, but I'll watch after it, thanks!
<didrocks> is cyphermox aware?
<apw> didrocks, yeah he is
<didrocks> ok, nice :)
<didrocks> I'll try to kill nm-applet
<didrocks> and see if I still get it after a few hours of use
<apw> didrocks, yeah its not running a lot, it just leaks an amount proportional to the number of wifi access points
<apw> ps lax | grep nm-applet
<apw> didrocks, ^^ was showing me 1.7g resident
<didrocks> apw: well, I'm "only" at 100Mb res, which is quite high for such a software
<didrocks> after 2h45
<apw> didrocks, and mine got that far cause the machine in question has 4G of ram, so it started to really hurt
<didrocks> yeah, definitively needed to be fixedâ¦
<micahg> hi mvo, are you planning on merging aptitude 0.6.5 before feature freeze?
<mvo> micahg: no, sorry, I don't think I will have time for this
<micahg> mvo: would you mind if I did it?
<mvo> micahg: not at all, thanks a bunch!
<pitti> apw, ppisati: I binNEWed the new linux-ti-omap4, doing a d-i rebuild now; can you please update linux-meta-ti-omap4 ?
<apw> pitti, ack
<bkerensa> dholbach: Are you about?
<dholbach> bkerensa, yep
<bkerensa> dholbach: I'm working on https://bugs.launchpad.net/ubuntu/+source/linux/+bug/593107
<ubottu> Launchpad bug 593107 in linux (Ubuntu) "Package description for linux-tools-* needs improvement" [Medium,In progress]
<dholbach> ah, best have a chat with the guys in #ubuntu-kernel
<bkerensa> and was wondering if you might have some feedback on a better description to bring it up
<bkerensa> dholbach: Oh those guys eh? :P
<dholbach> yep :)
<infinity> Note that linux-tools-* are generated from the kernel sources, and they'll be very miffed if you modify those packages. ;)
<infinity> But pushing them patches to put in git will make them quite happe.
<infinity> happy, too.
<bkerensa> infinity: Indeed... I'm just trying to get feedback on a better description to match debian policy on descs
<bkerensa> Right now the description is pretty vague
<bkerensa> and the only tool I have used is perf
<infinity> bkerensa: Describing what tools are included, or at least what you might want to use them for, would be a good start.
<bkerensa> infinity: The problem is I cannot find a list of all the included tools so I cannot create a good description the summarize them all
<infinity> bkerensa: If you have it installed, "dpkg -L <packagname>" will show you what's included.
<infinity> bkerensa: One would assume all the interesting bits are in {,/usr}/{,s}bin/
<bkerensa> k
<bkerensa> infinity: Hmm http://paste.ubuntu.com/842872/
<bkerensa> :)
<bkerensa> I also have source which only includes a debian folder
<infinity> bkerensa: The versioned package has the tools.
<bkerensa> ahh
<infinity> bkerensa: linux-tools-$(uname -r)
<ppisati> pitti: when you have time, could you pubblish the new omap4 kernels? thanks
<ppisati> *publish
<infinity> ppisati: They're through NEW already.
<infinity> ppisati: Nothing more for pitti to do.
<ppisati> nice
<pitti> ppisati: yep, did half an hour ago; was eagle-eying this to get NBS down
<infinity> pitti: Heh, I'd been waiting up to do it, and I turned away from my computer for a few minutes and you beat me to it. :P
<ppisati> cool, just hit the archive
<hrw> does someone know what is wrong with login.ubuntu.com?
<bkerensa> hrw: What do you mean?
<hrw> bkerensa: unable to authorize tomboy to use ubuntuone
<hrw> (Identyfikator bÅÄdu: 2237canistelubuntu1110)
<bkerensa> Hmm
<bkerensa> odd
<bkerensa> Didn't they end tomboy support for Ubuntu One?
<Laney> no
<hrw> bkerensa: u1 does not display notes on website
<hrw> bkerensa: tomboy still may store them on u1
<bkerensa> ahh
<bkerensa> dholbach: Got a patch submitted to those Kernel folks :)
<dholbach> yoohooo!
<barry> quick versioning question: fgfs-atlas 0.3.1-2 is in the archive.  i have to build it from cvs to fix the nbs, so i'm going to upload 0.3.1+cvs20120214-0ubuntu1.  does that seem reasonable?
<pgraner> anyone have an idea on why today's updates would want to remove skype?
<pitti> pgraner: libaudio i386/amd64 buildd desync
<pitti> err, libasound I mean
<pitti> oh, https://launchpad.net/ubuntu/+source/alsa-lib/1.0.25-1ubuntu4/+build/3213632
<pitti> FTBFS on i386
<pitti> pgraner: so don't say yes for now
<pgraner> pitti, ok, should that have shown up on http://people.canonical.com/~ubuntu-archive/testing/precise_probs.html  ?
 * pgraner is not sure how that gets generated
<pitti> pgraner: we don't test multi-arch to that level yet
<pitti> i. e. it doesn't notice if a libfoo is on a different version between architectures
<pgraner> pitti, ah ok, good to know
<cjwatson> alsa-lib needs to be built on a 64-bit-capable buildd :-/
<cjwatson> stick it on roseapple, and cry a bit inside
 * cjwatson goes to do that
<cjwatson> (this'll get fixed next time we merge from Debian, since they're dropping the lib64* bits)
<cjwatson> oh, bleh, roseapple is on amd64 duty right now
<cjwatson> I'll grab it back once it's done with firefox
<infinity> cjwatson: Err, what?
<cjwatson> notice how all its successful builds of late have been on roseapple ...
<infinity> Yeah, no.  I see the issue.
<infinity> I'm questioning the solution. :P
<cjwatson> and the error is "cannot run C compiled programs" on the -m64 pass
<infinity> Can we not just turn that insanity off?
<cjwatson> like I say, that's what the next merge from Debian will do
<cjwatson> I'm just not prepared to take responsibility for that :)
<infinity> Doesn't look like the worst merge ever.  But yeah, it's 5am for me too, I guess I'll pass on being a hero right now.
<GunnarHj> cjwatson: Hi Colin, any chance that you can give bug 926207 some attention? Just talked to pitti about it, and we concluded that it's important that the bug gets fixed before the 12.04 release.
<ubottu> Launchpad bug 926207 in ubiquity (Ubuntu) "Set formats related LC_* variables when applicable instead of LC_MESSAGES, LC_CTYPE and LC_COLLATE" [Undecided,New] https://launchpad.net/bugs/926207
<cjwatson> not today but I'll load it up
<cjwatson> for future reference please don't create tasks on multiple installer components if you aren't an installer developer
<cjwatson> one will do :)
<GunnarHj> cjwatson: Aha, sorry, just tried to be helpful...
<GunnarHj> cjwatson: Anyway, thanks in advance for dealing with it.
<ochosi> mvo: hey, i have a question wrt software-center. it currently shows the package "exo-utils" as "Email Reader" and "Web Browser" which is highly misleading. i guess that information comes from the desktop-file, is there anything we/you can do about that?
<mdeslaur> @pilot in
<mdeslaur> @pilot in
<mdeslaur> @pilot in
 * mdeslaur kicks bot
<mdeslaur> @pilot in
<mdeslaur> dholbach: ^ bot's busted
<dholbach> AlanBell, ^ do you know what we can do about it?
<mvo> ochosi: yes, you can set "X-AppInstall-Ignore=true" in the desktop files
<mvo> ochosi: or I can blacklist them in my extraction code
<ochosi> mvo: what is the more common approach?
<ochosi> mvo: in fact our packager (mr_pouit) just tells me that exo doesn't have any delta with debian atm and it'd be great if you could blacklist it
<ochosi> mvo: i meant debian _and_ upstream :)
<cjwatson> ochosi: exo has a delta
<cjwatson> ochosi: albeit not one that matters for this purpose
<ochosi> mr_pouit: ^ :)
<cjwatson> i.e. https://launchpad.net/ubuntu/+source/exo/0.6.2-3ubuntu1
<mvo> ochosi: having it in the package is easier for me but either way is fine
<ochosi> mvo: ok, well i think in fact it's mr_pouit's call, i just noticed because one of "my users" uninstalled exo-utils by mistake and it wasn't very pleasant to fix remotely :)
* infinity changed the topic of #ubuntu-devel to: Alpha 2 released!  Archive: open | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #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: mdeslaur
<infinity> mdeslaur: Bots aren't entirely necessary. :P
<mr_pouit> ok, then I guess I'll do it in the packages then
<mdeslaur> infinity: I'm terrified of dholbach thinking I skipped my patch piloting duty :)
<mr_pouit> all items from xfce4-settings appear in software-center too, and it's just confusing
 * dholbach hugs mdeslaur
<mdeslaur> hehe
 * mdeslaur hugs dholbach
<mvo> thanks mr_pouit - about xfce4-settings should I blacklist a package (i.e. is it all just in a single pkg?)
<mr_pouit> cjwatson: I know, but you forwarded it to debian so there won't be any delta with the next upload, hopefully
<ochosi> hm, if i'm not mistaken exo-utils is also single package but several desktop-files...
<mr_pouit> mvo: packages can also ship desktop files to appear in xfce4-settings, so blacklisting won't do (e.g. orage ships xfce-xfcalendar-settings.desktop, which appears in software-center because of that ;-)
<mvo> mr_pouit: is there a straightforward way to detect them? I guess I should just download the examples
<mvo> mr_pouit: so if X-XfceSeettingsName is there I guess it does not make sense in software-center, is that correct?
<pitti> SpamapS: wow @ https://launchpad.net/ubuntu/+source/mysql-5.5/5.5.20-0ubuntu1
<AlanBell> jussi: is the patchpilot bot running?
<pitti> SpamapS: that's the first-ever package that I saw that succeeded on all ports but failed on i386 and amd64 :)
<mr_pouit> mvo: mmh, I think you can exclude a desktop file when there's X-XfceSettingsDialog in the category (X-XfceSettingsName is only used by orage)
<infinity> SpamapS: \o/ on mysql using gcc-4.6!
<infinity> cjwatson: Have you put any time/thought into grub2 and gcc-4.6?  Looks like with the last mysql upload, only the bootloaders (grub2 and u-boot-linaro) are keeping gcc-4.5 in main.
<geser> pitti: no wonder as the test suite may only fail on amd64 and i386 (the other archs have "|| true" after the make test-force)
<cjwatson> infinity: some, but I've been having build problems
<cjwatson> infinity: I was planning to get back to it after FF
<hrw> "The PPD version (5.2.7) is not compatible with Gutenprint 5.2.8-pre1."
<hrw> = no way to print under precise
<hrw> be back in ~1h to discuss
<apw> cyphermox, i note i am getting the error below constantly from a version of nm-applet running in a terminal:
<apw> LIBDBUSMENU-GLIB-WARNING **: Trying to remove a child that doesn't believe we're it's parent.
<cyphermox> yes, I'll be fixing that with ted today
<cyphermox> this is because the same menu is used for the GtkStatusIcon applet as for the appindicator, and the way it's built
<apw> cyphermox, and thats the source of the leak?
<cyphermox> not afaik
<apw> bah, so no progress on that ?
<cyphermox> yes, getting there
<apw> cool
<apw> am i right in thinking that the control file in a source package, only the top source section is actually used ?
<geser> used for what?
<infinity> apw: No.
<infinity> apw: The entire control file is used to determine the Binary: and Architecture: lines in the .dsc
<infinity> apw: Which can do entertainingly haywire with auto-generated control files.
<infinity> s/do/go/
<apw> infinity, how does that work with udebs which don't appear there
<infinity> I think you sort of answered your own question.
<infinity> They don't appear there. ;)
<infinity> Though, they should still be counted in the Arch: line.
<apw> infinity, so them not being in the binary: line is or isn't a problem overall
<infinity> apw: For consistency sake (and tools that rely on Binary being correct), it's a potential issue.
<infinity> apw: In the real world, I think we've learned to live with .dsc being incorrect.
<apw> infinity, and am i right in saying that the only bit that it cares about is the Package: lines then, the rest of the binary area is ignroed
<infinity> apw: Package and Arch are the two binary lines that matter to source packages.
 * apw is trying to work out if the textual description being inaccurate in the source package is a problem or not
<infinity> apw: (Arch being important because it bubbles up to the dsc, and it's how we determine where to build the source)
<apw> infinity, ok great, thats what i hoped
<infinity> apw: Descriptions don't matter, no.
<Beret> kirkland, Ctrl-a in byobu broken?
<kirkland> Beret: hmm, it should be fixed in byobu 5.10
<kirkland> Beret: what version are you running?
<kirkland> Beret: byobu -v
<Beret> ah
<Beret> ok
<Beret> 5.9
<kirkland> Beret: yeah, upgrade to the latest and it's fixed;  yes, it was broken for a day or two
<scott-work> can anyone suggestion a person that is pokeable to review the lowlatency kernel in REVU?  http://revu.ubuntuwire.com/p/linux-lowlatency
<Beret> kirkland, no worries, thanks
<scott-work> we have one advocate already but need another (before tomorrow i believe)
<cjwatson> apw: the kernel is definitely anomalous here; I can't think of any other package that builds things not declared in its .dsc
<cjwatson> apw: ideally, the kernel's debian/control as uploaded would contain stanzas for the union of all the binary packages it might build on any architecture
<cjwatson> that's what everything else does :)
<apw> cjwatson, yeah the kernel wedge output is most unhelpful
<cjwatson> there's nothing wrong with the kernel-wedge output - you're using it wrong ;)
<apw> cjwatson, heh is there a unioner ?
<infinity> scott-work: Is it heavily patched, or just the Ubuntu source with some config tweaks?
<cjwatson> worst case you could run it on clean with DEB_HOST_ARCH set to each of the architectures you support, or something like that ...
<infinity> scott-work: The latter would be simple to review, but one could also make an argument for just generating it from the original source.
<cjwatson> and cat the whole lot onto control
<cjwatson> although I suppose I don't know if having two stanzas for the same package name which differ only in architecture would cause a problem - I guess in that case you would need something to produce the union, yes
<cjwatson> though, I thought this was exactly what 'kernel-wedge gen-control' was for
<cjwatson> hm, maybe not, can't quite remember
<cjwatson> I'd be surprised if the Debian kernel people hadn't solved this recently, since they just started building udebs out of their kernel source
<infinity> scott-work: Also, if it's based on the Ubuntu packaging, it should use the 3.2.0.orig.tar.gz instead of being packaged natively.
<infinity> scott-work: Yeah, okay, looking at this, it looks like it's literally just config changes, and an accidental change in arch/arm (which is entertaining, since it only builds for x86)
<infinity> apw: Is there a reason we can't take this lowlatency config and roll it from the linux source package?  Is it just that the i386 build times are already unforgivably high?
<infinity> Oh, wait.  I see a patch here, nevermind.
<infinity> ... a 7-line patch.
<apw> yick
<apw> it was supposed to be config only, but yes separation is about the build times being mental already
<apw> infinity, is there a package somewhere for that i can look at
<apw> infinity, i want to make sure its not going to make a linux-libc-dev etc
<scott-work> infinity: it is the same source as the -generic kernel but with some compile flags tweaked
<infinity> scott-work: And a small patch.
<infinity> apw: http://lucifer.0c3.net/~adconrad/made-kernel-irq-threaded-by-default.patch <-- The patch.
<scott-work> infinity: i wonder if TheMuso added the patch, i was unware of it before
<infinity> apw: http://revu.ubuntuwire.com/p/linux-lowlatency <-- The package.
<scott-work> but admitedly my knowledge of kernels is rather limited
<infinity> The patch seems like it could be skipped entirely by instead shipping a grub config snippet or something?
<apw> infinity, ick, just to save having a grub config ?
<infinity> apw: Jinx.
<apw> *mumble* *mumble*
<infinity> I could see extending the patch to it actually has a Kconfig option.
<infinity> Then it might be upstreamable.
<infinity> Or at least could be committed to the Ubuntu tree.
<infinity> s/to it/so it/
<apw> yep
<apw> bah here are the actual packages from this silly tool
<infinity> apw: The source is there.  It doesn't have binaries.
<infinity> apw: The source is cleverly hidden under the heading "Files", in light grey text that I can't read.
<apw> oh dammit, why do people insist on making their web pages 'cool' by changing the standard understandable markup of a damn link having _____ under it ... ARRRG
<apw> hate hate hate
<apw> especially as there are other links which are marked up ... sigh
 * apw watches dpkg locking trip over itself
<infinity> apw: My other obvious complaint would be that it should be a diff.gz against your 3.2.0.orig, rather than being a massive 100MB native package.
<apw> cjwatson, somethign has changed in dpkg locking, i beleive the regular apt-daemon update is managing to get in between files in a dist-upgrade and disrupt it
<dpm> thanks stgraber for the he.po change in pastebinit :)
<apw> infinity, yeah it should be that no doubt
<cjwatson> apw: er, dunno guv
<stgraber> dpm: np
 * cjwatson is neck-deep in writing ubiquity tests
<apw> who is apt/dpkg god so i a can whine
<infinity> apw: There's a req open for that position. :P
<infinity> apw: (Not the answer you were hoping for?)
<cjwatson> well, there will be.  eventually
<cjwatson> in the meantime we bug mvo and hope he's around
<infinity> dpkg locking is pretty primitive, mind you.  I'm curious how it could break as described.
<apw> mvo, i suspect we have a lockig issue with apt, i have just had my second apt-get dist-ugrade die due to a conflicting lock
<infinity> Unless something's decided it knows better and is actually stomping the locks.
<apw> infinity, i manage to trigger it myself previously by doing an apt-get update in the background
<apw> which it let me do, and broke the dist-upgrade badly
 * infinity raises his brow.
<infinity> Cute.
<cjwatson> that's really not supposed to happen; it should refuse
<apw> i know, that why i think the locking is broke
<cjwatson> you're not running this on overlayfs? ;-)
<infinity> Is overlayfs anywhere near this? :P
<infinity> cjwatson: Jinx.
<apw> i'll file a bug with this log, as this one i didnt do the conflicting command myself, i assume it was apt-daemon
<apw> cjwatson, infinity, no thankfully, this is a real install
<mvo> apw: what is the bugnumber?
<infinity> mvo: I think the above was him verbally filing it.
<apw> mvo, working on it
<apw> launchpad is involved
<cjwatson> For me: (1) if another apt-get update is running, then apt-get update fails with "Could not get lock /var/lib/apt/lists/lock"; (2) if apt-get dist-upgrade is running, then apt-get update updates the list files then fails with "Could not get lock /var/lib/dpkg/lock"
<cjwatson> It doesn't seem to break the upgrade in either case, although I suppose you could argue that updating the apt lists with another apt process in flight is ambitious
 * cjwatson files a bug report for infinity consisting only of pictures
<infinity> Shouldn't do any harm, since the apt-in-progress doesn't need to read the lists.
<infinity> cjwatson: Do you remember the scan of the printout of the xorg.conf?
<apw> cjwatson, well the intersting thing is we are at the beginning of a phase in the dist-upgrade
<infinity> Best.  Bug attachment.  Ever.
<scott-work> apw: infinity:  is there a resolution on what direction the lowlatency kernel should take?
<infinity> scott-work: I think apw was going to give it a quick eyeball.
<apw> cjwatson, and it fails trying to take the lock, which implies it thinks it doesn't have the lock and needs it
<apw> scott-work, yeah waiting on the download now
<infinity> scott-work: Under the assumption that it can't be in the primary sources (and it can't, for now), my only immediate complaint is that it desperately needs to be re-packed to be non-native, using the same orig as the regular kernel.
<infinity> scott-work: But that can be done when it's re-based to 16.25 and uploaded to the archive.
<infinity> Perhaps I'll comment.
<bdmurray> dobey: could you look at my lptools merge proposal?
<dobey> sure
<apw> mvo, bug #932822
<ubottu> Launchpad bug 932822 in apt (Ubuntu) "apt-get dist-upgrade failed with: dpkg: error: dpkg status database is locked by another process" [Undecided,New] https://launchpad.net/bugs/932822
<infinity> apw: Having it fail before the dist-upgrade actually takes the lock isn't really a failure...
<infinity> apw: Unless you're expecting apt to lock earlier to avoid annoying you.
<apw> infinity, bah you are right, thats between the download and application, i had seen it further forward in my mind
<infinity> apw: Although, that terminal log is weird.  I'd expect it to take the lock before the pre-config.
<scott-work> apw: infinity:  thank you x10^e :)
 * apw is confused now
<apw> mvo, i am not sure if i expect this to work or not, so if its 'thats expected behaviour' do invalid it as you see fit
<apw> as it does seem to be the first phase that fails here, though as infinity says i might have expected the error earlier
 * infinity is tempted to do a drive-by bot update on apw's bug to point out that he's not running the current kernel.
<apw> infinity, you have quite an evil streak
<infinity> Lil' bit.
<infinity> I haven't slept for a while...
 * Daviey guesses infinity has been burned.
<apw> ICE default IO error handler doing an exit(), pid = 17261, errno = 4
<cjwatson> infinity: vaguely :)
 * apw assumes gnome-session core-dumping would account for his being logged out
<cjwatson> infinity: In a previous job, instead of sending us configuration files, somebody sent us a zip file containing screenshots of the web admin interface with the bits they thought we might find interesting circled using a paint program
<SpamapS> pitti: lol.. mysql is innovative!
<infinity> cjwatson: Sure, but that kinda makes sense, if the admin UI is how they interact with settings.
<jamespage> does anyone have a nice way to calculate rebuild order for library transitions?  I want to run a test rebuild to evaluate openmpi 1.5 and not make it to hard...
<infinity> cjwatson: On the other hand, finding /etc/X11/xorg.conf in gedit, printing it, scanning it, and attacting the image just blows my mind when you could have attached the text file...
<infinity> s/attacting/attaching/
<SpamapS> Hm.. unity-2d seems to have lost the ability to maximize windows via keyboard
<infinity> SpamapS: More to the point, the reason mysql fails on x86 and nowhere else is because it should fail everywhere (testsuite is shorted with || true on !x86)
<SpamapS> infinity: totally t3h awesome
<SpamapS> I wonder why it didn't fail on my local build test
<infinity> SpamapS: Dunno.  But maybe you've jumped the gun on assuming they actually fixed the gcc-4.6 issues. :(
<infinity> SpamapS: (I'm hoping it's something simpler and more obvious when you poke at it, though)
<SpamapS> infinity: no, I think I included an errant patch to try and not statically link the client
<infinity> I'll be so excited that we get to kick out gcc-4.5 just in time to switch to gcc-4.7
<SpamapS> hm no...
<SpamapS> passed on retry.... weird
<SpamapS> wait, the fails were different on i386 and amd64
<SpamapS> oh my..
<SpamapS> the test suite was.. ridiculously bad on armhf
<apw> infinity, ok this package is sounding rather wonky, rtg is spinning an equivalent of it they way we do 'em for comaprison
<mvo> mr_pouit: I updated the extraction code now to ignore X-XfceSettingsDialog category packages
<infinity> apw: Thanks.  If the kernel team comes up with something you put a stamp of approval on and uploads it, I'll be happy to review it in NEW instead of making them go through another REVU cycle.
<infinity> apw: And if any of you have some spare cycles to turn their patch into something with a Kconfig option, so they can stop carrying a source delta, that would be awesome.
<apw> infinity, i think rtg will communicate with allessio on it
<infinity> apw: Lovely.
<mvo> apw: thanks! I'm a bit flooded in $stuff right now, but that looks like a bug
<apw> mvo, i know how you feel, its that drowing in bugs time of the cycle, i've been logged out by two today already, which is no help productivity wise
<cnd> slangasek, when I build a library against libx11-dev, it's not finding the XOpenDisplay and XCloseDisplay symbols at dpkg-shlibdeps time
<cnd> the symbols exist in /var/lib/dpkg/info/libx11-6\:amd64.symbols
<cnd> do you know what might be wrong?
<SpamapS> infinity: indeed, we may have to move back to gcc 4.6 .. though I'm not sure why. :-/
<slangasek> cnd: have't seen this, no.  is there a build log I can peruse?
<slangasek> doko: speaking of eglibc, I noticed a strange thing when scanning precise for multiarch: same file collisions... apparently our libc6-dbg on armhf is using the wrong path?
<doko> huh?
<doko> looking
<slangasek> doko: oh, no - the problem is that it seems to contain dbg symbols for *both* archs?
<slangasek> so either it shouldn't contain biarch debug symbols, or it has to be not M-A: same
<doko> ahh, the install file has /usr/lib, which works on the other biarchs, but not arm*
<mr_pouit> mvo: thanks! Also, do you know why I can't find any xfce4-panel plugin in software-center? because they don't contain any desktop file?
<mvo> mr_pouit: I guess so, I don't know much about the panel - but they should appear in technical items, no?
<mr_pouit> mvo: mmh, I can't find them. Entering 'xfce' or 'xfce panel' in the search bar doesn't show any plugin (and there's no hidden technical hidden to expand)
<mr_pouit> *technical item
<cnd> slangasek, http://paste.ubuntu.com/843242/
<lifeless> is today a good day to upgrade machines ?
<SpamapS> infinity: before I go digging .. do you know why we decided to disable the test suite on non x86 arches?
<hrw> Bug #932882 anyone?
<ubottu> Launchpad bug 932882 in cups (Ubuntu) "The PPD version (5.2.7) is not compatible with Gutenprint 5.2.8-pre1." [Undecided,New] https://launchpad.net/bugs/932882
<slangasek> cnd: your libxorg-gtest.so.0 appears to not be directly linked against libX11
<cnd> slangasek, I'm a little fuzzy on shared libs and direct linking
<cnd> should it be linking directly>?
<infinity> SpamapS: There was no "we", I think it was just laziness. :P
<mvo> mr_pouit: I see a bunch of them, but it requires that you have apt-xapian-index installed (which you may not have)
<mvo> mr_pouit: its pretty heavy on a slow system :/
<cjwatson> pgraner: BTW that alsa-lib thing from earlier should be sorted now
<infinity> SpamapS: I know !x86 has always thrown a few more errors than x86, I imagine it crossed the unacceptable threshold recently and someone just turned off the suite.
<cnd> slangasek, ahh, I think I found the issue
<slangasek> cnd: it uses libX11, so it should be linked against libX11 at build time
<cnd> yeah
<Daviey> infinity: I thought it shipped 386 asm code?
<cnd> it's a bug upstream
<infinity> Daviey: I'm sure it does, but I'd assume that's not used on !x86. :P
<SpamapS> infinity: ok, seems like those bugs need to be reported and patched..its a little ridiculous. :p
<pgraner> cjwatson, yep saw that thanks!
<infinity> SpamapS: Yeah, no arguments here about reporting and/or fixing.
<Daviey> infinity: right, i thought that was the headache of previous cycles.. was that it DID (try) :)
<infinity> SpamapS: If there are a bunch that are arm (especially armhf) specific, you might be able to talk the Linaro folks into caring (see #linaro-armhf)
<infinity> SpamapS: But the first step to reporting suite failures is to disable upstream's braindead "I've hit $threshold failures, so not running any more tests!" check.
<mr_pouit> mvo: it's installed already, so i'm running update-xapian-index to see if it makes them reappear
<mvo> ok
<Daviey> infinity: in other news... did utlemming get to speak to you about bug 759545 ?
<ubottu> Launchpad bug 759545 in grub2 (Ubuntu Precise) "user prompted to update unmodified grub configuration during Ubuntu server upgrade" [Medium,Triaged] https://launchpad.net/bugs/759545
<infinity> Daviey: Nope.  Can you poke me on your Friday (ie: when my work day is starting), and I'll make some time to actually give it a proper eyeball.
<utlemming> Daviey: I'm here now
<infinity> utlemming: Unless you wanted to steal the bug and run with it.
<utlemming> sorry...what was the bug number?
<infinity> https://launchpad.net/bugs/759545
<Daviey> 16:57 < Daviey> infinity: in other news... did utlemming get to speak to you about bug 759545 ?
<ubottu> Launchpad bug 759545 in grub2 (Ubuntu Precise) "user prompted to update unmodified grub configuration during Ubuntu server upgrade" [Medium,Triaged]
<Daviey> infinity: thanks!
<mr_pouit> mvo: now I've ~40000 items in software-center instead of ~2800, so I guess it worked (I'll retry a fresh install later to confirm it's ok). Thanks for your help.
<utlemming> ah, I looked briefly at that bug yesterday...give me a minute
<infinity> utlemming: I'm fading fast and approaching post-all-nighter-panic-nap-land.
<infinity> utlemming: If you have stuff to add to the bug, post a bunch of comments. ;)
<utlemming> infinity: will do
<infinity> utlemming: If you have fixes (and/or want to fix it yourself), go nuts, and I'll be happy to review.
<infinity> utlemming: Otherwise, see above, re: Friday. :)
<mvo> mr_pouit cool
<hallyn> jcastro: hey, mr unity workflow master :) - i understand and like how super-N gets me between banshee and ff, for instance.  but do you have tips on how to best, quickly pick one of my 8 xterms on varoius desktops?
<tkamppeter> anyone here who can help me on a sync problem?
<tkamppeter> I want to sync the "pnm2ppa" package with Debian, once Debian's package needs all our needs, and second, to get rid of a broken upstream source tarball.
<kirkland> cjwatson: have we ever considered providing a command that would clean up (remove) old, unneeded kernels, either automatically or on demand?  (or does such a thing exist?)
<kirkland> cjwatson: on a very long-running ubuntu machine (especially a server), you may have hundreds of MB tied up in old kernels
<kirkland> cjwatson: once you've rebooted into one that works, it may be safe to purge old ones
<cjwatson> kirkland: that was the point of computer-janitor
 * kirkland looks at computer-janitor
<cjwatson> (which at some point ought to become part of software-center)
<cjwatson> tkamppeter: you won't be able to sync it until there's a new upstream version
<kirkland> cjwatson: suitable for servers too?
<cjwatson> kirkland: dunno
<barry> computer janitor should die :)
<cjwatson> yes; but that was its use case
<cjwatson> or at least its primary one
<kirkland> barry: :-)
<SpamapS> Software developers, more than any other profession, are way too comfortable with killing their least favorite children.
<kirkland> so we just received an email from a fairly large cloud hosting provider that's recommending all of their customers running Ubuntu run:
<kirkland> dpkg --get-selections|grep 'linux-image*'|awk '{print $1}'|egrep -v "linux-image-$(uname -r)|linux-image-generic" |while read n;do apt-get -y remove $n;done
<kirkland> and I face palmed
<kirkland> I'm thinking we could/should do better as a distro
<barry> SpamapS: i think it's just that they disappoint us so much more often
<SpamapS> barry: and they don't bear that much resemblance either
 * SpamapS *does* think that pipemeter is way too skinny to be his first born program
<tkamppeter> cjwatson, so I suggest then for the meantime to put a samne source tarball under a new "upstream" version, like 1.13+dfsg and then drop in Debian's debian/ directory and add a debian/changelog entry explaining the mess.
<cjwatson> tkamppeter: you're welcome to do such a thing, yes, although +dfsg conventionally indicates that the tarball has been stripped down to remove non-free elements
<cjwatson> tkamppeter: however
<kirkland> cjwatson: do you think it would be worth taking this discussion/suggestion (specifically about kernels) and computer-janitor and servers to ubuntu-devel?  Or would it just rehash old conversations?
<cjwatson> tkamppeter: you might be better off using syncpackage -F (a.k.a. --fakesync) - see its docs
<cjwatson> kirkland: well, it's not the first time it's come up by a long shot ...
<tkamppeter> cjwatson, perhaps then better 1.13+1 or 1.13+non-dbs?
<cjwatson> tkamppeter: or use syncpackage -F
<kirkland> cjwatson: well, service providers are now recommending customers run some pretty gross hacks to work around this
<kirkland> cjwatson: i guess that's what's new hear
<cjwatson> the effect of that is to upload the same contents as the Debian source package but with the current orig tarball in Ubuntu
<cjwatson> kirkland: not new at all
<kirkland> cjwatson: painful to watch that go down, from my perspective
<tkamppeter> cjwatson, tried already --fakesync, but failed. Should I paste the output?
<cjwatson> tkamppeter: sure
<cjwatson> (but into paste.ubuntu.com, not the channel)
<cjwatson> kirkland: it's probably best to talk to the software-center developers if you want to try to move it forward
<cjwatson> though I don't know what they think of server use cases
<kirkland> hmm, computer-janitor doesn't look immediately functional in a server environment
<kirkland> ERROR:dbus.proxies:Introspect error on :1.3:/: dbus.exceptions.DBusException: org.freedesktop.DBus.Error.AccessDenied: Rejected send mes
<kirkland> sage, 1 matched rules; type="method_call", sender=":1.6" (uid=0 pid=20204 comm="/usr/bin/python /usr/sbin/computer-janitor find ") inter
<kirkland> face="org.freedesktop.DBus.Introspectable" member="Introspect" error name="(unset)" requested_reply="0" destination=":1.3" (uid=0 pid=19
<kirkland> 905 comm="/usr/bin/python /usr/share/computerjanitor/janitor")
<kirkland> cjwatson: thanks;  who are the software-center developers?
<cjwatson> kirkland: https://wiki.ubuntu.com/SoftwareCenter
<kirkland> cjwatson: thx
<tkamppeter> cjwatson, will do, just a minute.
<cjwatson> I'm also surprised that (in theory anyway) apt-get autoremove couldn't do the same thing
<slangasek> "remove all but the current and most recent kernel" is a bit beyond what apt-get autoremove can do itself currently
<cjwatson> mm
<mdeslaur> @pilot out
<mdeslaur> bah
<mdeslaur> dholbach: ^
<tkamppeter> cjwatson, http://pastebin.ubuntu.com/843314/
<dholbach> mdeslaur, I asked in #ubuntu-irc if somebody can help
<dholbach> mdeslaur, I don't have the keys to it
<cjwatson> that seems to be a problem with the pnm2ppa package in Debian itself ...
<mdeslaur> infinity: could you remove me from the topic pleeeeze?
<cjwatson> though can't say I can immediately work out what
<Laney> mdeslaur: you can remove yourself; the topic in here isn't protected (unless that's what C or z do)
<cjwatson> oh, I see, it's getting confused by the Ubuntu tarball being tarball-in-tarball packaging, how gross
<cjwatson> maybe you can't syncpackage this after all
* mdeslaur changed the topic of #ubuntu-devel to: Alpha 2 released!  Archive: open | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #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:
<mdeslaur> Laney: hehe, thanks
<cjwatson> I think your only choices are (1) just manually sync in the packaging changes you want (2) persuade Debian to artificially bump the upstream part of the version
<mdeslaur> infinity: never mind :)
<tkamppeter> cjwatson, this DBS is really crazy. It was one of my predecessors who packaged that way. I will remove it by using a renamed source tarball.
<smoser> well, i'm not going to bother contributing anything eles to the "get rid of all kernels", but this seems reasonable and generally safe to me:
<smoser> list_removable_kpkgs() { dpkg -l | awk '$2 ~ /^linux-[a-z]+-[23][.][0-9].[0-9][.0-9]*-[0-9]+/ && $2 !~ cur { print $2 }'  cur="linux-[a-z]+-$(uname -r)" ; }
<cjwatson> tkamppeter: yes, DBS is awful
<smoser> i guess you'd also want it to filter out newest.
<jtaylor> barry, doko: will you still have a look at the numpy merge before ff?
<barry> jtaylor: i can look at it today.  can you paste some links?
<jtaylor> barry: https://code.launchpad.net/~jtaylor/ubuntu/precise/python-numpy/merge-1.6/+merge/92671
<SpamapS> hm
<SpamapS> retrying the amd64 tests passed.. but I'm not sure thats exactly a good thing
<herton> @pilot in
* herton changed the topic of #ubuntu-devel to: Alpha 2 released!  Archive: open | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #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: herton
<tkamppeter> cjwatson, thank you very much. New pnm2ppa package is uploaded now.
<doko> jtaylor, barry: does this come with at least scipy updated as well?
<jtaylor> no scipy has not been updated in debian yet
<jtaylor> for to little time do that in ubuntu only now
<scott-work> apw: i apologize for being a pest, but do you have an eta for checking the -lowlatency kernel?  i'm concern with having enough time to make changes (which might not be made by me) in time for the feature freeze
<doko> jtaylor, does the old scipy work with the new numpy?
<jtaylor> numpy 1.6 was released 6 month before scipy .10 so I hope so
<doko> could you just rebuild it to be sure?
<jtaylor> doko: I did already, all rdepends build
<hallyn> if package a has build-depends: b, and b has Depends: c, will c be installed by apt-get build-dep a?
<jtaylor> I also checked the arch all depends for the minor api removals
<doko> ok, thanks
<jtaylor> doko: only 2 affected, one easy to fix one fixed already in unstable (going to merge soon)
<jtaylor> doko: numpy 1.6 is abi compatible with 1.5 but there is a new dh_numpy so I want to rebuild the arch any packages anyway
<micahg> hallyn: should be, but I suggest sudo mk-build-deps -i -r unless you're in a chroot you don't care about
<hallyn> micahg: well, what i really meant was - will that be enough for the buildd to install package c while building a?
<micahg> hallyn: yes, but if your package needs it specifically, you should build-depend on it
 * hallyn looks up mk-build-deps, sounds interesting
<doko> apw, ogasawara: I'll need one more gcc-4.6 upload tonight, fixing a regression with the last upload
<ogasawara> doko: ack, that should be fine
<hallyn> ok, thanks.  well, is that something debian would agree with (and accept a patch for)?
<micahg> hallyn: generally, yes, but it's only RC severity if it currently fails to build in Debian without it
<hallyn> micahg: ok, thanks
* herton changed the topic of #ubuntu-devel to: Alpha 2 released!  Archive: open | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #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:
<hallyn> doko: do you have any plans on further eglibc updates?  I'm looking at bug 930181 , not sure whether i should work around it with a #define, or wait
<ubottu> Launchpad bug 930181 in qemu-kvm (Ubuntu) "qemu-kvm (1.0+noroms-0ubuntu4) fails to build on Ubuntu Precise locally" [High,Confirmed] https://launchpad.net/bugs/930181
<doko> hallyn, I don't have any plans. di you talk with the kvm Linaro guys?
<hallyn> thanks. no, i didn't.  yet.
<hallyn> slangasek: lool: ^ have you guys seen the AT_EMPTY_PATH failure when qemu-linaro builds?
<hallyn> (it's in the 9p virtio code, so you might not enable that...)
<slangasek> hallyn: yes
<slangasek> wait, maybe that's not the one I'm thinking of
<slangasek> hallyn: no, what I've seen is this failure when you mentioned it to me the other day - sorry :)
<hallyn> lol - i didn't remember asking you before.  ok, thanks.
<hallyn> i guess i can just work around it with a #ifndef #ifdef...
<lifeless> heh
<lifeless> libc:i386 wants to restart services... why?
<cjwatson> because the code that asks that question hasn't checked whether it's running for a foreign architecture or not
<slangasek> yes, and it's not entirely clear to me how it should do so
<slangasek> (the one I enjoyed was libc6:armel restarting services)
<hallyn> doko: let me try one more time.  The core problem is that /usr/include/asm-generic/fcntl.h and /usr/include/x86_64-linux-gnu/bits/fcntl.h cannot be sourced at the same time.
<hallyn> they have conflicting definitions of several structs
<hallyn> I can work around it, mind you, but is that going to be a problem for more people?
<slangasek> hallyn: what's the path by which /usr/include/asm-generic/fcntl.h is being pulled into your code?
<slangasek> given that this is a kernel header
<hallyn> slangasek: if i want AT_EMPTY_PATH, i need to #include <linux/fcntl.h>
<hallyn> that's how it happens
<slangasek> ah
<hallyn> so i can just #define it by hand, but i don't want to work around something that's going to get worse for other people...
<slangasek> well, so, the kernel is responsible for making sure any structs it exports to userspace via linux-libc-dev are actually compatibleâ¢
<slangasek> and while it's not good to have this sprung on us suddenly like this, in general if the struct definitions don't match, it's a kernel bug, not an eglibc bug
<slangasek> because eglibc owns the namespace here
<hallyn> slangasek: so i should open a bug against linux, then?
<slangasek> I think so
<hallyn> great, will do - thanks
<cjwatson> slangasek: libc6:foreign> isn't that just a matter of substituting DEB_HOST_ARCH into the maintainer script and then comparing against dpkg --print-architecture at install time?
<slangasek> cjwatson: if we assume that services installed are all of the primary architecture
<slangasek> I wasn't prepared to make that assumption
<cjwatson> slangasek: but, given the multiarch constraints, if you install a new libc6:foreign at any point then you must either have just installed a new libc6:primary or be about to do so
<slangasek> cjwatson: oh yes!
<cjwatson> and by the time you get to libc6:foreign.postinst, libc6:primary should be at least unpacked, IIRC
<slangasek> good point
<cjwatson> (though check that assumption, I can't remember how it works with immediate configuration)
<cjwatson> I suppose it's possible that it goes libc6:primary unpack, libc6:primary configure, libc6:foreign unpack, libc6:foreign configure, which would break my assumption
<lifeless> slangasek: nice (libc6:armel)
<slangasek> cjwatson: dpkg doesn't allow configuring m-a: same packages unless they're both unpacked at the same version :)
<cjwatson> slangasek: hooray
<barry> jtaylor: i'm just doing a few local test builds but if those sanity check okay, i'll upload your numpy 1.6 branch in a little bit
<barry> (and get rebuilds of the 18 failures)
<jtaylor> barry: great thanks
<jtaylor> 18 failures?
<barry> er, not failures: http://people.canonical.com/~ubuntu-archive/transitions/numpy.html
<micahg> jtaylor: is the multiarch change folded in to the 1.6 migration?
<jtaylor> micahg: yes
<barry> jtaylor: i'm just the monkey pushing the buttons.  thank *you* for all your great work pushing this forward
<jtaylor> barry: I can do the universe rebuild
<jtaylor> did them all locally already, all succeed
<jtaylor> veusz needs special attention
<barry> jtaylor: fab!  okay, i'll push numpy now then.  ping me if you need anything else
<barry> jtaylor: in case you're interested, i cannot bzr merge your branch into ubuntu:python-numpy.  bzr crashes.  yes, i should report that ;)
<barry> jtaylor: but i did diff locally and looked at the debian/ diffs.  they looked sane to me
<barry> jtaylor: uploaded
<jtaylor> thx
<jtaylor> too bad I didn't find the time for py3 :(
<barry> ah well, there's always qwazy quahog
<jtaylor> rejected :(
<barry> gar
<broder> barry: awesome, i was debating bothering you to look at the numpy merge :)
<barry> broder: good thing you waited, otherwise i would have stolen all of jtaylor's rightfully earned kudos :)
<SpamapS> anybody else want to weigh in on whether or not we should update Erlang to R15B vs. the current R14B4 ?
<SpamapS> upstream says that R15B is the bees-knees
<jtaylor> considering the load of the buildd's should I wait with the no change rebuilds for numpy?
<jtaylor> at least until the test build is done on arm?`
<YokoZar> cjwatson: Can I poke you ~ https://bugs.launchpad.net/ubuntu/+source/dssi-vst/+bug/925127   (deleting the old wine packages) since you last touched wine1.4 :D
<ubottu> Launchpad bug 925127 in lmms (Ubuntu) "Please remove wine1.2, wine1.3, wine1.2-gecko, wine1.3-gecko from archive" [Undecided,New]
<barry> jtaylor: dunno, might be worth getting them into the queue.  i'm depwaiting on several arm builds myself
<jtaylor> I just saw in the ghc bug that -release asked for them to wait until its done
<jtaylor> though ghc are 470 packages not 18 ;)
<tumbleweed> jtaylor: ghc is way nastier than numpy
<barry> oh, definitely get it in the queue now then :)
<broder> haha
<micahg> jtaylor: load on buildds isn't heavy
<broder> micahg: the armhf buildds have a 2-day queue
<micahg> it's all rebuilds save for powerpc
<Laney> mmmmm tasty ghc
<micahg> broder: that's the test rebuild, ignore it :)
<broder> jtaylor: so https://code.launchpad.net/~jtaylor/ubuntu/precise/python-numpy/multiarch-fix-818867/+merge/87165 can be rejected at this point, right?
<jtaylor> broder: yes
<tumbleweed> Laney: btw, my pypy 1.8 upload is currently stuck in Debian binNEW. I'll probably be asking for an FFe on the weekend
<broder> jtaylor: would you mind? i don't have my lp creds on me at the moment
<Laney> ^o)
<Laney> does it build on arm yet?
<jtaylor> broder: I can only set it merged or wip
<tumbleweed> I built it on debian porterboxes. Only took a couple of days (and got me comments from DSAs in #debian-devel about load :P )
<jtaylor> merged is kind of right so should I do thaT?
<broder> jtaylor: merged isn't really inaccurate
<broder> i'd go with that
<Laney> heh
<Laney> so, not on the buildds yet?
<tumbleweed> when we get arm buildds with >2G RAM then it'll be good
<micahg> well, the problem with ghc on arm is ghc-ghci
<tumbleweed> possibly on debian buildds with 1.5G. I don't think Ubuntu has any that big
<Laney> that is one of the problems
<broder> whoo! sponsor queue now has nothing more than...34 days old! :)
<infinity> Laney: Oh, do you happen to know the status of ghci on arm?
<Laney> Still doesn't work, but at least 7.4 has registerised arm builds
<infinity> Laney: Is there any work being done on it, or just a bunch of people asking?
<Laney> Yeah I think there is some work being done; there's an infrequently updated blog at http://ghcarm.wordpress.com
<tumbleweed> barry: forget -v with numpy? :)
<barry> tumbleweed: ?
<tumbleweed> barry: when merging we use -v[previous ubuntu version] so that all the intermediate debian changelog entries are included in the .changes file
<barry> tumbleweed: yeah, there have been some bugs in udd about that.  i should go back and look to see if they've been fixed or not
<tumbleweed> ah, you should be able to pass that to bzr bd after a --
<tumbleweed> but yes, it'd be nice if it did it automatically
<barry> right, it's *supposed* to do it automatically ;)
<micahg> yes, but one should verify the source.changes file before dputting :)
<barry> very true. i did look, but should have been more careful
<tumbleweed> that's helped me catch a few mistakes (and I've also forgotten to check a few times and missed them :P )
<micahg> at least until it's 99.9% foolproof :)
<micahg> even then though, I find it helpful to catch mistakes as tumbleweed said
<barry> ah, okay, it's still in "new" state (bug 788349) so i will get it through my thick skull not to count on it
<ubottu> Launchpad bug 788349 in Ubuntu Distributed Development "Auto supply -v<last ubuntu version> for bzr bd -S?" [Undecided,New] https://launchpad.net/bugs/788349
 * micahg discussed with jelmer at the rally, but it seems that bzr-builddeb isn't the ideal place for the fix for this
<broder> barry: any reason for me not to upload tumbleweed's fix for bug #915167? i'll do some quick testing, but it looks trivially and obviously correct
<ubottu> Launchpad bug 915167 in python-defaults (Ubuntu Natty) "pycompile will use /usr/local/bin/python2.X if available and python2.X is installed." [Medium,Confirmed] https://launchpad.net/bugs/915167
<tumbleweed> broder: thanks
<broder> tumbleweed: ugh, is python-defaults a debian-native package with a debian revision number?
<tumbleweed> yup. it kinda makes sense, though
<slangasek> smoser: hi, did you have a chance to check out the new upstart?
<broder> tumbleweed: for what it's worth, it looks like the python2.7 postinst has a similar problem with preferring the python2.7 in your path
<tumbleweed> broder: so it does
<broder> i don't know whether that's still the case and how worth fixing that is
<tumbleweed> seems to still be the case, /me plays a bit
<broder> anyway, i'll still go ahead and upload the python-defaults change, since it seems correct
<tumbleweed> broder: so, a locally built cpython (2.7.0) installed in /usr/local doesn't break the postinst
<broder> printf '#!/bin/sh\nexit 1' >/usr/local/bin/python2.7 does
<tumbleweed> yes, but that was a pretty evil test :)
<broder> why did it break with a real cpython in /usr/local?
<tumbleweed> I'm assuming because the postinst has the full path to py_compile.py, and it's the locally built python's py_compile.py that is missing features we need
<broder> ok. i'm just thinking - doesn't debian policy have something to say about not using absolute paths in maintainer scripts?
<broder> i'm wondering if this change runs afoul of that
<tumbleweed> yes http://www.debian.org/doc/debian-policy/ch-maintainerscripts.html
<tumbleweed> but this is obviously the correct thing to do here (my proposed patch)
<broder> ok. good enough for me
#ubuntu-devel 2012-02-16
<eightyeight> is the kernel frozen for 12.04?
<broder> eightyeight: https://wiki.ubuntu.com/PrecisePangolin/ReleaseSchedule lists kernel freeze as april 5th
<smoser> slangasek, :-( no.
<smoser> i'm sorry.
<slangasek> smoser: hmm.  are there any tests in particular you'd like us to do before landing it in the archive?
<slangasek> (ones that we can get done before FF, I hope)
<smoser> i dont have a lot of expectancy of failure.
<smoser> for it.
<smoser> cloud-init is generally fairly light on it.  uses mounted event nof '/'.
<AaronMT> Has there been a security bug filed for seclists.org/fulldisclosure/2012/Feb/254
<slangasek> smoser: sure; we're being very cautious this time around, owing to the two previous false starts
<slangasek> so if you don't think there's anything special we need to test, I can just go ahead with the upload
<broder> slangasek: thoughts on https://bugs.launchpad.net/ubuntu/+source/sysvinit/+bug/858122/+attachment/2683183/+files/insserv_1.14.0-2.1ubuntu1.unstable.debdiff ? it seems reasonable (modulo needing quilt and changelog adjustments)
<ubottu> Launchpad bug 858122 in sysvinit (Ubuntu Precise) "incomplete migration to /run (shutdown script order has been demolished)" [High,Triaged]
<broder> if it's ok with you i can upload it and prep/upload an oneiric sru
<smoser> slangasek, i'll start an instance and install right now.
<smoser> ppa link ?
<slangasek> smoser: ppa:jamesodhunt/upstart-job-logging
<slangasek> broder: YES PLEASE
<slangasek> <cough>
<broder> slangasek: haha, ok. any thoughts about attempting to unwind the damage?
<slangasek> broder: I think I sketched something out on the bug about manually putting the key bits of /etc/rc{0,6}.d back where they belong if we detect this kind of massive breakage on upgrade
<slangasek> broder: we might not get all of it right, but we can at least get the core initscripts stuff
<broder> ok. i'll sketch something up. it'd be nice to have you review it, since complex maintainer scripts are easy to screw up
<slangasek> :)
<mwhudson> what could go wrong
<slangasek> mwhudson: little more than already has done P
<slangasek> :P
<broder> look, i'm absolutely terrified of uploading insserv. that's why i'm forcing slangasek to sign off on anything i do - so i can at least spread the blame :)
<smoser> slangasek, ok. initial snif done.
<slangasek> smoser: thanks :)
<smoser> no kittens sacrificed. 2 instances booted twice each.
<broder> slangasek: ok, that actually seemed a little more straightforward than expected. how does http://paste.ubuntu.com/843826/ look to you?
<slangasek> broder: I had been thinking in terms of the fix-up being done in initscripts, as the owner of both the scripts in question and the /run transition that's gotten clobbered; are you sure that doing the fixup from insserv will dtrt everywhere?
<broder> hmm, not really. i hadn't thought about it all that hard
<broder> i guess i figured that correcting the shutdown sequence from anybody's postinst -> initscripts shutdown script will do the right thing next time you reboot
<cjwatson> ScottK: bug 634215 - why are all-numeric host names prohibited?  I mean, I get that they might be considered unwise in some contexts, but my reading of RFCs 952 and 1123 in conjunction is that all-numeric host names are permitted, and indeed I think 1123 indicates that host software MUST support them
<ubottu> Launchpad bug 634215 in ubiquity (Ubuntu) "ubiquity-kde install allows invalid hostnames" [Wishlist,Triaged] https://launchpad.net/bugs/634215
<slangasek> broder: two other things: 1) if the runlevel's been broken, you'll see S0{1,2,3}reboot; maybe it's better to check for one of these values instead of just !90, in case the admin had some other reason for renumbering (e.g., having fixed up all their init scripts so insserv actually works for them)?  2) the fix-up needs to handle rc0 in addition to rc6
<slangasek> cjwatson: hmmm, stgraber brought that one up the other day and I asserted that all-numeric is illegal; perhaps I should dig up a real reference :)
<slangasek> cjwatson: in *practice*, an all-numeric hostname gets butchered by various unix tools, which will helpfully interpret it as a decimal encoding of an IP
<broder> slangasek: ok. i guess i need to s/reboot/halt/ for rc0, but other than that fix up the same scripts in the same way?
<broder> slangasek: but if you'd rather have this in initscripts, i'll drop the postinst from insserv and upload it, then we can work on getting initscripts fixed
<cjwatson> slangasek: I'm not necessarily opposed to making the installer forbid them, but I feel I'd like to have chapter and verse here :)
<cjwatson> especially since netcfg has the same algorithm
<slangasek> broder: yes, s/reboot/halt/ should be the only change... and yeah, I have a slight preference for putting this in initscripts, rather than embedding knowledge of another package's init scripts in the insserv postinst
<broder> slangasek: i'm fine with that
<stgraber> cjwatson: from my last RFC reading (last week), there's nothing explicitly prohibiting the use of all-numeric host names, as long as they aren't also used as part of a DNS record (where a DNS label can't be made of all-numeric)
<cjwatson> stgraber: where does that restriction come from?
<stgraber> cjwatson: 1912 IIRC
<slangasek> cjwatson: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=65041#34 ?
<ubottu> Debian bug 65041 in libc6 "glibc does not allow numeric hostnames" [Normal,Open]
<infinity> rfc2181 pretty much throws it all out the window, and only keeps the 63-byte restriction.
<infinity> But there's no reason systems can be more restrictive than the RFC (and, in our case, reasons why we need to be).
<slangasek> well, gethostbyname() is a deprecated interface, but we either have to modify its behavior or accept that anything using it will be broken with numeric hostnames
<cjwatson> ah, gotcha
<cjwatson> that's probably enough for me to change netcfg too then
<slangasek> (also, not sure if the glibc implementations of the ipv6-friendly interfaces actually do a better job with them?)
 * infinity figures the summary at the top of http://www.zytrax.com/books/dns/apa/names.html is a fair representation of the pre-2181 rules, and probably not an awful constraint for installers to impose.
<infinity> cjwatson: ^
<ScottK> cjwatson: The hostname itself can be all numeric (the machine name), but the top level domain (at least historically can't).  Says so in RFC 1123 paragraph 2.1.
<cjwatson> That point's clear (although the RFC is mainly making an observation about the existing set of TLDs, I think ...), but you aren't entering an FQDN in ubiquity.
<broder> slangasek: do you have an opinion on whether or not i should also move /usr/sbin/{update-rc.d-insserv,update-bootsystem-insserv}?
<ScottK> infinity: I don't see anything in 2181 that changes that.
 * slangasek looks at broder blankly
<slangasek> broder: not knowing what these are or why they exist, I don't have an opinion :)
<ScottK> cjwatson: It used to be that all numeric wasn't allowed for the machine name, but that changed, so maybe I was confused.
<slangasek> "update-rc.d-insserv is an obsolete implementation [...]"
<slangasek> seems like upstream should move that one to /dev/null
<slangasek> and the other one is a trivial script we don't need to care about
<slangasek> broder: ^^ so I think it's not worth moving them
<cjwatson> The gethostbyname problem is somewhat persuasive.
<infinity> ScottK: We weren't talking about FQDNs until just now...
<broder> slangasek: ok. sounds good
<ScottK> OK.
<ScottK> never mind me then.
<cjwatson> I've mailed debian-boot to ask if anyone cares if I make such a restriction
 * infinity remembers the bad old days when various operating systems used to tell him that his domain name was invalid.
<cjwatson> You were just testing them, right?
<infinity> cjwatson: NT4 had hissy fits about 0c3.net until SP3, I believe.
<infinity> cjwatson: Which caused me some grief.
<broder> oh what the heck. why does insserv ftbfs, but only in sbuild
<broder> ...with fopen(file_the_test_suite_just_wrote_out): Operation not permitted
<infinity> broder: In your local sbuild, you mean?
<broder> infinity: yeah
<infinity> broder: Is that running on top of an overlayfs-using schroot?
<infinity> broder: If so, that's your answer.
<broder> ...seriously?
<broder> ugh
<infinity> broder: The good news is that the buildds won't fail that way. :P
<infinity> broder: The bad news is you need to test without overlayfs locally.
<broder> wait, but why does it not happen if i build it with schroot dpkg-buildpackage, but not using sbuild?
<broder> oh, i guess that would be hitting one of the bind mounts
<broder> what is overlayfs doing wrong?
<infinity> broder: overlayfs plays fast and loose with inodes in ways that can confuse tools that assume that inodes don't (or do) change based on certain actions.
<broder> oww
<infinity> broder: The tools (or, in this case, test suite) are usually wrong, not overlayfs, but...
<broder> ok. since i *can* build it without copying the source into the overlayfs, i'll go ahead and move forward
<geofft> infinity: out of curiosity, is there documentation of usual overlayfs issues?
<geofft> I have a local buildd that I was just about to switch from LVM chroots to overlayfs one of these weekends...
<infinity> geofft: Mostly in apw's head, and scattered around to others who've had to deal with it. :P
<infinity> geofft: If you have a working LVM setup, I see no compelling reason to switch.
<geofft> infinity: "working" is a bit much, it randomly panics during rebuilds every so often
<infinity> Special.
<broder> also LVM snapshot-based chroots are borderline unusably slow, especially when there are a lot of them in action
<infinity> Anyhow, other than "some software makes stupid assumptions about filesystems that it shouldn't" and "overlayfs doesn't support inotify", I can't think of any other known gotchas.
<geofft> (hm, I'm misremembering, we switched it to aufs IIRC because of the slowness, and aufs brings the panics)
<andy753421> is it possible to request a sync from a PPA instead of from debian (or maybe not a sync, but something along those lines?)
<Daviey> andy753421: raise a sponsorship bug and link to the PPA.
<nigelb> man, Daviey is still awake?
 * nigelb looks at the clock and gets confused
<Daviey> nigelb: yes
<nigelb> Daviey: Go to bed you crzy person.. err, I mean.. Hi!
<Daviey> nigelb: heh
<nigelb> :)
 * dobey wonders if he could possibly get someone to review https://code.launchpad.net/~dobey/ubuntu/precise/twisted/backport-gireactor/+merge/93329 tonight
<broder> slangasek: that insserv fix technically needs to be sru'd to lucid through oneiric, right?
<broder> err, that's a dumb question that i know the answer to, since i hit the bug after installing vmplayer 4 on natty
<pitti> Good morning
<slangasek> broder: it's beneficial to SRU it to lucid through oneiric, but the most important is oneiric because that's where things go wrong with initscripts... for the other releases, nobody's reported any bugs yet
<soren> soren`: ?!?!?
<soren> soren`: You're officially freaking me out.
<soren> Oh! That thing!
<broder> slangasek: i installed vmplayer 4 on natty before upgrading to oneiric, triggering the bug
<slangasek> broder: and the fixed initscripts cleaned it up suitably?
<broder> slangasek: err, haven't made it that far in testing yet
<slangasek> ok :)
<broder> at the time, i think i went for the "nuke it from orbit" approach of rm /etc/rc*.d/[SK]* && dpkg --reconfigure --something-clever
<pitti> broder: --force-confmiss probably?
<broder> i thikn i just had a complicated one-liner to figure out all the packages that had scripts in /etc/rc*.d and then reconfigure them to run update-rc.d
<broder> slangasek: whoa!! vmware fixed their installer in 4.0.2!
<broder> it checks for update-rc.d before insserv now
<broder> slangasek: anyway, if i run insserv in my precise vm by hand and then install http://paste.ubuntu.com/844050/, it does seem to fixup the symlinks as expected
<broder> it didn't seem like there was a particular spot in the postinst the code needed to live, so i picked a point a bit above the /run transition code, since it seemed like this should probably be fixed up before then
<rickspencer3> pitti, am I reading this right? Feature Freeze is today, but only a few problems (all armel) in the archives, and all of the ISO smoke tests but one are passing?
<rickspencer3> that's pretty cool
<pitti> rickspencer3: yes, the recent compiz upload broke armel unfortunately :(
<pitti> rickspencer3: otherwise it's holding up pretty well indeed
<rickspencer3> well, I think it's a great result, especially for the week of feature freeze
<pitti> not sure whether didrocks has a trick up his sleeve to fix compiz on armel, though
<didrocks> pitti: the issue is in kelibs
<didrocks> kdelibs*
<didrocks> I ask Riddell to look at it
<didrocks> rickspencer3: just to be clear, compiz FTBFS on armel is due to kdelibs which ship a broken header, Riddel is already aware about it
<rickspencer3> thanks for the update didrocks
<rickspencer3> just to be clear, I wasn't actually complaining, as I don't recall being close to this tight on previous FF days ;)
<didrocks> yeah, it's just on this one "not compiz fault" :) (most of the time, it is, not one that though ;))
<pitti> bdrung: do you care about the vlc FTBFS on powerpc? if not, we could just remove the powerpc binaries
<micahg> mvo: sorry, was in the wrong channel, can I drop the intltools patch from aptitude?  it's commented out, but it's a 50k line diff
<mvo> micahg: yeah, if po and source are in sync again that is really not needed anymore
<micahg> mvo: is there an easy way for me to check that?
<mvo> micahg: well, I guess what it comes down to is if there are no po file diffs in the other patches it is fine
<micahg> mvo: ah, ok, I'll check, thanks
<micahg> nope, no po diffs, so I can drop it from the source then (I assume it's easy to recreate again)?
<Riddell> didrocks: as I said on the bug report nobody knows how to solve that compiler error, either get someone to port the code or drop the compiler -Werror or drop the kde compiz bits, alas I don't have time for much non-Kubuntu while I'm still allowed to work on it
<didrocks> Riddell: ok, I'll drop the kde build from compiz then
<didrocks> not sure anyone is using it anyway
<didrocks> if*
<mvo> micahg: yeah, thats fine
<mvo> micahg: its auto generated
<mvo> anyway
<micahg> ok, thanks
<mvo> ta!
<micahg> I still need to finish it, the patches need refreshing, but I'm hopeful :)
<Riddell> didrocks: just be gentle so we don't get "you don't care about kde" comments!
<didrocks> Riddell: hum? I just meant that people using kde are on kwin I guess, not compiz
<didrocks> Riddell: I'll make it clear in the changelog, no worry :)
<Riddell> didrocks: yes you're right.  but if one troll sees it differently it could go down badly
<didrocks> Riddell: right, will take great care on the changelog ;)
<Riddell> (and I've had to do more than enough media and community management recently as it is!)
<pitti> RAOF, Laney: do you have an idea about https://launchpadlibrarian.net/93054472/buildlog_ubuntu-precise-i386.tomboy_1.9.5-1ubuntu2_FAILEDTOBUILD.txt.gz ? it built fine locally
<pitti> I guess there's a missing build dep which I have installed locally; cli-common-dev ?
 * apw wonders how long before the archive might not remove every :i386 package he has installed
<pitti> did that change recently? the previous tomboy built fine without it
<pitti> apw: gcc-4.6/i386 still building :/
<apw> the compiler causes this mess, we really should build that in a PPA and copy it in if its going to cause utter uninstall every time
<pitti> apw: we had a lot of similar cases recently (webkit, compiz, glibc, etc.)
<apw> pitti, i take it that means the compiler triggers a multi-arch missmatch if amd64 and i386 don't hit together
<pitti> apw: we discussed using precise-proposed for this, so that we have ONE staging area instead of dozens of PPAs, and we can  copy binaries (which is really a main point)
<pitti> apw: correct
<apw> pitti, hehe thats funny, thats was my solution too :)
<pitti> we just need a LP tweak to allow this
<seb128> using ppa doesn't work, or we need non virtual ones
<seb128> but yeah, -proposed would be better
<pitti> great, and now the buildds are all firefoxed
<apw> pitti, i guess one needs to be able to copy your own packages from devel -proposed
<apw> for that work work any
<pitti> apw: yes, but I don't consider that a blocker
<pitti> initially we'd only use it for a few packages which are huge and known to cause major damage if they FTBFS or go out of sync
<pitti> such as yesterday's mysql, or glibc, or webkit
<apw> pitti, yeah that is a reasonable plan indeed if its optional like that
<bdrung> pitti: vlc will build on powerpc once the final 2.0.0 is released.
<pitti> apw: and for the time being it's a simple script invocation by any archive admin
<pitti> sru-release precise glibc
<pitti> (we might rename it for this)
<pitti> bdrung: ah, thanks; I have a local build prepared that disables altivec for now, want me to try that?
<bdrung> pitti: no. can you grab 2.0.0+git20120215+r81-0~r28~oneiric1  from https://launchpad.net/~videolan/+archive/stable-daily and try to build that on powerpc?
<pitti> bdrung: that's more effort/responsibility than I'm willing to take
<pitti> I don't care AT ALL about powerpc, just about getting rid of the NBS dependencies :)
<pitti> (in fact, I think we should have killed it long ago, but *shrug*)
<bdrung> pitti: you could either wait a few days or remove the powerpc binaries in the meantime. do what you prefer
<pitti> bdrung: ok, thanks
<SpamapS> oh how I love php's crappy multiarch
<pitti> RAOF, Laney: ah, tomboy does b-dep on cli-common-dev, so it's not that
<pitti> so, I'm lsot :/
<Laney> pitti: It's the DLLMap in debian/
<Laney> WebSyncServiceAddin.dll.config probably
<Laney> the soname needs fixing there
<Laney> did you build on a system with libproxy0 installed?
<pitti> Laney: yes, it's still installed here
<pitti> Laney: but the source diff was a no-change upload (http://launchpadlibrarian.net/93053939/tomboy_1.9.5-1ubuntu1_1.9.5-1ubuntu2.diff.gz)
<Laney> the DLLMap references the soname, it needs to be updated
<pitti> Laney: ah, so that's why it worked locally
<Laney> yeah, it probably would have failed in a chroot
<pitti> Laney: thanks, doing this
<Laney> np
<gotwig> hey
<gotwig> where is app development channel?
<bdrung> gotwig: look at the topic: #ubuntu-app-devel for app development on Ubuntu
<gotwig> bdrung: it will be an app for ubuntu
<gotwig> I know, what ever
<vila> hi guys, I'm running precise on my laptop and did a partial upgrade this morning,
<vila> I encountered  http://pad.lv/933343 and after reboot I can only login with the recovery console (Unity and Unity 2D are not presented anymore in the lightdm menu)
<ubottu> Error: Could not gather data from Launchpad for bug #933343 (https://launchpad.net/bugs/933343). The error has been logged
<vila> I also encounter transient connection issues during 'apt-get update' for extras.ubuntu.com and archive.canonical.com
<vila> apt-get -f install  failed with... ha, it was failing on the flash stuff but has just started downloading... hold on ;)
<vila> ok, with archive.c.c letting download the flash upgrade, everything is back to normal, more fear than harm ;)
<frafu> Hi, We released Onboard 0.97.0 yesterday and it has been accepted as onboard 0.97.0-0ubuntu1 into Ubuntu main. Shortly afterwards, a bug with translations appeared, we already fixed it in trunk and are going to release 0.97.1 today. My question: Are micro releases (i.e.:  0.97.1-0ubuntu1) accepted in feature freeze or should I rather submit it as patch creating onboard 0.97.0-0ubuntu2?
<micahg> frafu: bug fix only releases aren't a problem generally
<micahg> well, at least at this point
<SpamapS> They're really not a problem up until beta
<SpamapS> really, beta2
<frafu> micahg, SpamapS : So bugfix micro release updates are accepted until beta2. These were the pieces of information I was looking for. Thanks to both of you.
<SpamapS> frafu: its not a hard and fast rule.. but generally yes, fixing bugs up until the betas are out is a good idea
<SpamapS> frafu: after beta2 .. its up to the release team
<frafu> SpamapS: Maybe a few more words to the procedure to get it accepted until beta2: I should file a bug containing a debian source package based on the new micro release and add the Ubuntu Sponsor Team to the bug; correct?
<SpamapS> frafu: correct. Make sure you reference upstream bug comments/commits/etc.
<geser> the procedure should be the same as before FF (perhaps just mention in the bug that it's a bugfix release and adds no new features)
 * SpamapS wills the PHP test suite to pass, so he can sleep
<frafu> SpamapS, geser: Thanks
<SpamapS> alright.. latest (sane) version of PHP uploaded..
<ion> Isnât that an oxymoron? :-P
<SpamapS> PHP is perfectly sane. Its the users who keep using it expecting a different result (non-suckage)
<micahg> SpamapS: did the new sbuild help for dependency resolution?
<SpamapS> micahg: nope, still have to use aptitude resolver
<SpamapS> micahg: I haven't dist-upgraded since Friday.. was a new one uploaded this week?
<micahg> SpamapS: I uploaded it tonight, commented on your bug :)
<SpamapS> micahg: I'm sure I'll have to build php5 again this cycle. :)
<micahg> especially if we go to 5.4 :)
<SpamapS> micahg: high degree of liklihood there will be *another* RC
<ajmitch> SpamapS: did php manage to get 5.4.0 out yet? :)
<SpamapS> micahg: they broke signal handling, badly
<ajmitch> aha
<SpamapS> ajmitch: they promised "late December", or "at the latest January" when I proposed 5.4.0 at UDS
<ajmitch> the neverending story of php releases, and even then x.y.0 isn't really LTS materiel :)
<SpamapS> well
<SpamapS> promise is a strong word
<SpamapS> they thought they could hit that
<SpamapS> ajmitch: agreed
<SpamapS> It would take a lot to convince me that 5.4.0 will have less regressions than 5.3.10
 * ajmitch should keep 5.4 merged in his PPA
<SpamapS> I fully expect we will ship 5.4 in 12.10
<ajmitch> even if 5.4.0 has no regressions, there are plenty of other packages that it can break
<ajmitch> so mariadb vs mysql might get sorted at UDS?
 * micahg hopes it gets sorted before release
<SpamapS> Heh, its a hot button item. definitely needs wide discussion.
<ajmitch> that'd be preferable, with the 5 year support thing :)
<SpamapS> I had hoped to sort it by today, but I'd rather go the FFE route than jump blindly into something we don't fully understand.
<tmus> What do I need to do, to try to make sure, a specific package is pulled from upstream (debian) into precise? This particular package is not a base/core package, but something that really should be in repo in a modern version... (pmacct - version 0.12.5 - http://packages.debian.org/sid/pmacct)
<SpamapS> tmus: it needs to be merged
<SpamapS> tmus: actually.. it looks like it can be synced
<micahg> tmus: requestsync unless SpamapS is already processing it
<tmus> SpamapS, can I somehow "suggest" such a sync somewhere?
<tmus> micahg, aah, googl'ing requestsync
<SpamapS> tmus: yes there is a program, 'requestsync', that will file a bug
<micahg> tmus: install ubuntu-dev-tools (available in debian as well)
<SpamapS> syncpackage: Request succeeded; you should get an e-mail once it is processed.
<SpamapS> yes, sorry.. next time.. use requestsync. :)
<tmus> SpamapS, Does that mean you requested a sync of it right now? :-)
<SpamapS> alright and with that, I will retire to my tempurpedic
 * micahg wonders if SpamapS can build something that fast
<SpamapS> micahg: pmacct is tiny
<SpamapS> micahg: and the Ubuntu delta was my own, which was applied in Debian. :)
<micahg> heh, previous experience ftw :)
<SpamapS> I should go back through all the libmysqlclient bugs I filed and sync back up
<tmus> awesome! :-)
<SpamapS> anyway, right now, I will retire to the tempurpedic
<tmus> thanks
<SpamapS> tmus: should be available within 60 minutes in precise
<SpamapS> tmus: I stand corrected.. should be available on i386 within 60 minutes in precise ;)
<SpamapS> more like 3 - 4 hours on amd64
<SpamapS> FF always backs up the buildds :-P
<micahg> yeah, someone's hogging a lot of the buildds :)
<infinity> micahg: *stare*
<tmus> SpamapS, perfect... I know of a few minor issues with it - already resolved locally - and communicated upstream. Will it simply be re-sync'ed later on or do I need to file bugs and patches for the ubuntu version as well?
<micahg> :D
 * micahg is actually surprised at the lack of feature freeze uploads
 * micahg will upload aptitude when he wakes up
<ogra_> must be the LTS-nature of this release
<SpamapS> Yeah we're actually trying not to break this one  ;)
<SpamapS> tmus: You will need to use requestsync if things are fixed in Debian
<SpamapS> tmus: auto-syncing will resume after precise is released
<tmus> SpamapS, okay, cool - I'll make sure things are fixed in debian
<tmus> Thanks a lot
<SpamapS> tmus: if Debian can't get them fixed.. then feel free to file a bug w/ a patch in Ubuntu as well, and subscribe ubuntu-sponsors ..
<SpamapS> ok
<SpamapS> sleep
<SpamapS> now
<hrw> yes! finally gcc-4.6 landed in archive
<hrw> time to rebuild cross toolchain
<cjwatson> bdrung: FYI your vlc package (that you were talking about with pitti this morning) fails to build on powerpc; are you already aware of that or do you want the log?
<pitti> cjwatson: I talked to bdrung about it this morning
<pitti> he says the final release will fix it
<cjwatson> I read that discussion, and he said to try a PPA package which should fix it.  I tried it and it didn't.  That's why I'm mentioning it to him
<cjwatson> Looks like missing -maltivec when building the altivec module, possibly.
<valavanisalex> Hi All, I'm planing an update of the Inkscape package to the latest upstream version (the Debian maintainer is inactive).  My issue is that the Debian package uses the now-obsolete dpatch system, and this is giving me a lintian error (not warning).  Do I just ignore the error, or should I convert the package to using quilt?
<cjwatson> It's best not to do major packaging rearrangements as Ubuntu deltas, on the whole
<cjwatson> The purpose of the Lintian error is to encourage Debian maintainers to stop using dpatch
<cjwatson> At this point it's not a big deal for Ubuntu, except in that we'd generally like to reduce the breadth of alternatives in our packaging tools; but not urgent, anyway
<valavanisalex> Great, thanks for the explanation.  I'll just update the upstream component of the package then, and leave the patch system alone.
<mdeslaur> slangasek: dpkg-reconfigure doesn't know about $DPKG_MAINTSCRIPT_ARCH?
<barry> mvo: hi.  have some time today to talk about bug 876298 ?
<ubottu> Launchpad bug 876298 in update-manager (Ubuntu) "[MASTER] We need to better handle external payloads (Flash, msttcorefonts) not being available." [High,Triaged] https://launchpad.net/bugs/876298
<mvo> barry: I have a meeting now, maybe later?
<barry> mvo: devx?  me too (if i can get it to work this time ;).  after would work
<mvo> barry: yeah, devx - its in g+
<barry> mvo: i think i need to be invited.  i don't see it
<mvo> barry: oh, sorry
<Daviey> cjwatson / doko: Please don't scream.. but the experimental python udeb.. still an option?
<Daviey> (^ roaksoax: fyi)
<doko> Daviey, it's in the archive
<Daviey> it is?!  I thought it was still a 'maybe'
<cjwatson> it's only there for python3.2
<cjwatson> rmadison -s precise -S python3.2
<Daviey> ahh
<cjwatson> shouldn't be that hard to use python3 for a new project
<Daviey> cjwatson: right
<doko> bah, the new Xorg with nividia drivers is so unstable ... getting logged out every 2h
<ogra_> doko, use a tegra ;) thats stable nvidia ;)
<apw> cjwatson, i have an initramfs-tools update to include hyper-v modules to allow root to be on paravirualised disks, i am wondering if you might be able to look it over: lp:~apw/ubuntu/precise/initramfs-tools/add-hyper-v-drivers
<cjwatson> apw: looks good to me
<Riddell> TheMuso: I am getting lots of reports of "Failure: Module initalisation failed" on start-pulseaudio-kde, can you check?
<slangasek> mdeslaur: dpkg-reconfigure> correct
<meerkats> what does linux-source synaptic's package do?
<mdeslaur> slangasek: ok, so I have to get rid of $DPKG_MAINTSCRIPT_ARCH in the flash packages then. So...would having the rules file sed a "postinst.in" file with $DEB_BUILD_ARCH be the right way?
<slangasek> mdeslaur: oh bah.  well, it should be DEB_HOST_ARCH
<apw> cjwatson, would you be able to upload that puppy
<mdeslaur> slangasek: why DEB_HOST_ARCH vs DEB_BUILD_ARCH?
<apw> (and thanks for reviewing)
<slangasek> mdeslaur: because of the definitions of host and build in the C standards :)
<cjwatson> mdeslaur: DEB_BUILD_ARCH is the architecture you're building the source package on; DEB_HOST_ARCH is the architecture you're building for.  They differ in the case of cross-compiling
<slangasek> mdeslaur: host is always the arch that the code is hosted on; while it's unlikely anyone will ever need to cross-build a flash package, we should still use the right variable
<m4n1sh> ev: hey
<ev> m4n1sh: hi
<mdeslaur> cjwatson, slangasek: ah! thanks for the explanation, that makes sense
<m4n1sh> ev: you got any update about contributor agreement?
<cjwatson> apw: done
<apw> cjwatson, thanks a lot
<ev> m4n1sh: nothing yet. I'll keep you posted
<m4n1sh> ev: so if I integrate it in alm, then what about the code in whoopsie?
<m4n1sh> duplicated?
<ev> m4n1sh: can you elaborate? I don't follow.
<m4n1sh> means
<m4n1sh> I take those two files
<m4n1sh> and integrate it
<m4n1sh> then this functionality is in two pakages
<m4n1sh> *packages
<m4n1sh> are you going to disable that in whoopsie?
<m4n1sh> ev: is whoopsie going to be enabled by default? right?
<ev> m4n1sh: the idea is that we'll take the preferences page code from whoopsie, put it in a GtkNotebook page in activity-log-manager, and then remove the code from whoopsie.
<m4n1sh> hmmm
<m4n1sh> yeah, I am working on it
<m4n1sh> looks fine
<m4n1sh> it uses gtkbuilder
<ev> m4n1sh: I'm not sure if it falls under the contributor agreement or not yet, and given that today is feature freeze, I'll be doing an upload of whoopsie where the page it creates in GNOME Control Center is called "Diagnostics" rather than its current "Privacy"
<m4n1sh> okay
<m4n1sh> as per Colin this falls outside FF
<ev> indeed
<m4n1sh> so should be fine to move it from one to other
<m4n1sh> so it is in main?
<ev> it will be by the end of the day
<m4n1sh> okay
<pitti> ev: hm, does 'test/run local' work for you in your whoopsie apport branch?
<pitti> ev: I get a ton of errors in apport/ui
<pitti> ev: 'NoneType' object has no attribute '__getitem__'
<ev> eep
<ev> I had been running test/{gtk,kde} manually
<apw> yay ... unity now rendering the archive uninstallable
<davidcalle> Hi everyone, I'm looking for an archive admin to look at two new packages in the universe queue.
<ev> will fix now
<pitti> ev: thanks; reviewing in the meantime
<ev> cheers
<pitti> ev: I need to run out in about 10 mins, I'd rather finish this tomorrow morning than crowbaring it in today
<pitti> skaet: ^ if that's alright with you
<pitti> skaet: (these are the apport GUI and logic changes for whoopsie)
<ev> pitti: sure thing
<pitti> ev: I'll test this locally in the meantime
<ev> cheers
<skaet> pitti, ev =1
<rbasak> I have a line that creates a .so with: 'gcc -shared -Wl,-soname=lib$$i-openmpi.so.1 -o lib$$i-openmpi.so.1.1 -L/usr/lib/openmpi/lib/ -lmpi -lmpi_f77 $$(find tmp -name "*.o")'. The generated .so does not declare dependencies on libmpi and libmpi_f77. I know order matters, so I tried moving the -l's to the front, and also tried -Wl,-E. What am I doing wrong?
<ev> pitti: weird. I only get two failures in ./test/run local. Both relate to add_gdb_info: readelf: Error: /tmp/core: Failed to read file's magic number.
<pitti> ev: hmm, weird; I'll have a look at this tomorrow morning then
<ev> pitti: cheers
<ev> FWIW, I just did a bzr export /tmp/apport-whoopsie; ./setup.py build; ./tests/run local and it worked just fine (well, with the same two errors)
<pitti> ev: I followed up to the MP with various bugs
<ev> pitti: okay, reviewing now
<pitti> I'll look at the ui.py test crash tomorrow then
<pitti> need to run now, sorry (theater tonight)
<doko> Calculating upgrade... Done
<doko> The following packages will be REMOVED:
<doko>   unity
<doko> \o/
<didrocks> doko: this is what happen with ABI breakage and correctly handled packaging to prevent you partial upgrade
<didrocks> doko: rmadison tells that 5.2.0-0ubuntu5 is published now
<doko> didrocks, no, this is when you assume features are implemented in Debian, but not in Launchpad, and not working around these
<didrocks> doko: do you prefer I don't break on older version and let people upgrade at a bad time?
<didrocks> so that they start with the new compiz and unity fail to load?
<seb128> doko, when the compiz abi change unity needs a rebuild, without rebuild it will not start ... what is your issue with the way it's handled?
<doko> well, removing unity will make the system unusable as well?
<seb128> well, it's an apt bug
<seb128> it should put compiz on hold
<seb128> not remove unity
<cjwatson> IWBNI somebody could encapsulate this situation in an apt integration test case
<cjwatson> they're not that hard to write if you can work out what exact dependency relationships trigger it
<seb128> cjwatson, do you have any documentation on how to do that? or an example?
<didrocks> cjwatson: maybe I can give it a try (will probably need guidance from where to look at), but will be after UIF
<seb128> I can have a look (not this week though)
<didrocks> or seb128 can :)
<seb128> cjwatson,it's not really a "bug", I guess compiz scores high since it got rdepends and unity lower since it doesn't
<seb128> the way to fix that would be to upload to proposed and pocket copy as it was discussed at UDS I guess
<didrocks> yeah, we definitively should do that, will be way easier
<didrocks> seems for nux -> unity -> unity-2d
<cjwatson> seb128: I found it fairly self-explanatory when I looked in apt/test/integration/
<cjwatson> e.g. test-bug-657695-resolver-breaks-on-virtuals
<seb128> cjwatson, thanks for the pointer
<seb128> in apt's source then ;-)
<cjwatson> yeah
<cjwatson> that test was for http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=657695
<ubottu> Debian bug 657695 in apt "apt: gives up too easily when resolving Breaks of virtual packages" [Normal,Open]
<cjwatson> (I didn't write the test, though I should have done :-) )
<m4n1sh> ev: do I need to copy those .policy, .conf and .service file too?
<m4n1sh> is it for server or preferences client?
<ev> m4n1sh: everything in the preferences directory is required for the whoopsie gnome control center page to function properly
<m4n1sh> ev: I dont think .desktop file is needed
<ev> m4n1sh: everything except that :)
<m4n1sh> ev: I can integrate it easily
<m4n1sh> can you make some minor changes in the codebase?
<ev> m4n1sh: the privileged dbus backend is definitely required though.
<ev> m4n1sh: what's that?
<m4n1sh> whoopsie_daisy_preferences_panel_init contains all the glue code
<m4n1sh> it should be outside
<m4n1sh> and should be invoked from the method
<m4n1sh> otherwise I am not able to understand which is a part of it and which is not
<m4n1sh> part of cc integration and which for whoopsie
<m4n1sh> so that I just have a g_box
<m4n1sh> a method call which will give me GtkBox
<m4n1sh> ev: so that i can put it in the Notebook
<ev> m4n1sh: I'll endeavor to fit that in tomorrow, or at worst, early next week
<ev> quite busy with changes to apport at the moment
<m4n1sh> apport for for bug reporting?
<ev> m4n1sh: yes
<m4n1sh> okay
<m4n1sh> I will try myself
<m4n1sh> I am pretty bad at C
<ev> pitti: found the reason why I wasn't seeing this test failure. ./tests/run exits on the first test failure, which I was getting for those gdb ones. I've fixed this in my branch (but not your other concerns yet).
<lifeless> barry: #launchpad-dev please ;)
<broder> does debian currently support using sysvinit without using insserv?
<broder> (i'm trying to figure out if i can kick bug #884402 back to rra, since our update-rc.d is, in fact, identical to debian's)
<ubottu> Launchpad bug 884402 in shibboleth-sp2 (Ubuntu) "package libapache2-mod-shib2 2.4.3+dfsg-1ubuntu1 failed to install/upgrade: ErrorMessage: subprocess installed post-installation script returned error exit status 1" [Undecided,Confirmed] https://launchpad.net/bugs/884402
<slangasek> broder: only in the sense that sysv-rc is not mandatory
<slangasek> if you have sysv-rc installed, you have insserv installed; but there are still alternatives to it in the Debian archive, such as file-rc
<broder> slangasek: there's a comment in update-rc.d: "[...] upgraded systems might keep the legacy ordering until the sysadm choose to migrate to the new ordering method"
<broder> which makes me think that debian intends to support running without switching to insserv for an arbitrary period of time
<slangasek> oh, yes, you can have insserv installed but not active
<broder> i'm assuming that the shibboleth-sp2 bug would be reproducible on debian if you deactivated insserv, because update-rc.d looks completely self-contained and is identical between debian and ubuntu
<broder> i guess i can test that easily enough
<kelemengabor> hi dobey, do you have a little time to review the merge proposal for bug #856728 ?
<ubottu> Launchpad bug 856728 in Ubuntu Translations "Missing translations (Learn more, Install) in ubuntuone-installer window" [Medium,Triaged] https://launchpad.net/bugs/856728
<kelemengabor> kenvandine: same question to you with bug #926665 :)
<ubottu> Launchpad bug 926665 in Ubuntu Translations "Untranslatable strings in gwibber 3.3.3" [Medium,Triaged] https://launchpad.net/bugs/926665
<kelemengabor> just some trivial i18n fixes
<dobey> kelemengabor: not before 2100Z, so probably not today; but ping me tomorrow
<kelemengabor> will do, thanks!
<stgraber> kirkland: pastebinit 1.3 will ship without your scripts as they're still in bkieshed, let me know when it's no longer the case and I'll update pastebinit
<kirkland> stgraber: k -- i can do that asap today
<kirkland> stgraber: would you be willing to update subsequently?
<stgraber> kirkland: sure, I'm planning the pastebinit 1.3 upload within the next hour or so
<kirkland> stgraber: okay, give me a moment ...
<kirkland> stgraber: where can I find your code to make sure the current functionality is identical?
<stgraber> kirkland: lp:pastebinit
<kirkland> stgraber: 18579bab7d17780bcceae23b8b7dd01d  pbput
<stgraber> kirkland: doesn't match :(
<kirkland> stgraber: let me diff
<kirkland> stgraber: okay, looks good;  changes are http://paste.ubuntu.com/844801/
<kirkland> stgraber: ie, license only changes
<stgraber> kirkland: ok, good
<kirkland> stgraber: changes committed;  i'm releasing and pushing right now
<kirkland> stgraber: bikeshed 1.21 no longer contains pbput/pbget
<stgraber> kirkland: perfect
<kirkland> stgraber: uploaded
<kirkland> stgraber: thanks!!!
<stgraber> np, sorry it took so long ;)
<slangasek> broder: followed up on the update-rc.d bug; shibboleth is plainly invoking it wrong
<Laibsch> ping stgraber
<stgraber> Laibsch: hey!
<Laibsch> I'm almost dying, but I'm preparing another upload
<stgraber> Laibsch: awesome, thanks!
<Laibsch> what version is the last bikeshed package?
<stgraber> Laibsch: kirkland just uploaded bikeshed 1.21
<Laibsch> OK
<Laibsch> I'll conflict with anything before that
<stgraber> sounds good
<Laibsch> I'll pastebin a diff, I'm too tired to deliver quality
<Laibsch> stgraber: http://paste.debian.net/156526/ is what I'm thinking about (with proper changelog, of course)
<Laibsch> will compile now and see if the result is as expected
<stgraber> Laibsch: diff looks good (haven't tried it though)
<Laibsch> alright
<Laibsch> the scripts currently end up in /usr/bin/utils
<Laibsch> which is not the intention
<stgraber> utils/* usr/bin then
<Laibsch> yeah, I guess
<Laibsch> but not sure
<Laibsch> 25 or 85 minutes left?
<stgraber> Laibsch: 85
<stgraber> Laibsch: let me know when it's in incoming as it'll need manual syncing from there
<Laibsch> sure
<Laibsch> I'm still fixing some minor issues
<slangasek> SpamapS: does bug #933566 ring any bells with you (upstart job with no main process, fails to run pre-stop script)?
<ubottu> Launchpad bug 933566 in resolvconf (Ubuntu) "Stopping resolvconf doesn't disable updates" [Undecided,New] https://launchpad.net/bugs/933566
<Laibsch> stgraber: can you grab from incoming or is there a chance you might not get the upload in time?
<SpamapS> slangasek: restart and pre-stop do not play nicely.. hmm.. reading
<Laibsch> maybe I should provide you with a debdiff to current testing just in case
<slangasek> SpamapS: yeah, this isn't restart, just stopping
<stgraber> Laibsch: I'll grab from incoming and push manually. Debdiff works too.
<Laibsch> unstable package is building now
<SpamapS> slangasek: very strange. I'd love to see the full syslog from an affected box at shutdown.
<om26er> Is there a way to know how many packages I got sponsored to Ubuntu archives?
<slangasek> SpamapS: well, this is the only job on my system that uses pre-stop+pre-start w/o a main process, so I'm not sure there's anything to compare it with
<broder> om26er: you can look at https://launchpad.net/~broder/+uploaded-packages and https://launchpad.net/~broder/+synchronised-packages (substitute your lp id as necessary)
<slangasek> or just use /~/
<broder> oh right, i always forget about that
<om26er_> broder, ah, great thanks :)
<broder> om26er_: that list may not be complete - it will only list uploads where your name was at the end of the changelog entry. sometimes sponsors will re-sign the changelog if they make extensive changes before uploading
<broder> so if you know there are cases where that happened, you'll need to keep track of them yourself
<om26er_> that have happened on rare occasions but I'll keep track. thx
<micahg> om26er_: http://ubuntu-dev.alioth.debian.org/cgi-bin/ubuntu-sponsorships.cgi
<broder> slangasek: Bear in mind that dbus is not running on servers by default> uh, i don't think that's been true for a very long time
<slangasek> broder: really?
<broder> i thought the default install had included dbus since the lucid era or so
<slangasek> hmmm
<slangasek> it's in task: standard, which I suppose might do it
<Laibsch> stgraber: got disconnected, but upload is finished now.  good night.
<stgraber> Laibsch: thanks!
<stgraber> Laibsch: will wait for it to show up on incoming and will grab it from there.
<micahg> stgraber: it's there
<stgraber> micahg: I'm waiting for -2
<micahg> ah :)
<slangasek> SpamapS: interesting report of nfs mounts not working reliably, fwiw: bug #933575
<ubottu> Launchpad bug 933575 in nfs-utils (Ubuntu) "NFS not being mounted at boot time - rpc.statd is not running but is required for remote locking" [Undecided,Incomplete] https://launchpad.net/bugs/933575
 * TorpedoSkyline weeps at the departure of jono
<highvoltage> TorpedoSkyline: hmm?
<TorpedoSkyline> highvoltage: jono left the chatroom.
<TorpedoSkyline> I always liked jono. I'd like to talk to him next time he comes on.
<TorpedoSkyline> that was weird.
<EtienneG> quick question about isc-dhcp (slangasek, perhaps?): I see we are on 4.1.1 in precise, while Debian unstable is on 4.2.2.  Are we staying on 4.1.x in the LTS to benefit from 4.1 being an "ESV"?  (http://www.isc.org/software/dhcp/versions)
<EtienneG> ESV == Extended Supported Version, in ISC parlance
<slangasek> EtienneG: I don't believe it was an explicit decision; we're on 4.1.1 because that's the latest version in Debian testing
<slangasek> and for the LTS we sync from testing, not unstable
<EtienneG> slangasek, fair enough.  Someone pointed out to me that we where "behind" in term of isc-dhcp, but I guess it make most sense to stick to the ISV "ESV" release
<stgraber> Daviey: speaking of isc-dhcp-server, what's the status of the work item to get it upstartified with a job for dhcp4 and one for dhcp6?
<slangasek> stgraber: ^^ have you put any thought into isc-dhcp 4.2 for precise?  I think you may have mentioned it before but I don't remember the context
<slangasek> right, dhcp6 server, that would've been it ;)
<stgraber> slangasek: I only had a quick look at the isc-dhcp version, but 4.1 looked good because of ESV and it wasn't clear what would be the benefit of 4.2 (except for the nightmare of getting it to build + apparmor + ...)
<Daviey> stgraber: untouched.
<slangasek> stgraber: ok
<stgraber> Daviey: will you have it done for 12.04?
<Daviey> stgraber: i hope so, but the whole team are currently cooking way over capacity
<Daviey> which means the best i can say is 'maybe', not a commitment at this stage
<slangasek> bladernr_: hi, can we talk about bug #933723?
<ubottu> Launchpad bug 933723 in resolvconf (Ubuntu) "resolvconf creating bogus resolv.conf file" [Undecided,New] https://launchpad.net/bugs/933723
<stgraber> Daviey: ok, should I still the work item then?
<stgraber> Daviey: *steal
<bladernr_> slangasek:  sure
<slangasek> bladernr_: do you see this 127.0.0.1/example.org somewhere under /run/resolvconf?
<slangasek> if so, what file / can you pastebin it for me
<Daviey> stgraber: If you did, you'd earn beer tokens
<bladernr_> slangasek:  http://pastebin.ubuntu.com/844946/
<bladernr_> looks like it's actually pulled in interface/lo.named
<bladernr_> :/
<bladernr_> hrmmm
<slangasek> bladernr_: right, so you've got bind9 installed and running and hooking itself into resolvconf
<slangasek> not a resolvconf bug ;)
<bladernr_> apparently so...
<slangasek> but I think by default, bind9 is supposed to *not* do resolvconf
<bladernr_> and about as soon as I started catting files in run I realized that
<bladernr_> hehe
<bladernr_> that's good then... that means perhaps this is easily solvable on our end... just gotta figure out why bind is being installed
<bladernr_> slangasek:  sorry to alarm you :)
<slangasek> bladernr_: n/p - is it actually breaking name resolution, btw?
<slangasek> I think the bug should probably be reassigned to bind9
<bladernr_> well, we don't actually USE bind
<bladernr_> I'm not sure why it's being installed
<slangasek> because if bind9's not working as a local resolver out of the box, the default value for the bind9/run-resolvconf template should be fixed
<bladernr_> ugh... thi smeans there like 50+ machines in the lab all running their own nameservers
<bladernr_> oh, well yes
<bladernr_> to answer THAT question...
<slangasek> nothing so wrong with running a caching-only nameserver as long as it works ;)
<bladernr_> BUT, we're not configuring bind, so that may not really be a problem with bind iether
<slangasek> bladernr_: so hostname resolution *is* broken?
<bladernr_> well... define broken... as I said, bind is being installed but we're not actually configuring or doing anythihng with it.
<slangasek> I'm asking you if host lookups work
<bladernr_> that being said, we get NO resolution with the resolvconf including 127.0.0.1
<bladernr_> no
<slangasek> ok
<slangasek> then bind9 is broken out of the box and mustn't hook into resolvconf by default
<bladernr_> so as soon as I purged bind9, resolv.conf was re-written and now includes the working nameserver line from eth0
<bladernr_> also...
<broder> bladernr_, slangasek: err, i've used bind9 as a local resolver out of box
<broder> is this a policy-rc.d-at-install-time interaction?
<slangasek> bladernr_: are there firewalls blocking bind from forwarding DNS requests to arbitrary DNS servers on the internets?
<slangasek> broder: no, because bind9 *only* hooks into resolvconf *from* its init script :)
<broder> slangasek: ok, good. that's what i suspected, but didn't have the code in front of me yet
<bladernr_> slangasek:  you have now exhausted my DNS vocabulary and ability :(
<slangasek> bladernr_: is there a firewall ;)
<bladernr_> we have no firewalls on the machines...
<bladernr_> :)
<bladernr_> heh
<slangasek> bladernr_: bind9 *should* work without further configuration; however, it will fail to do so if it can't actually reach port 53 on the public internet
<slangasek> bladernr_: yes, but is there a fw for the lab as a whole
<bladernr_> yeah, just thought about that...
<bladernr_> because we're pointing servers to the satellite as the nameserver, that could well be the case then.
<bladernr_> sorry for being dense
<barry> Riddell, ScottK: any thoughts on these build failures?  they don't fail for me locally.  build skew perhaps?  https://launchpad.net/ubuntu/+source/telepathy-qt4/0.9.0+repack-0ubuntu2
<jtaylor> barry: in -packaging a django dev wants to talk about django 1.4 in precise, you had some uploads of it maybe you want to speak to him
<Riddell> barry: I added test coverage cos mterry demanded it to feel warm and fuzzy, it works for me locally too but it seems to need an LD_LIBRARY_PATH set to keep it happy in soyuz
<Riddell> I can look at it tomorrow or feel free to fix it
<barry> virtualenv 1.7.1 was just released.  i'm thinking about upgrading our 1.7-1 to it.  any objections
<Riddell> it's cdbs which I seem to have lost the nack of a bit
<mterry> Riddell, it's cold in Massachusetts!  Tests keep me warm
<Riddell> yeah you need something to keep your CPUs busy to keep the room temperature up I get you
<barry> Riddell: i can take a look.  if you don't see an upload fixing it today, you'll know i failed miserably :)
<Riddell> thanks barry
<chrisccoulson> mterry, it seems like you should try building webkit. that would definitely keep you nice and warm
<chrisccoulson> ask seb128 about that, he's our webkit expert now ;)
<mterry> chrisccoulson, no way.  I'm worried if I bring it up, he'll be like "you like webkit?  it's yours"
<seb128> chrisccoulson, did mterry just volunteered to maintain webkit?
<seb128> \o/
<mterry> fuck
<chrisccoulson> heh
<seb128> lol
<stgraber> kirkland: new pastebinit for you ;) enjoy!
<kirkland> stgraber: cheers mate
<kirkland> stgraber: one question for you...
<stgraber> kirkland: sure
<kirkland> stgraber: do you publish ppa builds of pastebinit for older ubuntu releases?
<kirkland> stgraber: ie, i always simultaneously push my projects (bikeshed included) to a ppa for all supported ubuntu releases
<kirkland> stgraber: and some of my users track those
<kirkland> stgraber: so someone who's running, 10.04, say, that's tracking my bikeshed ppa
<kirkland> stgraber: will update tomorrow, and actually lose pbput/pbget
<stgraber> kirkland: nope, I usually release once a year or every two years, never bothered setting up a PPA for it ;) (I do for most of my other projects though)
<stgraber> kirkland: I guess pastebinit would be interesting to backport though if there's interest
<kirkland> stgraber: okay, i'll push a copy of pastebinit sources to the ppa:bikeshed/ppa
<kirkland> stgraber: yeah, if you had one already in a ppa, I'd just pocket copy it
<stgraber> kirkland: ok, sounds good, make sure you remove the dh_python2 stuff though as it won't work on lucid
<micahg> kirkland: stgraber: pastebinit seems like a good candidate for backports
<kirkland> stgraber: if not, I'll just upload
<kirkland> stgraber: nah, i'll just set my ppa's builds to backports ;-)
<stgraber> kirkland: won't work, dh_python2 isn't even in lucid backports ;)
<kirkland> stgraber: oh
<kirkland> stgraber: shucks
<stgraber> micahg: yep, I'm really surprised nobody did it already, I guess people are happy with the default pastebin and don't need the new stuff :)
<TorpedoSkyline> when does hardy die?
<tumbleweed> TorpedoSkyline: http://wiki.ubuntu.com/Releases
<TorpedoSkyline> thx tumbleweed
<dobey> barry: ping; why does python-dbus depend on python-dbus-dev?
<barry> dobey: from the control file:
<barry> # Depends on python-dbus-dev for backwards compatibility, until packages
<barry> # are fixed to depend on that directly
<barry>  
<dobey> boo.
<barry> dobey: could you file a bug here: http://bugs.debian.org/cgi-bin/pkgreport.cgi?package=dbus-python
<dobey> i guess i should just run reportbug or something. that web page is confusing
<barry> reportbug -B debian i think does it (but i have to look at the manpage every time)
<dobey> i guess i have to tell it that it doesn't have direct internet access or something. eh, i don't really feel like dealing with configuring a bug reporting tool to be able to report a bug, right now :-/
<cjwatson> or just use the mail interface, takes a few minutes to learn :)
<cjwatson> submit@bugs.debian.org with body "Package: dbus-python" / "Version: ITS-VERSION-NUMBER" / blank line / your report
 * dobey prefers apport
<cjwatson> which is fine but I just told you how to work this one in one line of IRC
<cjwatson> so, not *that* hard
<dobey> i'm not saying it's hard
<dobey> i'm saying it's work :)
* ChanServ changed the topic of #ubuntu-devel to: Precise Feature Freeze in effect.  Archive: open | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #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:
<ScottK> dobey and barry: There's no need to file a bug with dbus-python.  The maintainer's well aware.
<sabdfl> congrats on FF folks
<RAOF> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Precise Feature Freeze in effect.  Archive: open | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #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: RAOF
<bdrung> cjwatson: can you provide a build log for the stable-daily vlc package?
<barry> ScottK: cool
<andy753421> Is there a naming convention that I should follow for having the a package for different ubuntu versions in a ppa?
<andy753421> I'm thinking something like mypackage_0.7-1ppa1.11.10.dsc and mypackage_0.7-1ppa1.12.04.dsc or something?
<infinity> andy753421: If you want 0.7-1 to be higher, then you want 0.7-1~ppa...
<infinity> andy753421: But tacking the release version on the end is a reasonable way to keep them in a sane order, sure.
#ubuntu-devel 2012-02-17
<mwhudson> is this a good place to ask upstart questions?
<slangasek> yes, though not the ideal time :)
<mwhudson> i guess that
<mwhudson> slangasek: do you know things about job instances?
<slangasek> yes
<mwhudson> so we have a lava-instance job that has
<mwhudson> instance $LAVA_INSTANCE
<mwhudson> and lava-instance-uwsgi that has
<mwhudson> instance $LAVA_INSTANCE
<mwhudson> start on starting lava-instance
<mwhudson> stop on stopping lava-instance
<mwhudson> when we do start lava-instance LAVA_INSTANCE=foo a lava-instance-uwsgi instance with LAVA_INSTANCE=foo is started
<mwhudson> when we do stop lava-instance LAVA_INSTANCE=anything, all lava-instance-uwsgi jobs stop
<slangasek> hmm, really?
<mwhudson> i guess this isn't so surprising, and we should say stop on stopping lava-instance LAVA_INSTANCE=$LAVA_INSTANCE ?
<slangasek> oh
<mwhudson> slangasek: well, that's what seems to happen
<slangasek> try 'stop lava-instance anything' instead
<mwhudson> uh really?
<slangasek> IIRC yes
<mwhudson> stop: Env must be KEY=VALUE pairs
<slangasek> oh, n/m, I think I see the issue
<slangasek> lava-instance-uwsgi should be
<slangasek> stop on stopping lava-instance LAVA_INSTANCE=$LAVA_INSTANCE
<mwhudson> ok
<mwhudson> thats what i was leaning towards suspecting
<mwhudson> or something like that
<mwhudson> slangasek: it's slightly funny that the instance-ness propagates 'down'
<mwhudson> but i guess that's because there are really environment variables involved here?
<slangasek> yes, there are
<slangasek> well, at some stages ;)
<slangasek> at other stages it's just key,value pairs being passed in a dbus call
<mwhudson> and when you do start on starting <mumble>, you inherit the env mumble starts in?
<slangasek> hmm, not entirely... I think init(5) explains the various idiosyncracies
<slangasek> sorry, afk now :)
<mwhudson> ok
<mwhudson> ahah
<mwhudson> we also have
<mwhudson> export LAVA_INSTANCE
<mwhudson> in lava-instance
<mwhudson> the murk parts, slightly
<RAOF> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Precise Feature Freeze in effect.  Archive: open | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #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:
<mwhudson> argl bargl
<slangasek> broder: http://paste.ubuntu.com/844050/ looks good to me for sysvinit, yes
<broder> slangasek: ok, cool. i'll go ahead and upload it
<broder> and i'll start working on the srus for that as well
<slangasek> broder: thanks :)
<broder> thanks for the review
<broder> slangasek: oh, hmm. is there any way for me to ensure that the sysvinit update gets taken after the insserv update? i could do a breaks, but that wouldn't technically prohibit, e.g., not-fixed-oneiric insserv + fixed-natty sysvinit
<micahg> why wouldn't sysvinit breaks << fixed precise insserv prevent oneiric insserv + precise sysvinit/
<broder> it would, but i also need to sru this fix to lucid through precise, inclusive
<slangasek> broder: you could breaks: insserv (<< 1.14.0-2ubuntu1), insserv (= 1.14.0-2.1)
<broder> ooh, breaks with an =. never thought of that
<slangasek> although breaks doesn't actually require the broken insserv to be /removed/, just /deconfigured/, so it is technically possible to still get breakage after initscripts has been upgraded
<micahg> well, seemingly, each release gets its proper breaks (is there any problem with insserv getting upgraded before sysvinit on dist-upgrade?
<slangasek> if necessary, we could have initscripts use a versioned depends on insserv; initscripts already depends on sysv-rc | file-rc and sysv-rc depends on insserv and file-rc isn't actually installable in Ubuntu because upstart depends on sysv-rc
<slangasek> so it wouldn't break the world to have initscripts depend on insserv directly
<slangasek> micahg: the problem is that the old insserv breaks things and the new initscripts tries to clean it up... we don't want to leave insserv in a position to break things again and force us to do /another/ round of srus to clean up
<broder> so what would i do in that case? oneiric's initscripts would depend: insserv (>= 1.14.0-2.1ubuntu1) | insserv (= 1.14.0-2.1ubuntu0.1) ?
<broder> and then i keep adding disjunctions as i go further back?
<slangasek> yeah
<slangasek> fugly, innit :)
<broder> yeah...
<rectec> Is there any way I can check the HUD's development? Like its stages? (Alpha, beta, etc.)
<broder> slangasek: we could survive without that dependency in precise, right? which at least means that the fugliness is temporary?
<micahg> that would also couple any other insserv SRU with an initscripts upload
<slangasek> broder: yes, for precise I think it's fine to drop the disjunctions
<pitti> Good morning
<slangasek> micahg: this is the only time we've done an insserv SRU to date
 * slangasek waves to pitti
<pitti> yay empty precise_probs \o/
<pitti> and that at FF time
<micahg> pitti: new glib-networking broke ia32-libs, I subscribed you to the bug, needs multiarching
<micahg> err..deps need multiarching
<pitti> micahg: for libproxy? I thought that already was
<pitti> micahg: thanks, will have a look
<micahg> yeah
<micahg> libproxy's deps I think
<broder> slangasek: ok. well, for starters, would you mind rejecting the oneiric initscripts i just uploaded?
<broder> err, sysvinit that is, of course
<pitti> micahg: ah, libjavascriptcoregtk-1.0-0
<slangasek> broder: done
<pitti> i. e. webkit
<pitti> micahg: acually, I'd rather not have it depend on that in the first place, it's rather big
<pitti> will ask Laney about it when he comes online
<micahg> sounds good
<broder> slangasek: and you think the depends is the best option here?
<slangasek> broder: I think it's the safest option that's most certain to kill this bug dead
<broder> slangasek: do you think it's an acceptable risk that this would break users who have their own insserv (e.g. from a ppa) installed?
<slangasek> heh
<slangasek> yes
<slangasek> worst case, they need to either rev their ppa build of insserv, or do a ppa build of sysvinit with it
<broder> slangasek: ok, really bad idea: have initscripts trigger on /usr/lib/insserv?
<slangasek> yuck :)
<broder> but...i think it would work, no?
<slangasek> I can see a couple ways that could be made to work; none of them appeal to me
<slangasek> why do anything with a trigger that could be expressed as a declarative package relationship
<broder> because the declarative syntax only lets me express an approximation of what i'm really trying to say?
<slangasek> ok, but suppose the user upgrades insserv to a version (local or otherwise) that doesn't include /usr/lib/insserv
<slangasek> this may or may not trigger
<slangasek> and it may or may not result in insserv being run and breaking things again afterwards
<broder> we could clean up the rc*.d links in the initscripts upgrade case and the trigger case
<slangasek> yes
<slangasek> but the point at which things get *broken* again is when $random_other_thing calls insserv
<slangasek> and there's no way to ensure the postinst is called at that point to fix it up
<broder> but that's still a problem with the dependency plan
<slangasek> how?
<slangasek> the only versions satisfying the dependency are ones that have moved insserv off the path
<broder> unless it moves back into the path in the future, which i thought was what you were worried about
<slangasek> broder: I'm not worried about it moving back into the path in an *archive* version
<slangasek> but a *ppa* version could be doing the wrong thing
<slangasek> hmm, let me check if that makes sense
<slangasek> nah, I officially don't care about any broken versions of insserv packages in anyone's ppa
<slangasek> what if the user installs the initscripts SRU but not the insserv one though?
<broder> with the dependency approach, they can't
<slangasek> are you doing the dependencies?
<broder> with the triggers approach, they're still screwed until they get the insserv update, but when they do, it'll be cleaned up
<slangasek> I thought that's what you were trying to talk me out of
<slangasek> right
<broder> i'm currently banging my head against a table trying to keep all of this straight :)
<broder> but not yet writing any code
<slangasek> I would prefer to deliver an SRU that forces the upgrade to a good version of insserv immediately, so that their shutdown is un-screwed and stays that way
<broder> ok. i think that seems right
<slangasek> ok
<slangasek> fwiw I wouldn't reject either approach if uploaded
<slangasek> I also wouldn't accept them at the moment, because I'm headed for bed ;)
<pitti> micahg: uploaded a fixed libproxy which drops the webkit dependency FYI, I updated bug 933913
<ubottu> Launchpad bug 933913 in libproxy (Ubuntu) "libjavascriptcoregtk-1.0-0, libicu48 need to be multiarched" [Undecided,In progress] https://launchpad.net/bugs/933913
<micahg> pitti: great, thanks
<rickspencer3> pitti, nice to wake up to a beer this morning! http://people.canonical.com/~ubuntu-archive/testing/precise_probs.html
<pitti> rickspencer3: indeed!
<pitti> rickspencer3: we got new armel panda buildds yesterday, they nicely managed to catch up with the backlog
<pitti> and compiz fixed
<rickspencer3> yeah!
<rickspencer3> pitti, looks like the server smoke tests are in less good shape
 * rickspencer3 braces for the desktop tests to run
<pitti> rickspencer3: these look odd; maybe the same QA lab problem that didrocks was experiencing with his unity mergers?
<pitti> error: internal error process exited while connecting to monitor: libvir: error : cannot execute binary /usr/local/bin/kvm: Permission denied
<pitti> err
<didrocks> no, doesn't seem the same issue
<pitti> rickspencer3: so, once the alternates and desktops build, that'll hit them as well
<rickspencer3> oops, looks like a lab issue, indeed
<didrocks> (it was a network one)
<pitti> didrocks: right, sorry; should have checked logs before
<pitti> jibel: ^ halp
<didrocks> no worry :)
<rickspencer3> day after FF, bad luck!
<rickspencer3> pitti, did 10.04.4 go out as expected?
<pitti> rickspencer3: yes, it's out and announced
<rickspencer3> sweet!
<rickspencer3> big day yesterday
<pitti> http://releases.ubuntu.com/10.04.4/
<pitti> http://releases.ubuntu.com/kubuntu/10.04.4/, too
<dholbach> good morning
 * pitti hugs dholbach
 * dholbach hugs pitti back
<rickspencer3> morning dholbach
<dholbach> hey rickspencer3
<pitti> Riddell, debfx_: hmm, kubuntu-docs wants to go to universe; is that intended?
<jibel> pitti, good morning
<pitti> bonjour jibel
<jibel> pitti, permission denied on kvm in the lab. that's weird.
<pitti> YokoZar: indeed, http://people.canonical.com/~ubuntu-archive/nbs.html now has dssi-vst which needs to change its b-dep to wine1.4
<YokoZar> pitti: Aye, I'll get it right after I get this wine1.4 upload going.
<dholbach> does anybody else have issues with thunderbird too?
<dholbach> as in widgets being completely empty?
<micahg> dholbach: bug 933951
<ubottu> Launchpad bug 933951 in thunderbird (Ubuntu Precise) "Messaging menu extension interacts badly with lightning in precise making thunderbird unusable" [High,Triaged] https://launchpad.net/bugs/933951
<dholbach> ah, thanks micahg
<sabdfl> it's a real friday when you don't have to cram as much email as possible in between conversations
<sabdfl> thanks, somebody :)
<dholbach> haha, thanks sabdfl :)
<dholbach> luckily it's easy to workaround it
<Riddell> pitti: kubuntu-docs rescued
<pitti> cheers
<pitti> cjwatson: any opinion on https://bugs.launchpad.net/ubuntu/+source/kickseed/+bug/810068/comments/13 ? I'm inclined to just reject the maverick-proposed uploads; we had enough trouble verifying this for lucid already
<ubottu> Launchpad bug 810068 in partman-iscsi (Ubuntu Maverick) "kickstart iscsi option broken" [High,In progress]
<Laney> pitti: it would have been OK were that still a module
<Laney> but I think disabling mozjs stops that being so
<pitti> Laney: this probably needs to be split into several source packages at some point?
<Laney> why source packages?
<Laney> having them in separate binaries was alright wasn't it?
<pitti> Laney: you can't build-dep on universe packages, though
<Laney> it would be good to disable mozjs and have webkit still be a plugin
<pitti> i. e. if we want the mozjs plugin in universe, it needs to be in an universe source package
<pitti> Laney: yes, but webkit doesn't build without mozjs apparently
<pitti> when I disabled mozjs, webkit wasn't built
<Laney> it was
<Laney> it's just a part of the main package now
<pitti> ah; could this be split out again somehow?
<Laney> I think â let me check
<pitti> pulling in an extra > 1 MB package just for this seems a little exaggerated
<pitti> having it in the plugin would be fine
<pitti> also, we shoudl check whether it builds against libwebkitgtk-3.0-dev
<Laney> for ubunt2 we had " * pacrunner_webkit"
<Laney> i.e. webkit is builtin
<Laney> I'm pretty sure it has webkit3 support
<pitti> ok, SRU queues processed as much as possible
<Laney> next week I'll speak to upstream about the module thing
<pitti> thanks
<Laney> or â¦ actually, see libproxy/cmake/modules.cmk:21
<jamespage> any archive admins around?  I'm reviewing a proposed new package (see bug 930422) and wanted a second opinion on what they are doing with qtrpc2
<ubottu> Launchpad bug 930422 in Ubuntu "[needs-packaging] rds Resara Server" [Wishlist,New] https://launchpad.net/bugs/930422
<Laney> pitti: bug #934088
<ubottu> Launchpad bug 934088 in libproxy (Ubuntu) "Re-enable webkit plugin as a module (and build against webkit3)" [Undecided,New] https://launchpad.net/bugs/934088
<micahg> pitti: did you see my ping before?
<pitti> micahg: only the one about libproxy
<micahg> pitti: can you please copy firefox/lucid-oneiric from ubuntu-mozilla-security to $RELEASE-security?
<pitti> Laney: sweet, thanks! sponsoring
<pitti> micahg: uh, not in backscroll; weird
<Laney> cheers!
<pitti> micahg: sure, doing
<micahg> pitti: I've been having IRC issues, I'm hoping after I dist-upgrade they'll go away :)
<smb> optimism seems to die last... :-P
<pitti> micahg: done
<micahg> pitti: thanks
<hrw> ~curse thunderbird
<micahg> hrw: fix already uploaded and buidling
<hrw> micahg: cool
<hrw> time to run dget - will be faster then waiting for archive
<hrw> micahg: can TB be built in 7GB of disk space?
 * micahg checks
<micahg> hrw: umm, cutting it very clsoe
<hrw> hope it will fit - 7GB is my pbuilder tmpfs
<micahg> oh, on armhf it's less
<RAOF> hrw: Someone has too much ram!
<hrw> RAOF: 16GB was <100â¬ so why bother with 8GB :D
<RAOF> Fair call!
<hrw> RAOF: when 8GB DDR3 sticks will be around price of 2x4GB DDR3 I will consider 16->24/32GB
<RAOF> Yeah, I guess I could build a desktop... :)
<pitti> hrw: "swap? what is that?"
<hrw> pitti: can you speak english? :)
<hrw> pitti: with low price of ram I do not see sense in having swap
<pitti> err -- WTH
<pitti> all my copying of kernels to -proposed were just silently forgotten by LP
<pitti> ah, no, seems just the publisher is veeery behind
<cjwatson> bdrung: http://paste.ubuntu.com/845621/
<cjwatson> pitti: maverick> I guess; I was just uploading it for everything without especially thinking about it, really
<karel_ff> According to omgubuntu (http://goo.gl/vXnPf) the sun java packages were going to be pulled from the partner repos yesterday.
<karel_ff> It appears they're still there for natty. Can anyone enlighten me if they are going to be removed there as well?
<pitti> go, ev, go!
<ev> haha
<hrw> micahg: thx - ubuntu3 tb package works
<micahg> hrw: chrisccoulson fixed it
<debfx> could someone please close https://code.launchpad.net/~marcelstimberg/ubuntu/precise/scribus/merge-1.4-from-debian/+merge/92623
<hrw> chrisccoulson: thx for fix
<debfx> a newer version has already been merged, see bug #930639
<ubottu> Launchpad bug 930639 in scribus (Ubuntu) "Please merge scribus 1.4.0.dfsg+r17287-1 (main) from Debian sid (main)" [Undecided,Invalid] https://launchpad.net/bugs/930639
<hrw> micahg: and you confirmed that this version will work
<chrisccoulson> doko_, you around?
 * TorpedoSkyline thinks doko_ disappeared.
<mdeslaur> bdmurray: sorry, the oneiric update-manager security update superseded your package in -proposed...
<doko> chrisccoulson, yes, what's the issue?
<chrisccoulson> doko - i could use some help on https://bugzilla.mozilla.org/show_bug.cgi?id=694594 :)
<ubottu> Mozilla bug 694594 in JavaScript Engine "Crashes with gcc 4.4.3" [Critical,New: ]
<doko> chrisccoulson, that's what you get when backporting new upstream versions :-/
<chrisccoulson> heh
<doko> chrisccoulson, did you test vanilla 4.4.6, or the Ubuntu packages? does 4.5.x work?
<chrisccoulson> doko, i tested the ubuntu 4.4.6 package. i've not tested a vanilla gcc yet
<chrisccoulson> 4.5.x seems to work though
<doko> note that there are backports for lucid in the ubuntu-toolchain-r/test repository, and in ubuntu-toolchain-r/ppa for gcc-4.4
<chrisccoulson> at least, we don't get any crashes from builds that are built with 4.5 :)
<doko> ok, but maybe not an option or the upload
<chrisccoulson> thanks, i'll try a vanilla build too
<doko> chrisccoulson, from the bug report I understand that you can work-around the issue?
<chrisccoulson> doko, sort of. it's not a good long term solution, as this code is pretty performance optimized. and there's no guarantee that we don't see the same problem in other places too
<doko> understood
<doko> bdmurray, 933946 was closed with the wrong text (talking about apport, while it's a corrupt archive)
<zumbi> hello, base-files fails to install on precise, when /var/run is not empty dir, there is a patch attached to a BR, is there something special that needs doing to get this applied? (BR: https://bugs.launchpad.net/ubuntu/+source/multistrap/+bug/874505)
<ubottu> Launchpad bug 874505 in multistrap (Ubuntu) "Native Multistrap oneiric chroots have an error configuring base-files" [Undecided,Confirmed]
<roadmr> zumbi: looks like  it needs to be reviewed, I see the review team is already subscribed so it should get some attention soon
<zumbi> roadmr: ah! thanks
<pitti> Riddell: ah, has there been a decision for telepathy-KDE now?
<pitti> Riddell: (I'm just curious)
<pitti> I read your blog a few days ago, and it didn't seem obvious which one was better
<Riddell> pitti: not yet, I'm still a fan of telepathy-KDE because it's maintained but others are more cautious for the LTS.  It might come down to whether we can convince upstream to add message indicator integration :)
<Riddell> we'll make a decision in plenty time either way
<pitti> Riddell: ah, I was just reading your -release@ mail
<Riddell> pitti: I still hope to have it in but happy to accept if it can't be done
<pitti> Riddell: tricky situation indeed; we had pretty much the same a few cycles ago
<pitti> at least the telepathy stack settled down since then, it's actually surprisingly stable these days
<pitti> video connections used to be a bit unstable (sometimes you needed to try connecting twice), but that was some time ago; I don't use them often
<pitti> the tubes for sharing your desktop etc. are really cool, though
 * pitti goes back offline until release meeting, bbl
<barry> Riddell: good to see you got a version of telepathy uploaded that fixes the failure.  i got as far as disabling the fix_test_linkage.patch and getting that built in my ppa.  if you're happy with your fix, i'll move on to other things
<Riddell> barry: oh do I?  clever me!
<Riddell> barry: where is this?
<barry> Riddell: https://launchpad.net/ubuntu/precise/+source/telepathy-qt4/0.9.0+repack-0ubuntu2
<pitti> cking: I have a first version of a power-usage-report script (WI in that spec) in https://code.launchpad.net/~pitti/+junk/power-usage-report/
<pitti> cking: it can be run without arguments, does its thing (fatrace, powertop, and post-processing), and gives a reasonably meaningful output
<pitti> cking: I'd appreciate comments and suggestions that you might have
<pitti> cking: today I overheard in a bug report that you have an events-something script yourself, perhaps we can combine this somehow?
<cking> pitti, yes, that's doable - my code is free to be used + reworked
<cking> pitti, I will look at this in ~40 mins - I'm halfway through making a load of edits to a document that needs to be completed today
<pitti> cking: oh, not urgent at all
<pitti> I'll go offline again until release meeting, and won't re-look at this until Tuesday anyway
<pitti> cking: thanks in advance!
<ion> Heh. By chance the nicks of everyone who has been discussing here for the last 25 minutes end up having the same appearance in WeeChat. (It uses nick hashes to select attributes such as color for nicks.)
<pitti> cking: there's another WI to add stracing for the worst offenders, but that'll introduce some interesting problems (reporting passwords and what not), so that'll need some thought
<cking> ok - well, I'm off on monday, so I will either get back to you end of day or on tuesday
<pitti> cking: I'm off on Monday as well
<pitti> cking: but I think in the end the automatic stracing might be overkill -- at that point it's better to analyze the offending processes individually anyway in bug reports, I think
<pitti> this script should give a good overview where the problems are on a particular system
<pitti> anyway, /me waves, bbl
<cking> pitti, yep, I think one can has tools to identify rogue processes, debugging it is a strace + gdb effort
<cking> pitti, thanks for letting me know - I shall look at the tool with great interest! \o/
<rbasak> Does "pull-lp-source" fail for anyone else? Eg: "pull-lp-source hello".
<Riddell> barry: yeah but that has led to a new problem, needing LD_LIBRARY_PATH or something
<rbasak> It seems to work from my machine (authenticated) but not from an anonymous machine
<barry> Riddell: yep.  but hey, a built package is a built package, right? :)
<rbasak> Hmm...rm -Rf ~/.launchpadlib fixed it.
<Riddell> barry: it's not built
<bdmurray> mdeslaur: in oneiric or lucid?
<cjwatson> ivoks: I've merged your livecd-rootfs change, but two things
<ivoks> cjwatson: sure?
<cjwatson> ivoks: firstly, in order to get a BuildLiveCD change deployed, you'll need to raise an RT
<mdeslaur> bdmurray: oneiric...oh, looks like your lucid -proposed package dropped the new security update too
<mdeslaur> bdmurray: d'oh...sorry about that
<barry> Riddell: okay.  let me look in more detail
<cjwatson> ivoks: secondly, the rest of Ubuntu nowadays only uses livecd-rootfs as a wrapper for live-build - the code for that is in the live-build/ subdirectory
<cjwatson> ivoks: so in some ways you seem to be going in the wrong direction
<mdeslaur> bdmurray: publishing security updates when there are packages in -proposed is painful :(
<Riddell> barry: it's cdbs so actually mine and debfx's preference is just to turn it into dh9 and hope that helps
<bdmurray> mdeslaur: the lucid was just approved and had been pending queue
<ivoks> cjwatson: mrmh... ok :)
<cjwatson> ivoks: live-build/auto/config is probably the main one to edit
<ivoks> cjwatson: ok, thanks i'll do that
<barry> Riddell: i definitely support that choice :).  shall i just leave this one to you guys then?
<mdeslaur> bdmurray: yeah, but while it was in the queue, a security update got published, and since you bumped the major version instead of the minor version, it superseded the security update
<ivoks> cjwatson: atm cloud-live is build with live-build; does that make any difference? should i still change livecd-rootfs?
<bdmurray> mdeslaur: Is there anything for me to do besides upload new versions to -proposed?
<bdmurray> I mean in addition to
<mdeslaur> bdmurray: no, you just need to remerge the security update and re-upload it
<cjwatson> ivoks: how are you configuring live-build right now?
<ivoks> cjwatson: (sorry, i'm otp) i have whole live-build tree (lp:cloud-live)
<cjwatson> ivoks: you mean you branched the whole thing?
<cjwatson> ivoks: wow, that's ... interesting
<cjwatson> ivoks: what I'd suggest is that you figure out how to do this with the stock live-build package in precise, using suitable 'lb config' parameters and possibly the odd hook
<cjwatson> ivoks: then it should be a short step from there to expressing that in livecd-rootfs/live-build/auto/config
<ivoks> cjwatson: let me get back to you in few minutes (on the phone)
<cjwatson> ivoks: sure, no rush
<cjwatson> ivoks: ah, looks like you checked in the result of running lb config and creating hooks
<cjwatson> ivoks: so that could be done on the fly in auto/config instead
<kelemengabor> dobey: ping. do you have time to review the proposed merge for bug #856728?
<ubottu> Launchpad bug 856728 in Ubuntu Translations "Missing translations (Learn more, Install) in ubuntuone-installer window" [Medium,Triaged] https://launchpad.net/bugs/856728
<dobey> kelemengabor: yep, i will poke at it shortly. i am working on installer right now :)
<dobey> kelemengabor: thanks for the reminder
<kelemengabor> yw :)
<dobey> bdmurray: i'll try to poke at your lptools branch today too
<bdmurray> dobey: thanks
<ivoks> cjwatson: sorry, i had a meeeting
<ivoks> cjwatson: all those changes are now in the package, so that build mechanism is kind of obsolete
<ivoks> cjwatson: s/changes/hooks
<dylan-m> Little question before I file a bug report: why are the category icons for gnome-control-center named like preferences-desktop-personal-directory instead of preferences-desktop-personal ?
<pitti> ev: test_run_crash_known() test case in ui.py works for you? I still get a KeyError (just re-merged your branch 5 mins ago)
<ev> pitti: ah, I wasn't sure if that one was related to the gdb weirdness I was seeing.  When I poked at it last night, it was raising an IOError inside collect()
<ev> I'll have another look
<ev> apols for that
<pitti> ev: no, I get KeyError: 'KnownReport'
<pitti> PYTHONPATH=. python apport/ui.py -v _T.test_run_crash_known
<pitti> ev: that looks like a regression in the dupe detection
<ev> yes, but if memory serves, it's because the IOError is raised, setting self.report to None
<ev> (and thus the KeyError)
<pitti> ev: bug report window looking nicely now, thanks for fixing that up!
<pitti> ev: btw, I'm not getting the gdb failures; I suspect it's a race condition, but I don't think that's related to your work at all
<ev> pitti: cheers!
<pitti> ev: I'm currently walking through all {bug, crash, symptoms} x {gtk, cli, qt} cases
<ev> thanks for that - I tried to understand them as best I could, to ensure I wasn't just making the test pass, but it was getting on in the evening and I could've made a mistake somewhere.
<SpamapS> Ugh
<SpamapS> why does apt want to remove unity-2d?!
<SpamapS>   gnome-session: Breaks: unity-2d (< 5.4~) but 5.2.1-0ubuntu2 is installed.
<SpamapS> ahh, that
<pitti> buildd lag
<apw> cjwatson, is it possible to increase 'something' on key packages like ubuntu-desktop to encourage apt's conflict resolution to prefer not to remove it
<smoser> SpamapS, around ?
<SpamapS> smoser: I am
<smoser>  /etc/network/if-up.d/upstart
<smoser> i'm looking tat that and wondering
<SpamapS> yes
<kelemengabor> is there any unity dev around, who could take a look at the merge proposal in bug #923762 ?
<ubottu> Launchpad bug 923762 in unity (Ubuntu) "Files missing from Unity's POTFILES.in" [Medium,In progress] https://launchpad.net/bugs/923762
<smoser> if no interfaces are auto, will all interfaces ever be noticed as up?
<SpamapS> kelemengabor: try #ubuntu-desktop
<SpamapS> smoser: lo is always going to be auto
<smoser> well.. yeah.
<SpamapS> smoser: and actually no, if there are no auto interfaces, all_interfaces_up will return 0
<smoser> so here s what i'm looking at right now.
<SpamapS> because the for loop will be skipped
<smoser> its mostly an edge case
<SpamapS> err
<SpamapS> actually this script will never be called in that case
<SpamapS> and you'll failsafe boot
<smoser> but in cloud-init, i can now take an /etc/network/interfaces file from "config drive" or from DataSourceNoCloud
<Daviey> jdstrand / mdeslaur (barry for info): bug 934295, not proud that i got it to build by giving back.. but you might want to be aware if it's not fixed before release.
<ubottu> Launchpad bug 934295 in python-django (Ubuntu) "FTBFS on buildd's testsuite (FAIL: test_timeuntil)" [Undecided,New] https://launchpad.net/bugs/934295
<smoser> the order would then be boot... likely lo up, mount / , cloud-init, cloud-init writes /etc/network/interfaces and runs 'ifup --all'
<smoser> but if the new /etc/network/interfaces does not have any auto (other than lo) then nothing would emit that.
<jdstrand> Daviey: gotta love it! thanks :)
<smoser> hm..
<pitti> ev: for a crash report I still get the second window with the info colelction progress bar
<pitti> ev: you don't?
<smoser> but i guess that snot really all that bad, because anything waiting on that is probably actually expecting network.
<ev> pitti: Do you not get that error in test_run_crash_known with trunk? the error it's attempting to raise (but which gets swallowed by the except clause around collect_info) in both trunk and my branch is 'CRC check failed 0x6d754465 != 0x0L'
<ev> pitti: I do not. What's the command you're running where you're seeing that?
<pitti> ev: gedit &; killall -SEGV gedit
<pitti> PYTHONPATH=. gtk/apport-gtk
<pitti> ev: that's with killall update-notifier, so that it doesn't get in the way
<pitti> ev: trying with trunk again
<ev> I'll give it a bash after this interview call
<pitti> ev: (I'm in release meeting, sorry for lagging)
<ev> no worries at all!
<ev> I appreciate your careful and thorough review of this
<SpamapS> So, dpkg experts.. if I have a conffile, say, /etc/apparmor/profiles.d/usr.sbin.mysqld .. and it is owned by mysql-server-5.1 ...
<SpamapS> and then mysql-server-5.5 Breaks/Replaces mysql-server-5.1 ..
<SpamapS> and it also owns said file..
<SpamapS> wouldn't one expect that the file would *only* be owned by mysql-server-5.1 ?
<SpamapS> err
<SpamapS> 5.5
<SpamapS> I would expect that the conffile would be owned by 5.5, and that it would be updated to the 5.5 version
<pitti> ev: I'm done with testing, I followed up to the MP
<pitti> ev: I don't get that _T.test_run_crash_known failure in trunk
<pitti> ev: then the second progress dialog, and finally the apport-kde crash (which might or might not be your fault)
<pitti> ev: oh, and the "dash" vs. "Ubuntu 12.04 internal", but I agree that we can sort this out later and it's not a blocker
<SpamapS> slangasek: ^^ any ideas on the conffiles? Its showcased in bug 934013
<ubottu> Launchpad bug 934013 in mysql-5.5 (Ubuntu) "Mysql fails to start after upgrade to precise" [Undecided,New] https://launchpad.net/bugs/934013
<slangasek> SpamapS: yes, Replaces should be sufficient to cause the mysql-5.5 version to take over
<jtaylor> barry: can you do a no change rebuild of libvigraimpex please
<SpamapS> slangasek: its showing rc for mysql-server-5.1 .. and the content is still the 5.1 version
<slangasek> SpamapS: the new version of the package doesn't ship that conffile at all?
<slangasek> so since the old package is removed but not purged...
<slangasek> the old conffiles remain
<SpamapS> slangasek: it does ship that conffile
<slangasek> SpamapS: not according to dpkg -c / Contents.gz
<SpamapS> ruh roh
<SpamapS>     if [ "$(DISTRIBUTION)" = "Ubuntu" ]; then \
<SpamapS>       dh_apparmor -pmysql-server-5.5 --profile-name=usr.sbin.mysqld; \
<SpamapS>     fi
<SpamapS> hmmmmm
<SpamapS> oh
<SpamapS> no.. hmm.. debian/apparmor-profile is there...
<SpamapS> oh wait.. does dh_apparmor not actually pull that file in?
<pitti> SpamapS: FWIW, if mysql is anything like postgresql, then uploading whole microreleases to -updates/-security is probably better than trying to cobble together large patches ourselves
<pitti> SpamapS: a microrelease exception would be in order then, and likely granted provided that upstream has strict policy for microreleases and good QA
<SpamapS> pitti: I was under the impression that postgres was far more careful abotu not introducing incompatible changes in patch releases though.
<pitti> SpamapS: yes, that's the "if"; I am not familiar at all about the nature of changes that happen in mysql microreleases
<jdstrand> SpamapS: iirc, when using dh_apparmor you need to rename apparmor-profile to what you are passing as the --profile-name
<SpamapS> pitti: about every 2-3 releases they break something. To be fair, they usually identify it in their changelog.
<jdstrand> SpamapS: ie, mv apparmor-profile usr.sbin.mysqld
<SpamapS> jdstrand: indeed, looks like the file got missed
<jdstrand> SpamapS: (in the debian/ directory of course)
<pitti> SpamapS: not that helpful for production servers, though
<pitti> SpamapS: if that is so, then backporting security fixes indeed sounds better then?
<SpamapS>     install -D -m 644 debian/apparmor-profile $(TMP)/etc/apparmor.d/usr.sbin.mysqld
<SpamapS> In 5.1 packaging, not in 5.5
<SpamapS> ok it all makes sense now. :)
<jdstrand> SpamapS: yes, 5.1 did not use dh_apparmor iirc
<SpamapS> pitti: we can't do that
<SpamapS> pitti: Oracle *obfuscates* their security fixes
<jdstrand>  /o\
<SpamapS> jdstrand: it did
<pitti> SpamapS: hm, you think mariadb will have compatibility problems, too?
<SpamapS> pitti: yes
<pitti> rock <-> SpamapS <-> hard place
<jdstrand> can we migrate mysql users to postgresql?
<SpamapS> s/SpamapS/Ubuntu & Debian MySQL users/
 * jdstrand is obviously kidding
<SpamapS> jdstrand: lol
<pitti> SpamapS: for psql I found that users didn't appreciate the backporting fixes that I used to do
<SpamapS> pitti: to be fairl, neither do a lot of MySQL users.
<pitti> SpamapS: they wanted the full microreleases, even though they had larger changes (but usually no incompatibilities, except to fix security holes)
<pitti> SpamapS: just giving that as a data point
<pitti> SpamapS: so maybe the odd incompatiblity is ok, as users can then go directly upstream to discuss/log bugs/etc.
<SpamapS> Its really not about the users perception.. they'll take 5.1.61 and use it. Its just that we are going to be the first point of contact for when it breaks their app.
<pitti> just giving that as a data point; I can't make a solid recommendation what to do for mysql
<SpamapS> pitti: heh.. except that bugs.mysql.com is now a 2nd class citizen at Oracle.
<SpamapS> pitti: you have to pay to get access to the private bug tracker.
<SpamapS> to be fair, they have been responding a bit more to community bugs
<pitti> good night everyone!
<SpamapS> but.. yeah.. its just the suck.. what made MySQL great... nimble openness .. is gone. Its now just "Mini-Oracle"
<jdstrand> SpamapS: ignore me on the apparmor-profile/dh_apparmor bit. I was confused. dh_apparmor just needs the profile to where it expects it to be based on --profile-name. whether one uses 'install -D -m 644...' or a debian/*.install file doesn't matter. sorry for the noise
<SpamapS> jdstrand: indeed, I'm fixing the files sections now
<SpamapS> somehow missed the apport hook too
<SpamapS> Ugh.. I really want to rewrite this packaging from scratch
<ion> âwhat made MySQL greatâ /me snorts
<SpamapS> right, its not great.. it just accidentally dominated the database market for the last 10 years. ;)
<ajmitch> ion: not a fan? :)
<ion> ajmitch: For a toy database, SQLite is easier to deploy and maintain. For a real database, one might want to use a real database. :-P
<SpamapS> mysql is to databases as sitcoms are to television.
<SpamapS> yes.. a toy that runs facebook and google... just a toy. :)
<ion> An awesome piece of history: http://sunsite.univie.ac.at/textbooks/mysql/manual.html#Broken_Foreign_KEY
<SpamapS> seriously
<SpamapS> did you just quote the 3.23 manual?!
<jdstrand> hehe
<ajmitch> it may be old, but it's an amusing read :)
<ajmitch> SpamapS: I don't envy you or other maintainers trying to keep up with security fixes from oracle though
<SpamapS> ajmitch: we're not going to. We're going to ship the micro releases.. period. :-/
 * ajmitch relies on mysql at work, so it's sort of important to have it still function 
<jdstrand> SpamapS: yeah, I just don't see any other way atm :(
<ajmitch> just have to hope that the tests catch any regressions
<SpamapS> jdstrand: neither do any of the experts .. people who have been developing mysql for years cannot find the way to get the security patches out
<jdstrand> SpamapS: to add insult to injury, its my understanding that there most recent 5.0 release was their last
<jdstrand> s/there/their/
<SpamapS> jdstrand: yeah.. we're on thin ice for the next 14 months w/ hardy
<jdstrand> SpamapS: well, maybe they'll wait 14 months to group security vulnerabilities together like they did last time :P
<ajmitch> isn't that a problem with any upstream that doesn't provide fixes over a long period?
<jdstrand> ajmitch: the problem is there isn't any path to backport from 5.1. the fixes are all obfuscated with no access to the bugs
<SpamapS> jdstrand: the reality is that many of the CVE's they reported as being fixed in 5.1.61 were fixed in earlier releases
 * ajmitch could write some things about that situation, but has to adhere to the CoC
<jdstrand> ajmitch: you and me both
<SpamapS> jdstrand: but 5.1.61 is just the first release where they're 100% using oracle's machinery
<jdstrand> I see
<SpamapS> jdstrand: in fact the mariadb guys were pretty convinced that some of them were duplicate CVE's of publicly disclosed bugs.
<SpamapS> I say bring on Drizzle
<jdstrand> heh
<jdstrand> 'pretty convinced'
<jdstrand> that is from the experts. man, what a mess
<SpamapS> http://bit.ly/x40TS8
 * ajmitch wonders if he can move to postgresql
<SpamapS> ajmitch: You're going to have a lot less friction moving to Drizzle.
<SpamapS> 99.9% compatibility.. just all the stupid stuff removed.
<jdstrand> SpamapS: seriously :)
<ajmitch> SpamapS: you're probably right, the drizzle packages in precise look to be a few months old though
<SpamapS> like   update table set timestamp column = NULL; ... in mysql a select from that column will give '0000-00-00 00:00:00'
<SpamapS> in drizzle it gives.. SURPRISE.. null
<SpamapS> ajmitch: I'll be uploading the GA release of drizzle to precise next week
<ajmitch> SpamapS: great
<SpamapS> ajmitch: its beta right now
<ajmitch> SpamapS: are you currently the only person touching php & mysql in ubuntu?
<SpamapS> ajmitch: mostly yeah
<SpamapS> ajmitch: zul helps some too
<ajmitch> that figures
<zul> secrets and lies!
<SpamapS> hmm
<ajmitch> zul: oh hello there
<SpamapS> so.. I wish dh_apparmor actually installed the file into the intended package..
<SpamapS> because it makes it really hard to sync packages between debian/ubuntu if you have to change the .install or .files ..
<ajmitch> SpamapS: where is the best place to help out with php-related stuff these days?
<lamont> lamont    3722  0.3 60.0 6779384 2310004 ?     SLl  Feb14  15:24      \_ nm-applet
<SpamapS> ajmitch: testing testing testing testing. :)
<lamont> what has my machine done to itself that nm-applet has chosen a 6GB footprint in memory?
<SpamapS> ajmitch: We've diverged from debian recently, as they've removed suhosin, and we're keeping it
<ajmitch> yeah I saw that in your latest upload
<slangasek> lamont: hahaha
<lamont> slangasek: yeah, something like that
<lamont> network mangler has expanded its scope to include swap manglement
 * lamont dist-upgrades again before rebooting
<dylan-m> Hey, I noticed the Wacom settings panel has a Map Buttons button, which is disabled. Anyone know what's going on with that? (WIP upstream, or is it a missing dependency?)
<slangasek> lamont: hmm, so, the postfix resolvconf hook still fails miserably in early boot
<lamont> slangasek: somehow, this does not surprise me
<slangasek> it's weird though
<slangasek> things fail, then /etc/init.d/postfix status exits zero :P
<slangasek> oh, ah yes
<slangasek> because postmulti fails, enabled_instances() returns an empty list
<lamont> haha
<lamont> nice
<slangasek> so "all" 0 instances are running
<lamont> yeah
<Sarvatt> dylan-m: it looks like its just a stub and hasn't been implemented yet
<dpm> hi pitti, the latest precise langpacks are dated from 0209 and were disabled for the beta freeze. I haven't seen any other langpacks, but the cron job is enabled. Did you just enabled it recently, or is something happening with the builds?
<SpamapS> jdstrand: hey, is there any reason that an apparmor profile containing package should include the dir etc/apparmor.d/force-complain
<SpamapS> ?
<jdstrand> SpamapS: the force-complain directory is used for upgrades from a release of Ubuntu that shipped the package without a profile (or non-enforcing) to a release that ships an enforcing profile
<SpamapS> jdstrand: ok, so 5.1 has always shipped enforcing profiles
<jdstrand> SpamapS: idea being, that if you upgrade from a release that didn't have the profile present, we don't have enough information to be sure we won't break your system, so we force it into complain mode
<SpamapS> I think, let me check lucid..
<jdstrand> I think mysql has since hardy tbh
<SpamapS> jdstrand: ok, so we don't need that dir anymore seems
<jdstrand> yes, it was in hardy
<jdstrand> shouldn't, no
<SpamapS> jdstrand: should I leave the bit in postrm to remove the symlink?
<SpamapS> seems like yes
<SpamapS> or is that dh_apparmor's job now?
<jdstrand> SpamapS: yes-- the user could have done it
<jdstrand> oh, good point
 * jdstrand looks
<SpamapS> yep
<SpamapS> cool
<jdstrand> cat /usr/share/debhelper/autoscripts/postrm-apparmor
<jdstrand> dh_apparmor does it
 * SpamapS <heart> dh
<jdstrand> hehe
<jdstrand> SpamapS: fyi, it got easier in Debian. apparmor in Debian ships dh-apparmor now so everyone can start using it
<jdstrand> SpamapS: we need the apparmor merge to happen though in Ubuntu first before we can then pull those Debian packages into Ubuntu (should happen next week)
 * jdstrand thanks kees for his tireless work with debhelper upstream and finding a solution for us
<SpamapS> # no DEBHELPER here, "update-rc.d remove" fails if mysql-server-5.5 is installed
<SpamapS> DOH
<SpamapS> I bet thats not the case anymore.
<SpamapS> jdstrand: thats awesome!
<jdstrand> yeah-- next cycle we can start removing that delta and push all this up to Debian, now that they have an apparmor
<slangasek> jdstrand: hmm, I don't see a dh_apparmor in the current debhelper package in unstable?
<kees> slangasek: it's in the dh-apparmor binary package in unstable
<slangasek> ah
<slangasek> oh, he kinda said that already
<dylan-m> Okay, thanks, Sarvatt
<m4n1sh> ev: ping
<bdmurray> doko: thanks - I've pushed a fix for that
<barry> Riddell: well, at least i can reproduce the failure in my sbuild now, not that i have a fix yet
<Riddell> barry: debfx says he has a patch http://people.ubuntu.com/~debfx/telepathy-qt4_0.9.0+repack-0ubuntu3.debdiff
<Riddell> ah well a port to dh
<Riddell> debfx: have you tried it in a PPA?
<barry> Riddell, debfx that's probably the best longer term fix.  i'll give that a try in preference to the fix/hack i've been developing
<barry> Riddell, debfx your debdiff works for me locally.  tests pass, package gets built.  i'll try it in a ppa to double check.  don't know if you're still online, but if there are no objections, i'll go ahead and sponsor this upload.  will be nice to get this one fixed
<Riddell> barry: yes please
<barry> +1
<broder> slangasek: spent some more time thinking about initscripts/insserv
<broder> does it make any sense to put the postinst code in insserv just for the srus, and not sru initscripts at all?
<broder> we've have the better fix for the long-term, and the "short term" of the srus would have a fix that was guaranteed ordered correctly
<slangasek> it makes a certain amount of sense, yes
<slangasek> notwithstanding my dislike for insserv messing with links belonging to initscripts
<broder> sure, that's not ideal, but at the same time, it is insserv cleaning up its own mess, which seems appropriate at some level
<broder> and my head doesn't explode trying to think about the edge cases in possible upgrade paths
<slangasek> yeah; I wouldn't reject this solution either
<broder> ok. i think i prefer doing it this way. would you mind rejecting the insserv srus i've already uploaded, and then i can roll this in and reupload?
<broder> thanks
<slangasek> broder: rejected
<ScottK> dobey: Where's your split python-qt4 package?
<lamont> slangasek: bind9 9.8.1.dfsg.P1-3 uploaded to debian, I figure we can sync it monday
<slangasek> lamont: sounds good to me
<lamont> I'll work on postfix next,sometime this weekend
 * slangasek nods
<bdrung> cjwatson: around?
 * lamont wanders
<slangasek> bdrung: he isn't
<bdrung> k
#ubuntu-devel 2012-02-18
<ximion> pitti: hi!
<Ezim> hi is it possible to ask I question about CMakeLists? I wonder what should from CMakeLists be used in debian/control Build-Depends? Here is a link: http://paste.kde.org/424334/
<ximion> pitti: Are you there? I'd like to ask you a question about a change you applied to the packagekit package recently...
<Ezim> kdelibs5-dev, libx11-dev, libkwinglesutils1, freeglut3-dev  correct?
<ximion> Ezim: what do you mean? The X11, OGL(ES), KWin/KDE libraries?
<Ezim> ximion, training on making package
<ximion> Ezim: looks okay... If you're unsure, you could test-build your package in a chroot environment.
<Ezim> I picked http://kde-apps.org/content/show.php/BeClock?content=117542
<ximion> Ezim: you should always test-build your package in a chroot environment (you can use e.g. pdebuild for that after creating a pbuilder environment) - Then you'll see if stuff is missing.
<Ezim> ximion, I have never tryid to build in chroot enviroment
<ximion> if you don't want to do this, you can also run ldd on the resulting binary, see which libs are used, find the package they're in (apt-file) and then add their -dev package to depends.
<ximion> from what I see in the cmake file, you'll need kde-workspace-dev zoo
<ximion> *too
<Ezim> ximion, this package is not in the repo.
<Ezim> package outside repo
<ximion> Ezim: which package?
<Ezim> I picked http://kde-apps.org/content/show.php/BeClock?content=117542
<ximion> Ezim: yes, I'm talking of the packages you need as build-dependency.
<ximion> you can determine them by building a binary out of your sources, and then use the ldd way.
<ximion> this is not the most efficient way, but it works :P
<Ezim> ximion, you mean without adding anything to Build-Depends?
<ximion> a better alternative is using the CMakeLists, which tells me that you'll need at least cmake, kdelibs5-dev, libx11-dev, libkwinglesutils1, freeglut3-dev, kde-workspace-dev
<ximion> Ezim: no, you can find out Build-Depends from the libraries your resulting binary is linked to.
<ximion> but that's just if you're really not sure :P
<Ezim> CMakeLists <<--- was exactly were I looked
<Ezim> I only wanted to now if does I wrote was right or not
<ximion> Ezim: I think yes, if you depend on cmake (kinda obvious) and kde-workspace-dev too :)
<Ezim> find_package(KDE4), find_package(X11), find_package(OpenGLES), find_package(OpenGL)
<ximion> but to be really sure, you need to test-build your new pkg in a clean environment e.g. with pbuilder ( http://pbuilder.alioth.debian.org/#usingpbuilder )
<ximion> cmake helpers to find OpenGLES and OpenGL are in workspaces-dev :)
<ximion> so you'll need it
<Ezim> ximion, so the only thing I missed was kde-workspace-dev?
<ximion> and cmake, yes -  as far as I can see
<Ezim> ximion, :) cmake of course
<ximion> but there might be some hidden stuff somewhere, I haven't looked at the source or if there's another buildscript somewhere
<Ezim> libqt4-dev <<--- maybe also?
<ximion> Ezim: AFAIK, the kde dev packages should pull this in
<ximion> everything else would be against policy.
<ximion> yep, they do depend on it already
<Ezim> ximion, there is not any other buildscript I am aware of.
<ximion> okay, then give it a try! :)
<Ezim> ximion, which section should I choose in debian/control?
<ximion> Ezim: kde
<Ezim> ximion, :) this is only trying to make package.
<ximion> Ezim: is this your first Debian package? (Just asking so I don't tell you stuff you already know ^^)+
<Ezim> ximion, no.
<Ezim> ximion, this is my 3 outside the (k)ubuntu repo.
<ximion> Ezim: okay :) Do you use the PPA service?
<Ezim> ximion, :) no, only for myself. when I feel I can make good package then I will help in other way to ubuntu-family.
<ximion> if you only build packages on your machine then, debuild uses your local environment, meaning that the package build won't fail even if you haven't defined all the Build-Depends which are actually required ^^
<ximion> you only need to have the packages installed locally :P
<ximion> (of course, you need to define the right builddeps if you build your package in a clean environment, like a PPA repo or pbuilder env)
<Ezim> ximion, yeah Build-Depends before i modify it, it builded correctly anyway.
<ximion> ...but I suppose you know this already :P
<ximion> yes :D
<Ezim> ximion, :) yes.
<ximion> cmake uses Fin* macros to find modules required for build... So if you see something "like find_package (Foo)", you can run a search which package contains "FindFoo.cmake" - then you have your build-dependency or a hint how to find it.
<ximion> (cmake itself ships some Find* fines, but you can open them and check which library/etc. it's referring too, if this is not obvious already)
<ximion> *files
<ximion> oh, it's really too late, I can't even type correctly anymore :(
<infinity> TheMuso: Is there any chance I can get you to merge 3.2.0-17.26 with -lowlatecy and re-upload, so I don't waste buildd time accepting this -16.25 one from NEW?
<infinity> TheMuso: Other than that, it all looks good, and I'm happy to accept.
<infinity> TheMuso: Actually, I guess since it only builds on x86, I don't care about the buildd churn so much.  Just so long as you guys are committed to rebasing and keeping it up to date.
<Atlantic777> Is there any guide on where to store files, or to be even more specific, how to use sqlite db and where to store database?
<Atlantic777> This is first time I'm writing a desktop app so... I'm not sure. ~/.myAppFolder/database.db is ok?
<Atlantic777> which offline database you suggest? sqlite vs couchdb
<hyperair> sqlite.
<hyperair> the whole desktopcouch stack was horrible for the laptop battery iirc
<Atlantic777> tnx hyperair, then I'm on a good way. :)
<Ampelbein> Atlantic777: ~/.myApp/ looks fine to me and yeah, sqlite is the better solution for now. But #ubuntu-app-devel might be better for those kind of questions.
<Atlantic777> oh, sorry, I havn't read the topic here...
<addy20020> hello all is their is special compiler on which c language coding and compiling on same plateform as like in window
<ximion> pitti: hi!
<ximion> pitti: are you there?
<htorque> hi everyone! if debsums detects changes to files like 'changelog.Debian.gz', should this be filed as bug against the corresponding package?
<penguin42> htorque: There's something special about those due to the system where only part of hte changelog is included in the resulting package
<penguin42> htorque: And I think it might be related to a gzip bug where the gzip of the same file didn't always produce the same result
<htorque> penguin42: yeah, that's why i'm asking - i noticed lots of mismatches for those files. i'll keep looking for a bug report.
<penguin42> htorque: There is bug 871083 for gzip odd behaviour - but I don't think that's the one due to mangled changelogs
<ubottu> Launchpad bug 871083 in libtasn1-3 (Ubuntu Precise) "gzip -9n sometimes generates a different output file on different architectures" [Medium,Triaged] https://launchpad.net/bugs/871083
<htorque> there are also a couple of png files, probably due to optimization efforts?
<mainerror> Someone needs a kernel ninja on Ask Ubuntu.
<mainerror> http://askubuntu.com/questions/105395/make-fails-because-it-doesnt-know-headers-install
<ximion> pitti: are you there now? (sorry for bothering ^^)
#ubuntu-devel 2012-02-19
<cjohnston> 15
<l3on> Hi all... I've a question about packages have files (script) in /usr/lib/NAME/ directory
<l3on> for instance â http://packages.ubuntu.com/precise/all/ivtools-bin/filelist
<l3on> are they in the right place?
<l3on> most of these package are affected by bug like this:
<l3on> `pkglibdir' is not a legitimate directory for `SCRIPTS'
<l3on> there is a "simple" way to fix it ad maintain SCRIPTS or DATA or whatever in the /usr/lib/NAME/ directory ?
<cousteau> would it be possible to add Adobe Shockwave to repositories?
<cousteau> there's an installation workaround based on Wine and MozPlugger, but it's complicated to set up - it would be nice if a package did that for you
<cousteau> (similarly to how flashplugin-installer also installs nspluginwrapper and installs the 32b version on 64b machines)
<kyoushuu> How could I get a debug package for xchat? I want to fix a bug by checking the debug package, but there's no xchat-dbg package in precise.
<debfx> kyoushuu: https://wiki.ubuntu.com/DebuggingProgramCrash
<kyoushuu> Thanks!
<kyoushuu> Is there any difference if install libgtk2.0-0-dbgsym or libgtk2.0-0-dbg?
<Ampelbein> kyoushuu: If both exist, install the -dbg one. -dbgsym are automatically generated, while the -dbg could be built using special debug options.
<kyoushuu> If I created my own package, how could I get a -dbg package? I compiled gwaei from git and based the package from the Ubuntu package, but it doesn't have a -dbg package.
<cyphermox> kyoushuu: IIRC you just need to have a -dbg package listed in debian/control; and maybe pass --dbg-package=<whatever> to dh_strip
<cyphermox> kyoushuu: http://wiki.debian.org/DebugPackage
<kyoushuu> While using these debug packages, how do I set a breakpoint in gdb? I get the following:
<kyoushuu>    (gdb) b src/fe-gtk/dccgui.c:264
<kyoushuu>    No source file named src/fe-gtk/dccgui.c.
<kyoushuu>    Make breakpoint pending on future shared library load? (y or [n])
<kyoushuu> I'm currently in the xchat-2.8.8 that I got from 'apt-get source xchat'
<kyoushuu> While using these debug packages, how do I set a breakpoint in gdb? I get the following:
<kyoushuu>    (gdb) b src/fe-gtk/dccgui.c:264
<kyoushuu>    No source file named src/fe-gtk/dccgui.c.
<kyoushuu>    Make breakpoint pending on future shared library load? (y or [n])
<kyoushuu> I'm currently in the xchat-2.8.8 that I got from 'apt-get source xchat'
<Atlantic777> is testing a development release in chroot ok idea? I'm not using ubuntu but I would like to test few things...
<Atlantic777> Is it generaly better to have a "normal install" or chroot is good enough? Can I run some gui apps which exist only in chrooted system?
<tumbleweed> Atlantic777: depends how much you want to test, and what you want to test
<tumbleweed> chroots are great for most packages, and fine for most GUI stuff
<Atlantic777> I would like to try how will some my apps work on new ubuntu releases.
<tumbleweed> if you want to see how well they work with the standard ubuntu desktop environment, a VM is preferable. If such detials aren't important, a chroot should be fine
<cyphermox> if the app is simple enough to install, maybe a live CD might work too
<tumbleweed> (disclaimer: I don't use a real ubuntu install for day-to-day work, almost everything I do in Ubuntu I build & test in ubuntu chroots)
<Atlantic777> cool, that's what I need
<Atlantic777> I'm using some other distro on the desktop and I have ubuntu on the netbook. I'm trying to develop something ubuntu specific and I can't install ubuntu on desktop. So solutions are to develop it on netbook, create vm and develop it there or make chroot. It's some foo pygtk app and I'm testing quickly. Hope that I got my answer, I can use chroot for development and testing. Right?
<Atlantic777> quickly = this nice dev helper app from http://developer.ubuntu.com/
<tumbleweed> what's ubuntu-specific about it?
<Atlantic777> that I don't have quickly, couchdb, gtk3 and deb packaging things on gentoo
<tumbleweed> the packaging is easily done in a chroot, and gtk3 and couchdb aren't ubuntu-specific
<Atlantic777> what about unity lenses? can that be tested in chroot?
<Atlantic777> I find that interesting, too.
<tumbleweed> Atlantic777: that'd be hard to do in a chroot
<Atlantic777> tumbleweed: ok...
<Atlantic777> And what about debootstrap?
<tumbleweed> what about it?
<Atlantic777> chroot vs debootstrap for this purpose
<tumbleweed> they are orthoganal
<kyoushuu> Is there a command to install source packages? I get "3468	/build/buildd/gtk+2.0-2.24.10/gtk/gtkicontheme.c: No such file or directory." when debugging
<Ampelbein> kyoushuu: apt-get source <packagename>
<tumbleweed> also, -dbg packages
<kyoushuu> but they are not installed to 3468	/build/buildd, should I just recreate those, or is there any command to install the sources there?
<kyoushuu> rather: but they are not installed to /build/buildd, should I just recreate those, or is there any command to install the sources there?
<tumbleweed> your debugger should have a way to point it at th esources
<kyoushuu> Ah, okay. But since I download sources to different directories, and I'm lazy, I'll just download them to /build/buildd...
#ubuntu-devel 2013-02-11
<doko> cjwatson, just sync libffi from experimental
<doko> now synced
<lifeless> infinity: you missed 'sbuild' for Ubuntu :P
<infinity> lifeless: In intentionally didn't mention it, since it's not a sparate piece of software in the LP case, but a forked and embedded copy.
<lifeless> infinity: ah, I thought you were listing the toolchains, not the things they develop
<lifeless> LP doesn't want it to be a fork :) it just sucks at fixing that
<infinity> It's on my TODO.  There are some things I want to address before I can do that.
<infinity> (And, like Debian, it'll probably always have to be a fork, to a certain degree, but a lightly-modified branch, rather than a decade-old fork)
<infinity> As in, Debian's buildd tools (buildd and sbuild) have infrastucture branches that are slightly different from the packaged versions, but merged into on a regular basis.
<cjwatson> doko: ah, didn't notice, sorry.  thanks
<Chipzz> infinity: what do you mean for "small local archive"? Lets say I have a big number of servers runnig debian/ubuntu, and I want to rebuild a certain number of debs for internal usage; would your definition apply?
<Chipzz> infinity: also, what would you suggest in such a case?
<infinity> Chipzz: Well, if it's a really small number of debs, just doing the builds by hand (or marginally scripted) with sbuild and then building a flat archive with dpkg-scanpackages or apt-ftparchive works fine.
<infinity> Chipzz: You don't really need autobuildy infrastructure until you either have lots of arches or lots of packages (or both).
<infinity> Chipzz: At which point, there are mid-range solutions out there like reprepro and mini-dinstall and such (which, admittedly, I have no experience with, but I hear they're simple enough).
<Chipzz> it might be more convenient though (hack on the deb in your homedir, once done, upload to a server and have it built/being able to be deployed automagically)
<infinity> Chipzz: And then if you're doing something nearly distro-sized, dak itself is likely the best bet, unless you're really comfy with doing local launchpad setups.
<infinity> (Though, dak has gotten vaguely user-hostile lately too, I hear)
<infinity> To each their own, mind you.  *shrug*
<Chipzz> yea
<Chipzz> I never got to the point of automating stuff on my last job
<Chipzz> "Not their core business blablabla spend your time on sth more useful blablabla..." ;)
<Chipzz> but it was something I was thinking about
<Chipzz> one use case was to be able to keep providing php4 on newer distro's (dont ask :( )
<infinity> Ew.
<Chipzz> that's what you get when your colleague webmasters have an "It works now, so why would I change?" attitude :/
<Chipzz> and management thinks "It works, why invest time and money that works now?"
<Chipzz> +in something
<Chipzz> with that attitude I didn't even bother trying to tell them about supportability etc, they just didn't see the value :(
<infinity>  php5 (5.0.4-1) unstable; urgency=low
<infinity>    * Initial PHP5 release; packaging forked from php4 4:4.3.11-1.
<infinity>  -- Adam Conrad <adconrad@0c3.net>  Sat, 16 Jul 2005 23:42:36 +1000
<infinity> So, uhm.  They really like to live in the past, I take it?
<Chipzz> "We're a publishing company, not an IT company. Updating our sites is a waste of time and money when there are some many other things to build"
<Chipzz> at which point I didn't even bother...
<Chipzz> and the attitude of my colleagus being very similar, well..
<Chipzz> good thing I'm gone there now, SEP
<Chipzz> first thing my successor did when he started there was upgrading php, beside me having it pinned in preferences. Hilarity ensues :)
<Chipzz> but "Not my problem anymore now" :)
<pitti> Good morning
<Dedunu1> good morning
<dholbach> good morning
<captainlinux> Guys how do you think, is it better to kind of merge webapp icons with applications which are calling them? I mean - the more tabs I open in my firefox the more webapps get called and at the end my dash is full of useless icons which I don't even touch. Wouldn't it be better just to change the Icon of Firefox according to the active webapp and to change the icon every time you change the tab calling another webapp?
<ogra_> captainlinux, try #ubuntu-app-devel
<ogra_> (see topic)
<captainlinux> Oh, thanks!
<pete-woods> has anyone got a nice link to how you're supposed to implement cancellable dbus methods serverside?
<pete-woods> basically I have a compiled dbus interface (where it emits signals in response to client-side method calls)
<pete-woods> and I can't see where you connect to the gcancellable
<xnox> pete-woods: this is not really relevant for this channel, as we develop ubuntu itself here. Not general programming for/on ubuntu. But it'd recommend to look into udisks2 which implements that in it's API.
<xnox> (over dbus)
<pete-woods> xnox: thanks for the info (again) :)
<mlankhorst> cjwatson: https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1121179 ?
<ubottu> Ubuntu bug 1121179 in mesa (Ubuntu) "Ubuntu 12.04.2 alternate AMD 64 ISO image Feb 10 installing mesa 8.0.4 not 9.0.0 - LTS quantal" [Undecided,New]
<infinity> mlankhorst: Fun.  We may have missed some seed changes that affect how alternates are built.
<mlankhorst> seems so
<infinity> And by "might have missed", I mean "may not have done at all"... Hrm.
<infinity> How the heck is the new ubuntu-meta being built correctly?
<ogra_> infinity, hmm ? did it change ?
<infinity> Oh, crap.  We did it all in livecd-rootfs, and skipped updating seeds.
<ogra_> oh, thats 12.04.2
<xnox> well Feb10 image - is it .2 or candidate?!
<infinity> xnox: Yes.
<infinity> cjwatson: Your clever plan to do xserver-xorg-lts-quantal entirely in livecd-rootfs and skip making seed changes makes alternates sad.
<infinity> cjwatson: Perhaps a debian-cd hack to s,tasksel/first,pksel/install-pattern, and use "*buntu-desktop xserver-xorg-lts-quantal"... That would sort of match the livecd-rootfs change.  Though, we might need to be more clever to get the right packages on the CD in the first place.
<cjwatson> I probably forgot about alternates because we've stopped building them elsewhere ...
<infinity> Well, stopping building them is also an option. :P
<cjwatson> And it's not so much that we skipped updating seeds as that we determined we *couldn't* do it that way
<cjwatson> Not for 12.04
<infinity> Well, seed updates would have no effect on the archive, but they WOULD affect CDs, since CDs are based on fresh germinate runs, no?
<cjwatson> TBH: I'm at least half-tempted to just release-note that the alternates get you the old stack
<cjwatson> Oh, true
<cjwatson> Well, I'm on leave today: if you want to give it a try and respin then be my guest :)
<infinity> I'm guessing it might be as simple as just adding xserver-xorg-lts-quantal to the appropriate desktop seeds and praying germinate does the right substitution and culling.
<infinity> But it's never that simple.
<cjwatson> I think that should be all you need
<infinity> I'll give it a whirl.  Easy enough to back out and release note if it ends up a tangled mess.
<cjwatson> Since germinate marks everything in the seeds as installed before attempting to resolve broken dependencies
<cjwatson> (Much like apt)
<infinity> Enjoy your leave.  Thanks for popping in to be a sounding board.  Shoo.
<yofel> cjwatson, infinity: question about the new LTS stack: yesterday we were wondering in #kubuntu-devel how the hell that's supposed to work. Are the changes in livecd-rootfs also applied to the flavour images or what do we need to do to get the new stack?
<yofel> currently we only have the kernel change in the seed
<cjwatson> you need to have asked for it a couple of weeks ago if you want it for a given flavour for .2
<yofel> that was documented... where?
<cjwatson> it'll need a livecd-rootfs SRU and er I think something else
<cjwatson> probably wasn't, sorry
<yofel> *sigh*
<yofel> nevermind
<yofel> we'll rever the kernel then
<cjwatson> because this all got dumped on *me* rather too late to coordinate anything properly
<yofel> *revert
<cjwatson> eh
<yofel> heh
<cjwatson> how do you already have an updated kernel?
<cjwatson> because that's handled in the same place ...
<yofel> cjwatson: we changed the seed, so our current test image has kernel 3.5 + mesa 8
<cjwatson> that was silly :)
<cjwatson> yeah, revert that and ask for a respin please
<yofel> well... yeah
<yofel> Riddell, ScottK ^
<Riddell> yofel: currently talking in #ubuntu-release
<cjwatson> seriously, major structural changes like that it's best to consult with the person coordinating the point release ...
<yofel> ah, good
<Laney> what is guanabana?
<marga> Does anyone here understand the interaction between dconf and gsettings?
<marga> Supposedly, dconf is a backend for gsettings
<marga> But I'm seeing a bug where something set with gsettings does not match the value set with dconf.
<Riddell> didrocks: bonjour, kde 4.10 est tout bon en raring, ou somme-nous avec qt 5?
<didrocks> Riddell: salut! I uploaded the qt4-compatible with qt5, we'll get a quick review of qtchooser. Qt5 itself is in the pipe, but still polishing the packaging with review and rereview :-)
<Riddell> didrocks: qtchooser looks like it's in
<didrocks> Riddell: yeah, we need a post-MIR though
<Riddell> didrocks: who needs it in main?
<Riddell> oh for qt
<Riddell> of course
<didrocks> yep :)
<Riddell> didrocks: I see qtbase-opensource-src  and qtscript-opensource-src in New, shall I review?
<didrocks> Riddell: seb128 is doing the first review pass, but maybe he could use some help :-)
<didrocks> qtscript is already under way and there are some copyright issues, so refixing soon
<seb128> Riddell, I found copyright issues with qtscript, if you want to review qtbase or start on it please do, there is lot to review there
<Riddell> seb128: I'll take a look, what was up with qtscript?
<seb128> Riddell, debian/copyright is incomplete, e.g src/3rdparty/javascriptcore/JavaScriptCore/profiler/ProfileGenerator.cpp is copyright apple and under BSD and the debian/copyright doesn't list apple at all and has this one under LGPL
<dhanasekaran> Guys Where i can find, kernel related release notice please guide me
<ogra_> on launchpad or in /usr/share/doc/<packagename>/changelog.gz
<ogra_> (also probably more appropriate for #ubuntu-kernel)
<Riddell> seb128: oh I see packaging issues rather than upstream
<Riddell> it's only 45MB, should be a quick review :)
<Daviey> xnox: no smart proxy :(
<xnox> Daviey: I am working on it as a hobby project =) but it's not a work priority for me.
 * xnox wishes for xnox-personal work items
<xnox> Daviey: currently still prototyping. Hoping to have something working in a few weeks.
<xnox> well 3-4 evenings of working on it.
<Daviey> xnox: that is wonderful!
<bdrung> Sweetshark: should i upload 4.0 beta2 today or do you want to merge the 4.0 final first?
<infinity> seb128: If single files are BSD, the entire source can be GPL, that's not a conflict at all.
<seb128> infinity, right, be shouldn't debian/copyright list those are BSD sources? in any case that's not the only issues, some files were listed under a wrong license in there and some copyright holders are missing
<infinity> seb128: And if individuals files carry different copyright owners, that also doesn't necessarily need to be shown (see the kernel as a prime example).
<infinity> seb128: "Linus Torvalds and others", we don't list every single copyright header.
<infinity> seb128: And we list the kernel as being GPL, despite plenty of individual files being BSD or other free licenses that have no conflict with being relicensed as GPL.
<seb128> bdrung, thanks for the libreoffice review, it seems that you found mostly small problems ... does it raise your confidence for Sweetshark ppu application? ;-)
<seb128> infinity, ok, well it seems weird that if apple contributed a good part of the code in there to not have it listed in the copyright holders list
<seb128> infinity, if that list is incomplete and lack some of the major contributors and that's ok what's the point of having it at all?
<infinity> seb128: We don't list Freescale, Marvell, Intel, etc as copyright holders to the kernel.
<seb128> infinity, note that I would be happy to just see debian/copyright being optional :p
<seb128> infinity, well my german mind says either we care about copyright and it should be right or we don't care and why bother :p
<Sweetshark> bdrung: I would go for uploading 4.0 beta2. Im back to work today and wading through a 4300 email backlog from the last two weeks. I will bump to 4.0 soonish then.
<infinity> seb128: I dunno.  Others would disagree with me and want copyright to be nit-pickingly complete, but if it covers the license of the project as a whole, and no individual files stand out as contradicting that, it doesn't need to note everything that's more relaxed.
<bdrung> seb128: ping me after the dmb meeting.
<infinity> seb128: The "and others" bit is important if you're just listing one upstream copyright contact, mind you.
<seb128> bdrung, ok
<bdrung> Sweetshark: will you apply the patches i sent you and regenerate the source?
<infinity> seb128: And I haven't looked at the one you rejected in particular, if it literally has two copyright holders, listing the two is easy.  But if it has hundreds (which is true of most OSS projects), why single out the "major contributors" as different from the guy who has copyright on one file?
<seb128> infinity, well, I learnt to be picky and I usually list all the copyright holders because I though it was the way it should be done
<seb128> infinity, e.g I would list 100 lines if there is 100 of those to list :p
<seb128> infinity, but I never understood the point of listing copyright holders in debian/copyright to start with
<infinity> seb128: It's certainly not wrong to list them all.
<seb128> infinity, if the list can be incomplete then it could as well go missing...
<infinity> seb128: I think it's mostly a fiction that copyright holders are useful in debian/copyright, I agree with you.  What matters is the licenses, the source files themselves list the copyright holder.  But not an argument I'd want to get into.
<seb128> hehe, same here ;-)
<infinity> seb128: (Now, in the case when the source DOESN'T list the copyright holders, then having it in debian/copyright is important, as is often the case with the entirety of debian/* for instance)
<infinity> Because a license means nothing without a copyright holder granting it.
<Sweetshark> bdrung: I will try to apply the patches and push them to the repo and regenerate the source today still.
<bdrung> Sweetshark: thanks. ping me when done and i will do the upload.
<Daviey> infinity: The real inconsistency is that once accepted, debian/copyright is rarely/never updated to reflect new AUTHORS.
<Sweetshark> bdrung: willdo. thanks for the review work!
<infinity> seb128: I dunno.  I just probably wouldn't reject on an "and others." copyright statement is all I'm saying.  Others might.  And maybe it would be good to have the kernel list every single copyright holder in debian/copyright to appease some people's sensibilities.
<bdrung> Sweetshark: you're welcome.
 * infinity is somewhat glad his major package is an FSF one that has a single copyright holder, and he can pretend not to care.
<seb128> infinity, thanks for the input, I will be a bit more relaxed on NEW review and copyright holders after that discussion ;-)
<infinity> seb128: Licenses, on the other hand, are much more meaningful.  You need to make sure nothing conflicts with the overall project license (if it's GPL/LGPL/MPL/etc).
<infinity> seb128: Luckily, people mixing BSD/MIT/expat code into GPL projects is pretty much a non-issue, so you get to gloss over it.  We can just distribute the project as a whole as "GPL" and be done with it.
<davmor2> n
<infinity> seb128: (Not that it's wrong to list each individual license, but I'd contend that any user who wants to know that src/lib/function.c is BSD is going to be reading the source anyway, cause he wants to use the file, and he'll find out then)
<seb128> infinity, right, that's not the case there, the sources are Qt style: e.g LGPL-2.1 with qt exception or GPL-3 and there are a bunch of BSD files in the middle of the tree
<infinity> Again, some people will argue that you should list the license for every file.  And totally not wrong to do so.  Just also not a legal issue if you don't, as long as the project license as a whole isn't incorrect because of those files.
<infinity> seb128: The kernel again being a canonical example here, distributed as GPL-2, but a ton of the code in there is actually MIT/BSD/expat.
<seb128> infinity, right, I got it, thanks for the details ;-)
<infinity> (Same story with glibc, actually, which actually has a TON of 4.4BSD-derived code that was donated by UCB and they even kindly dropped the advertising clause to avoid license conflicts)
<infinity> Very entertaining headers.  The licenses have clause 1, 2, 4.  3 just mysteriously went missing.
<mdeslaur> Sweetshark: mind if I merge boost1.49?
<infinity> mdeslaur: I don't think anyone wants TIL on boost.
<infinity> mdeslaur: But if you take it, remember to do boost-mpi to match, or the world explodes.
<mdeslaur> infinity: oh! thanks for the hint
<marga> This is the bug I was mentioning earlier: https://bugs.launchpad.net/ubuntu/+source/glib2.0/+bug/1122028
<ubottu> Ubuntu bug 1122028 in glib2.0 (Ubuntu) "gsettings does not respect dconf locks" [Undecided,Confirmed]
<marga> In certain situations, gsettings and dconf values differ.
<marga> I'm trying to chase this, but it's a big monster, I'd appreciate any pointers.
<seb128> marga, hey, can you try pinging desrt on #ubuntu-desktop about it? he wrote gsettings/dconf and is maintaining those for us
<marga> oh, I looked for him here.
<marga> Sure
<vibhav> Is there any documentation on adding Multi-Arch support for packages?
<dobey> seb128: btw, did you not upload with my patch for bug #859600 ? :)
<ubottu> bug 859600 in gnome-keyring (Ubuntu Precise) "Please convert gnome-keyring to multiarch" [High,In progress] https://launchpad.net/bugs/859600
<stgraber> ScottK: congrats!
<ScottK> Thanks.
<seb128> dobey, doh, will do today!
<dobey> seb128: thanks :)
<Sweetshark> mdeslaur: sounds good to me, and yeah: infinitys hint is well worth its bits and bytes ...
<mdeslaur> Sweetshark: thanks
<cjwatson> vibhav: http://wiki.debian.org/Multiarch/Implementation
<vibhav> cjwatson: thanks!
<mlankhorst> is it just me or is there no xorg package set for quantal?
<Laney> seems likely
<Laney> they are per-series
<Laney> stgraber: ^- care to copy?
<stgraber> I can do that yes
<stgraber> mlankhorst: do you need something else than quantal too? (I try to avoid unnecessary copies as keeping them all in sync is a pain)
<stgraber> (done for quantal)
<vibhav> hmm, The wayland ABI/API are still not fixed, right?
<Laney> stgraber: I could imagine a -S all that does the smarts to apply packageset operations uniformly
<stgraber> Laney: well, you're assuming we have the same source packages everywhere ;) we don't, especially for xorg where they have a bunch of special ones for LTS
<stgraber> and sometimes things end up moving between packagesets between releases too (thinking of the desktop one)
<stgraber> so yeah, we probably could make the scripts a bit less painful, but covering all the weird cases will be tricky
<Laney> Well I don't believe that they have to exist in that series, merely to have an SPPH at all.
<Laney> That's how you can get packagesets out of sync with the archive in the case of removed packages, for example
<stgraber> yeah, I try to avoid that though as it makes pretty confusing reports ;)
<Laney> It could also do the conservative thing and check which series the package exists in
<SpamapS> Hrm, something with X in raring is making synergy do weird things
<SpamapS> keyboard presses are held too long often... so I get lots of ..............'s or aaaaaaaaa's
<SpamapS> modprobe: ../tools/modprobe.c:550: print_action: Assertion `kmod_module_get_initstate(m) == KMOD_MODULE_BUILTIN' failed.
<SpamapS> Aborted (core dumped)
<SpamapS> doh, and there's this
<SpamapS> weird why isn't apport pppppppppppppppicking that uuuuuuuuuuuuuup?
<SpamapS> ^^ argh
<hyperair> eh whenever synergy times out or gets interrupted in mid-keystroke that happens
<Laney> SpamapS: https://bugs.launchpad.net/ubuntu/+source/kmod/+bug/1073062
<ubottu> Ubuntu bug 1073062 in kmod (Ubuntu) "modprobe: Assertion `kmod_module_get_initstate(m) == KMOD_MODULE_BUILTIN' failed" [Undecided,Confirmed]
<SpamapS> Laney: cool, +1'd
<seb128> Riddell, thanks for qtbase review, do you think you have any time for qtdeclarative as well? ;-) (I'm reviewing qtscript and qtmultimedia)
<Riddell> seb128: QtQuick?  it'll be a quick one!
<Riddell> I'll take a look
<seb128> Riddell, thanks ;-)
<alexlist> https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1122278
<ubottu> Ubuntu bug 1122278 in ubiquity (Ubuntu) "ubiquity hangs when existing LVM volumes are present" [Undecided,New]
<xnox> alexlist: thanks. it is probably a dupe of existing hang, but your steps to reproduce it are much easier for me to follow.
<xnox> i'll see if i can strace it and hopefully fix it for good.
<mjt> how bad is to have a package in Suggests: whcih is not in ubuntu but is available in debian?
<alexlist> xnox: you're welcome. For the time being, I wiped the disks and just installed on 1 disk, will ad SW raid later. But I guess there are many users out there who want RAID1 on two disks in a workstation  ....
<JontheEchidna> mjt: usually it's not considered worth making a delta between debian/ubuntu, especially if that would be the only difference (iirc)
<xnox> mjt: happens all the time =) it's totally fine.
<mjt> heh ok
<infinity> mjt: Which package is that?
<mjt> qemu
<mjt> suggests vde2
<infinity> mjt: I meant the suggests.
<mjt> which has been rejected by the security team iirc
<hallyn> looks like i was wrong then - excellent
<infinity> mjt: It's in Ubuntu.
<mjt> hallyn: ^^ ;)
<mjt> heh. so much fuzz... ;)
<mjt> or buzz
<infinity> It's in universe, not main, but that's not a problem.  We only follow recommends for component promotions, not suggests.
<jbicha_> happyaron: can I lower the ibus-table dependency in Ubuntu on ibus to 1.4.2?
<happyaron> jbicha_: let me check
<jbicha_> happyaron: or we should have you do it to exercise your new upload powers? :)
<happyaron> jbicha_: that could be a good idea, :)
<happyaron> but please bear me a bit more time to learn about the difference between upload queues of ubuntu and debian.
<jbicha_> happyaron: sure, feel free to ask questions if you need help too
<jbicha_> (I'm thinking it's probably too late in the raring cycle for ibus 1.5 as it's a bit disruptive :) )
<happyaron> jbicha_: for 1.5, see my short discussion in -desktop with seb128
<happyaron> jbicha_: I think ibus-table 1.5 is okay for ibus 1.4.2, but if you don't have a good reason then there's no need to take the potential risk.
<jbicha_> happyaron: thanks for the pointer, we're definitely interested in ibus 1.5, we just don't want to pass breakage along to our users
<happyaron> I see. Unfortunately 1.5.1 brings more breakges, :(
<jbicha_> we already have ibus-table 1.4.99 in raring, and 1.5.0-1 is in raring-proposed (but can't auto-migrate to raring because of the unsatisfiable dependency)
<jbicha_> https://launchpad.net/ubuntu/+source/ibus-table
<jbicha_> autosync from Debian unstable hasn't been turned off yet
<happyaron> I see.
<happyaron> then lower the dependency is okay.
<jbicha_> if that version has issues, we could do a 1.5.0+really1.4 or whatever if needed...
<jbicha_> happyaron: ok I'll let you try to handle that upload then?
<happyaron> ok
<happyaron> so the only differece here is ubuntu needs a source-only upload, I think?
<barry> dobey: how goes those u1 oauth branches?
<jbicha_> happyaron: yes that's the biggest difference from uploading to Debian
<happyaron> jbicha_: debdiff http://paste.ubuntu.com/1637302/
<jbicha_> happyaron: that looks perfect to me :)
<happyaron> ok, signing and uploading
<happyaron> jbicha_: done, got the email, :)
<dobey> barry: working on it
<barry> dobey: thanks
<catbus1> smoser: ping
<smoser> catbus1, hey
<catbus1> smoser: about bug 1115710, do we still need to have /etc/modprobe.d/mlx4.conf if mlx4_en specifies PCI IDs?
<ubottu> bug 1115710 in module-init-tools (Ubuntu Quantal) "Mellanox mlx4_en network driver is not automatically loaded" [Medium,Triaged] https://launchpad.net/bugs/1115710
<smoser> catbus1, no.
<smoser> catbus1, are you implying that mlx4_en might have/get pci-ids ?
<smoser> this was/is the upstream decision to load that _core module on pci-id. and then basically require user-configuration for loading other stuff.
<catbus1> smoser: no, I am not implying they will. if mlx4_en is important to be loaded in the boot path, maybe it should specify so it gets auto loaded.
<smoser> catbus1, you're right that that is probably ultimately the right place for the fix.
<smoser> i was surprised, though, that upstream kernel had this as it is for so long. as if it is working as expected.
<catbus1> dduffey: ^^^
<barry> dobey: looks like a linting is not so smart, unless there's some other reason why 10 skips and 766 successes still causes the merge tests to fail. :/
<dobey> barry: pep8 complained about your indentation change of a closing paren in the imports line. reverting the change will fix it (i added comments to the MP about it)
<LantzR> Hiya. I created a new ppa:  bzr push  lp:~lantzr/+junk/cup-pdf-zel which was ok. What I do not understand is why it moved to lp:~Ubuntu-Etherpad/+junk/cup-pdf-zel
<barry> dobey: oops, sorry about that.  (i try not to fix whitespace even when it's wrong <wink>, but i hit tab on that line or something.)
<dobey> LantzR: you probably want #launchpad or #bzr for help with that. i don'tk now why that would happen outside of you typing the wrong thing or something, though
<LantzR> Thx dobey. It was under me most of last night ... then moved
<dobey> LantzR: https://answers.launchpad.net/launchpad and ask a question about it, and someone will look into it
<barry> dobey: revert pushed
<dobey> thanks
<dobey> barry: doh; i didn't notice this before your branch landed (which i am surprised it did), but ubuntu_sso/utils/webclient/tests/test_webclient.py still has "from oauth import oauth" and doesn't import oauthlib
<barry> dobey: oh crap
<barry> dobey: yeah,that will break test_iri_parameters_used_in_oauth_signature() :(
<barry> dobey: let me work on a branch for that
<dobey> well, it didn't break is the thing. the branch landed :-/
<dobey> thanks
<barry> dobey: right, removing the import will though ;)  my grep just missed it :(
<barry> dobey: actually, i think that test can be removed, but please double check me.  all it's doing is ensuring that 'fake_param' is in the parameters when the low-level oauth.OAuthRequest.from_consumer_and_token() is called.  but that will never be called, so who cares?  it's kind of a silly test ;)
<dobey> barry: hrmm, yeah. i don't see that being used in software-center or ubuntuone-client either
<dobey> there's something in ./ubuntu_sso/utils/tests/test_common.py that does something with from_consumer_and_token though; which should probably get axed as well
<barry> dobey: should i just kill the whole FakedOAuthRequest class?  doesn't seem to be used anywhere
<barry> dobey: tests pass, so "yes" i guess ;)
<barry> https://code.launchpad.net/~barry/ubuntu-sso-client/no-mo-o-oauth/+merge/147781
<dobey> barry: if it's not used and doesn't break tests, i'd say sure
<barry> dobey: cool.  mp all up2date-y
<bdrung> Sweetshark: i am doing the final test build, which probably will end when i sleep and i will do the upload tomorrow.
<dobey> barry: mmcc posted a needs-fixing. looks like the test is useful, so probably should stay, but the use of oauth directly can go away
<barry> dobey: looking
<Sweetshark> bdrung: I did a test-build with your patches here and it completed and passed the tests. I only wanted to review the debdiff to the last version I put on people.canonical.com once more (and punted that for tommorrow morning).
<bdrung> Sweetshark: have you seen the mail to rene and you with six additional patches?
<bdrung> Sweetshark: one thing to do before the upload is to update the date in the changelog stanza
<Sweetshark> bdrung: hmm, I seem to have missed that one.
<bdrung> Sweetshark: sent 20 minutes ago
<Sweetshark> bdrung: have some mercy with me, wrangling down a 4300 msg inbox today.
<bdrung> Sweetshark: i know that feeling. :)
<Sweetshark> bdrung: found it, will sync with rene about it tomorrow to move them to the debian branch ASAP.
<bdrung> thanks.
<bdrung> Sweetshark: after looking closer at the packaging, i am all in for rebooting the packaging.
<barry> dobey: updated
<dobey> thanks
<Sweetshark> bdrung: yep. IMHO that has to start upstream. The .deb packages created by the upstream packaging at LibreOffice (using the desaster of the old OOo packaging system) are that broken that there is luckily not much one can break by touching them (except that debian/ubuntu packaging is build on top of it via this gid2pkgdirs.sh voodoo).
 * bdrung nods.
<bdrung> packaging should only be i tiny wrapper around the upstream build system.
<Sweetshark> bdrung: moving the packaging logic there proper (instead of using half of it and then moving and splitting stuff around later) would be a huge win.
<bdrung> yes
<dobey> barry: hrmm, that doesn't seem right. body would be text, not a dict, no?
<bdrung> that's what a build system is for
<dobey> barry: and headers should have more in it than just the params
<barry> dobey: in oauthlib i think body can be either text or a dict.  in this case because the parameters are being passed in as a dict (and auto-converted internally due to Content-Type: application/x-www-form-urlencoded), then the come out as dict from oauth_client.sign()
<barry> dobey: but it's possible that i don't fully understand how build_oauth_request() is supposed to be used
<dobey> barry: hrmm, if that's true, i think that's a bug in oauthlib then. body should always be text
<Sweetshark> bdrung: the build system itself has mostly finished the migration to sane gbuild (which is essentially plain GNU make), but the upstream packaging is still quite messy: perl and C preprocessor macro madness (hmm, at least m4 seems to be dead and gone there now ... \o/)
<Sweetshark> anyway ...
 * Sweetshark is gone for the night.
<bdrung> Sweetshark: why care about upstream packaging?
<barry> dobey: the api for Client.sign() says it can be a "dict, a list of 2-tuples, or a formencoded string"
<bdrung> packaging should be done by the distribution and upstream can use that packaging.
<bdrung> Sweetshark: does upstream generate the debian/ files via a script?
<dobey> barry: i don't understand why body would ever be anything other than None, or a form encoded string. anything else just doesn't make sense in the context of what a body is
<barry> dobey: i think the motivation is that if the client got form data as a dict, it wouldn't have to formencode it itself, the oauthlib library would do that as a convenience.
<barry> (list-o-2-tuples and dicts being essentially equivalent)
<barry> s/client/user of the library/
<Sweetshark> bdrung: I never looked closely at that, but IIRC the upstream packages are just created using some cruel hacks around epm.
<dobey> barry: i think everything using this api, expects it to be a string, as it's going directly to the web
<bdrung> Sweetshark: then let's don't care about it. rebooting the packaging can start (as gbuild should be there)
<bdrung> Sweetshark: starting with it now has the advantage of safely landing in raring+1
<dobey> barry: on the other hand, i can't find any external users of that API either
<dobey> barry: it just seems very odd to me for an api to do that
<barry> dobey: could be yeah, but i guess upstream has its reasons ;)
<barry> dobey: otoh, build_oauth_request() could *not* convert the query params into a dict, then it would just send them into .sign() as formencoded.  that might make sense as it saves a roundtrip from formencoded->dict->formencoded
<barry> dobey: it wouldn't change this test though because Client.sign() would still return a dict (i think, would have to try it)
<Sweetshark> bdrung: the package split is used on all platforms in some form (e.g. for the msi splits on windows and for the way the rpms are split).
<Sweetshark> bdrung: and we are still depending on in multiple ways: This stuff is a/ also used in 'make install' and 'make dev-install' (which are essentially 'package to directory' targets) and in the current debian/ubuntu packaging via the gid2pkgdirs.sh script, which extracts the upstream packaging split for debian/ubuntu as a base and then modifies and tweaks some of it.
<barry> dobey: anyway, i'm certainly willing to do what you think is right, given upstream's api
<dobey> barry: query parameters aren't formencoded though. that's the whole point :)
<Sweetshark> bdrung: What I would love to have would be something like 'make install PKG=libreoffice-core' or somesuch upstream to install each package in a debian/ package dir.
<dobey> barry: and given the description of upstream's api, i can't easily predict what will happen :-/
<bdrung> Sweetshark: isn't it possible to install everything in debian/tmp and then split by directory and * wildcard?
<bdrung> that's what smaller packages do
<Sweetshark> bdrung: nah, that wouldnt work too well. The LibreOffice install layout is vastly different from what you want in a debian/ubuntu system.
<barry> dobey: probably best not to guess then!  which i think means build_oauth_request() not passing in a dict, but encoding the parameters itself, do you think?
<Sweetshark> bdrung: as for getting this done for raring+1: that depends on priority and thus is not my call -- I have some other things raised on my list of TODO that have priority for Canonical.
<bdrung> Sweetshark: maybe it's time to get upstream follow the FHS
<bdrung> pictures should go to /usr/share
<dobey> barry: i think i need to read the oauthlib code for that call, because their API design is rather unfortunate since I have no idea why you're passing the Content-Type header in at all, and your description of the API worries me
<bdrung> Sweetshark: whom could i talk to to get it raised?
<Sweetshark> bdrung: libreoffice@lists.freedesktop.org patches welcome ;)
<barry> dobey: okay.  it's entirely possible i'm smoking something ;)  do take a look and let me know what you think.  i'm going afk now, but let's touch base tomorrow (or just update the m-p).  also, upstream is very friendly, so if you think their api is whack, please file a bug at https://github.com/idan/oauthlib
<bdrung> -ENOTIME
<Sweetshark> bdrung: the tricky part is when touching URE etc. one has to be careful not to break the stable ABI promise.
<Sweetshark> bdrung: ;)
<Sweetshark> anyway ... really gotta go, n8
<bdrung> good night
<dobey> need to go as well
#ubuntu-devel 2013-02-12
<Bluefoxicy> man
<Bluefoxicy> how do I test debian-installer
<TheMuso> netboot?
<Bluefoxicy> heh
<pitti> Good morning
<pitti> infinity: please remind me again, does soft-freeze mean that -proposedâ release migration is suspended, or that we should stop uploading to -proposed?
<pitti> infinity: nevermind, language-selector just migrated, so I guess it's the latter
<ScottK> pitti: In theory migration is suspended.  The block I put in place is not ideal however.
<ScottK> I also put it up somewhat late.
<ScottK> So you're supposed to be able to keep uploading.
<pitti> ScottK: ah, ok; the language-selector fix is fine I think, but I wouldn't want to upload a new gvfs during the freeze
<pitti> ScottK: does "late" mean "within the last hour"?
<ScottK> Yes
<pitti> ah, ok
<ScottK> I guess though with Edubuntu bailing out of Alpha 2, it's just Kubuntu AFAIK, so maybe gvfs is fine.
<pitti> it's on kubuntu-active-dvd-live
<pitti> but aside from a new backend, it's mostly bug fixes
<ScottK> Ah.
<ScottK> Riddell: ^^^^ is that still a valid seed for us?
<pitti> ScottK: so apparently authres also just migrated
<ScottK> That's not on any images though.
<ScottK> The block is meant to be limited.
<pitti> ah, great
<ScottK> I was supposed to write a script to generate the hint, but didn't get time yet, so what's in place is not ideal.
<pitti> ScottK: so in theory, the block will take care of not migrating packages that affect a2 images, and people can just go on uploading?
<ScottK> That's the theory.
<ScottK> If they theory doesn't work out, bad on me for not writing a better block, IMO.
 * pitti presses "Like!" button
<isaias> Hello to all Ubuntu Dev' ^_^
<dholbach> good morning
<diwic> seb128, hi
<seb128> diwic, hey
<diwic> seb128, how are you?
<seb128> diwic, I'm good thanks, how are you?
<diwic> seb128, it's a bit calmer due to chinese new year :-)
<diwic> seb128, so I'm looking at a oem-priority bug, which they want fixed in 12.04 preferrably
<diwic> seb128, bug 1071561
<ubottu> bug 1071561 in OEM Priority Project precise "[sound-nua] Bluetooth device not listed if change mode to Off" [Medium,New] https://launchpad.net/bugs/1071561
<diwic> seb128, first, it bothers me that not more people have discovered, but anyway. For 13.04 my ambition was to actually make us handle the off profile better
<diwic> seb128, and for 12.04 we would just remove the off profile like we have done for alsa cards
<diwic> seb128, but now I don't know if I'll get to that during this cycle; so what do you think?
<diwic> seb128, what is your advice here - in what order should I/we do what, essentially?
<seb128> diwic, reading that bug/patch
<diwic> seb128, and, btw. In 13.04 bluetooth will start to work a bit differently when we upload PA 3.0, so it's possible this bug resolves itself for bluetooth anyway
<seb128> diwic, so the issue is that you can turn a device off and then not on back because it's dropped from the list?
<diwic> seb128, exactly. Change the bluetooth profile to "off" and it disappears from the list
<seb128> diwic, that seems fine for SRU to me, do you want me to upload that to raring and precise?
<diwic> seb128, yeah, I think that's the simplest way. Haven't checked if it applies to 13.04 straight off
<diwic> seb128, do you want another merge proposal for raring, or do you take it from here?
<seb128> diwic, do you consider that as upstreamable to GNOME or as a distro hack until pulseaudio fixes the issue?
<diwic> seb128, upstreamable
<diwic> to gnome
<seb128> diwic, it would be nice if you could upstream it and I will handle the Ubuntu uploads
<seb128> diwic, works for you?
<diwic> seb128, ok, I'll make an upstream bug for it
<seb128> diwic, thanks
<xnox> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Open | Dev' 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: xnox
<xnox> please reject / mark w-i-p / resubmit of https://code.launchpad.net/~baltix/ubuntu/precise/ubuntu-defaults-builder/remove-quotes-from-firefox-bookmarks-titles/+merge/137107
 * dholbach hugs xnox
<seb128> diwic, let me know when you open the upstream bug, I would like to add the bug reference to the changelog
<diwic> seb128, ok, can you reach bugzilla.gnome.org? It seems down.
<seb128> diwic, you are right, connection failed
<diwic> seb128, I'll try later and let you know if I succeed
<xnox> fixed up bug 778627
<ubottu> bug 778627 in bash (Ubuntu Precise) "In natty, bash completion now quotes shell variable references rather than expanding them" [Undecided,Incomplete] https://launchpad.net/bugs/778627
<tziOm> I get a kernel segfault on 12.10 updated running exim4/spamass/clamav/nfs mounts
<bdrung> Sweetshark: you have got mail. there is just one blocking issues.
<bdrung> seb128: i would love to see this blueprint raised: https://blueprints.launchpad.net/ubuntu/+spec/desktop-r-reboot-libreoffice-packaging
<seb128> bdrung, hey, thanks for the reviews on libreoffice ;-)
<seb128> bdrung, yeah, we would like to see packaging cleaned but we have only one lo maintainer and getting things working and libreoffice updates is higher priority than cleaning a working debian/rules...
<tziOm> How can I prevent ubuntu from loading radeon driver? Seems to cause kernel panic here!
<xnox> tziOm: for support see #ubuntu or askubuntu.com or just google "blacklist kernel module"
<bdrung> Sweetshark: it would be nice if you could push those changes. then i can rebuild the source from the checkout so that you can properly tag the uploaded commit
<bdrung> seb128: you're welcome.
<bdrung> seb128: the packaging reboot will rewrite debian/rules and most of the logic will be done upstream by their build system. the reboot will split the source package, reduce build time, make it faster to review, less error-prone. i make a bet that the invested time will pay back in the future.
<seb128> bdrung, is debian on board with that reboot?
<seb128> bdrung, or does it mean forking libreoffice's packaging in ubuntu?
<bdrung> seb128: i haven't asked the debian maintainer. Sweetshark said that the debian maintainer is conservative. i assume that he will jump on board once the initial step are done. let me ask him.
<seb128> bdrung, thanks (and good luck, the debian maintainer is not really ubuntu friendly ;-)
<ogra_> "conservative" heh
<ogra_> he's such a diplomat
<Laney> i'm sure he'll see the merits in good engineering ;-)
<bdrung> seb128: i can contact him with my DD address :)
<seb128> bdrung, that's probably wiser ;-)
<cjwatson> seb128: Do you have anything to add to https://wiki.ubuntu.com/PrecisePangolin/ReleaseNotes/UbuntuDesktop for 12.04.2?
<seb128> cjwatson, no, I don't think we did any change, which is not already mentioned, and is worth listing
<seb128> cjwatson, libreoffice 3.5.7 was uploaded but that didn't get out of proposed I think?
<cjwatson> seb128: no, still not completely verified according to pending-sru
<seb128> cjwatson, it has a MRE and there is no specific testcase afaik, it's mostly "wait until there is enough confidence the update is good"
<cjwatson> seb128: Sure, I just don't tend to take that kind of decision as an ubuntu-sru member and prefer to wait for somebody more domain-competent to take it and mark the bug accordingly
<seb128> cjwatson, ok, fair enough
<seb128> Sweetshark, ^
<seb128> Sweetshark, if/when you feel confident the 3.5.7 SRU got enough testing and is good please change the tag to verification-done
<cjwatson> (I do tend to look over the bug to make sure it was tagged by somebody I know is competent or somebody who quoted a good reason; but it's rare for me to tag it myself)
<seb128> yeah, I doubt anyone out of Sweetshark has enough of an overview of the testing done/bugs opened since/feedback to tag that one anyway
<seb128> or it would take a day to sit down and digest all the infos/feedback we received through launchpad/forums/...
<cjwatson> Right
<cjwatson> Some bugs are easier - coming up to 12.04.2 there were various bugs pending verification that amounted to "is it actually possible to install this package?", so I just verified those quickly in an schroot
<seb128> yeah, I had on my todo to try to help verifying some SRUs, I didn't get to it though :-( I will still try to do some after 12.04.2 when things are unfrozen
<cjwatson> mlankhorst,tjaalton: Either of you know what's happening with bug 1122072?  It's showing up in 12.04.2 testing reports
<ubottu> bug 1122072 in xorg (Ubuntu) "[Precise on VirtualBox] "Fatal server error: no screen found" in Xorg.0.log" [Undecided,Confirmed] https://launchpad.net/bugs/1122072
<mlankhorst> cjwatson: ugh sounds like a bug fixed in raring
<mlankhorst> let me find the specific commit that fixed it
<tjaalton> virtualbox didn't get updated?
<mdeslaur> cjwatson: mind if I merge curl?
<mlankhorst> cjwatson: https://bugs.freedesktop.org/show_bug.cgi?id=56343 ?
<ubottu> Freedesktop bug 56343 in Drivers/DRI/i965 "[Regression i965]X fails to start with headless" [Major,Resolved: invalid]
<cjwatson> you'd know better than I :)
<cjwatson> mlankhorst: Probably too late to fix for .2 now, but if you can find it a backport for .3 and a release note in https://wiki.ubuntu.com/PrecisePangolin/ReleaseNotes/UbuntuDesktop would be appreciated
<mlankhorst> still fixable if i have someone to verify it
<cjwatson> mdeslaur: Go ahead; just be careful to preserve the +x perms on debian/*.links (easy to lose by accident)
<mdeslaur> cjwatson: thanks for the hint
<cjwatson> mlankhorst: Hm, I hadn't been planning to respin the desktop images; it would depend whether this affects substantial real hardware too
<cjwatson> And this would probably require respinning many flavours ...
<infinity> cjwatson: Well, it affects anyone booting a desktop image in vbox to install...
<mlankhorst> ok it could be done as SRU probably
<infinity> cjwatson: Since no X, no ubiquity.
<cjwatson> Sure, I just don't see virtualbox as a showstopper
<cjwatson> mlankhorst: So what 2D driver is out of sync here?
<tjaalton> hmm
<mlankhorst> cjwatson: no it's a bug affecting quantal too, if you have no outputs it doesn't see the hardware
<tjaalton> vbox shouldn't need any special driver
<tjaalton> the special driver adds more features but it's never available on the installer
<cjwatson> mlankhorst: Just trying to understand how that upstream bug matches up, given Eric Anholt's reply
<tjaalton> probably not that bug :)
<mlankhorst> cjwatson: get a desktop computer, unplug all displays, see if you can reproduce it :P
<mlankhorst> on quantal
<cjwatson> desktop computers?  what are those?
<tjaalton> i have five!
<mlankhorst> a laptop without builtin screen, keyboard and touchpad!
<tjaalton> plus panda
<Sweetshark> seb128: When I left for vacation, I felt good with the SRU already, just wanted to let it hang for a few more days. I havent seen anything popping up so far, but would need to recheck mails and lp-comments again carefully one.
<mlankhorst> and no battery either
<cjwatson> mlankhorst: ah, old tech
<vibhav> cjwatson: Some say they are bigger than laptops
<cjwatson> (you may infer I don't have any, at least not any that wouldn't require some hardware maintenance to get up and running again ...)
<tjaalton> mlankhorst: if it's fixed in xserver 1.13.x then we probably should add it there..
<seb128> Sweetshark, ok, please recheck what happened while you were away and if you don't see any real issue tag it as verified?
<mlankhorst> tjaalton: yeah I want to use xorg-integration-tests as a reason to add a MRE to input-evdev and xorg-server
<tjaalton> right but if there's an identifiable commit it could be sru'd right away
<cjwatson> Do we know if this bug affects kvm?
<Sweetshark> seb128: k, will do.
<mlankhorst> tjaalton: should be d71a17cfab6536df9df46a342a24dd415c020192
<seb128> Sweetshark, danke
<cjwatson> Ah, psivaa says it doesn't
<tjaalton> mlankhorst: ah
<seb128> cjwatson, mlankhorst, tjaalton: is the bug you are talking about the "12.04 isos can't be booted from a raring kvm/virtualbox"?
<mlankhorst> yes
<tjaalton> it shouldn't matter what the host has
<cjwatson> seb128: kvm is reported to work fine, at least via libvirt
<seb128> k, I ran into that last week when I wanted to try to verify some SRU
<cjwatson> seb128: bug 1122072
<ubottu> bug 1122072 in xorg (Ubuntu) "[Precise on VirtualBox] "Fatal server error: no screen found" in Xorg.0.log" [Undecided,Confirmed] https://launchpad.net/bugs/1122072
<tjaalton> I can try kvm in a bit
<mlankhorst> seb128: it should affect normal quantal too though
<seb128> cjwatson, I tried to kvm -cdrom .iso and that didn't work for me, not sure if it uses libvirst by default?
 * penguin42 has done a Precise install on Raring kvm a couple of weeks ago
<cjwatson> seb128: kvm doesn't, no
<cjwatson> I'll check once rsync finishes
<seb128> ok
<cjwatson> http://cgit.freedesktop.org/xorg/xserver/commit/?h=d71a17cfab6536df9df46a342a24dd415c020192 presumably
<cjwatson> (per mlankhorst above)
<mlankhorst> but if somebody verifies the bug exists on quantal too, i can do a sru for both
<cjwatson> do any of you have virtualbox set up to help verify it?
<mlankhorst> nope, suppose i could see if the other system fires up though
<seb128> cjwatson, I have
<cjwatson> since I assume it'd be rather fiddly to do it based on a live CD (unless we promoted it to -updates in advance of verification, and, er, no)
<cjwatson> I guess I could do a custom one-off image build if need be
 * mlankhorst has netboot for live quantal
<seb128> cjwatson, how would I go about testing it?
<cjwatson> with just everything in -proposed
<cjwatson> seb128: the bug says that if you boot a live image and select "Try Ubuntu" (etc.) then that reproduces it
<cjwatson> infinity: ^- which suggests, incidentally, that ubiquity works fine ...
<seb128> right, I can confirm the bug, not sure how to test the fix, does that require to respin an iso?
<mlankhorst> Fatal server error:
<mlankhorst> [    13.893] no screens found
<mlankhorst> [    13.893] (EE)
<mlankhorst> on headless quantal with real hardware
<mlankhorst> ah well lets try the fix..
<cjwatson> seb128: possibly break=casper-bottom and install a new package from -proposed
<cjwatson> seb128: but a custom image might be easier, or if mlankhorst can verify in a more normal environment ...
<seb128> ok, seems like mlankhorst is on it
<infinity> cjwatson: Erm, that doesn't make a lot of sense.
<cjwatson> I know.  I wonder if it only affects second and subsequent attempts to launch a server, or something
<cjwatson> Or maybe only via display managers that are more normal than ubiquity-dm
<cjwatson> ubiquity-dm does hardcode various things
<mlankhorst> ok rebuilding xorg-server now
<tjaalton> so we have a plan to request a MRE for xorg-server minor releases, but it didn't occur to me that it would've been useful for .2 :/ also, integrating the tests is still WIP
<cjwatson> If we're going to do this for .2 it'd need to be a cherry-pick anyway
<tjaalton> sure thing
<cjwatson> This patch is pretty simple and shouldn't require much retesting of other things
<cjwatson> Is this only in xorg-server-lts-quantal/precise, by the way, or xorg-server/precise as well?
<mlankhorst> just quantal
<cjwatson> ok, good
<mlankhorst> dupe of https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1037518
<ubottu> Ubuntu bug 1037518 in xorg-server (Ubuntu) "Xorg crashed with SIGABRT - FatalError (f=f@entry=0x7f41e2f9a9e2 "no screens found")" [High,Triaged]
<mlankhorst> hm wonder how I missed that
<cjwatson> that says it's still happening in raring?
<mlankhorst> shouldn't afaict
<cjwatson> also claims it's a dup of bug 982889.  Is there any possibility that making this compat output change might affect the server's behaviour if it happens to be started up before drm devices appear?
<ubottu> bug 982889 in xorg-server (Ubuntu) "X trying to start before plymouth has finished using the drm driver" [Critical,Triaged] https://launchpad.net/bugs/982889
<mlankhorst> hm that's a different bug
<mlankhorst> ok I'll undupe for now
<cjwatson> Question still applies though :)
<mlankhorst> no
<cjwatson> OK ...
<mlankhorst> this is specifically about not finding screens due to no outputs being connected, I think
<cjwatson> So none connected != some connected but open fails?
<mlankhorst> yes
<cjwatson> Right, makes sense, thanks
 * cjwatson -> bike shop
<mlankhorst> well you can test if you want by cherry picking that patch, it fixes the headless case for me
<cjwatson> On reflection, happy for this to be SRUed and respun for .2 if it checks out for you
<mlankhorst> seb128: want to try with a custom xorg-xserver-core deb?
<seb128> mlankhorst, my image is i386 if you have one of those?
<mlankhorst> quantal?
<mlankhorst> either works, I need to rebuild for lts-quantal anyway, and I have netboots for precise/quantal/raring i386/amd64
<mlankhorst> I so need to automate lts-stack sru's at one point :/
<mlankhorst> seb128: I've done the builds so if you can verify I'll upload both. http://paste.ubuntu.com/1639562/
<seb128> mlankhorst, maybe just upload if it works for you, it will be easier to test for me once it's in proposed
<mlankhorst> seb128: well you can test on a live installation too
<mlankhorst> but I don't know if you're hitting that bug or not
<seb128> mlankhorst, I do when trying to boot the 12.04.2 iso in virtualbox from my raring
<mlankhorst> anyhow if network works you could do some manual testing, I uploaded to my ppa too
<mlankhorst> https://launchpad.net/~mlankhorst/+archive/ppa/+packages building atm
<siretart> hm. i've been looking now for a while in the d-i sources, but I don't see the obvious solution: I need to copy stuff from my customized install cd to the target system just before apt-setup runs, but after /target has been mounted. what's the best way to implement this? is there a hook that I could preseed or something?
<siretart> I've found partman/early_command, but that's quite a bit before /target is usable
<plars> mlankhorst: your request to see if it happens on quantal too - was that pertaining to https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1122072 ?
<ubottu> Ubuntu bug 1122072 in xorg (Ubuntu) "[Precise on VirtualBox] "Fatal server error: no screen found" in Xorg.0.log" [Undecided,Confirmed]
<mlankhorst> plars: yes
<plars> mlankhorst: I can check that, but last I tried quantal it worked fine under virtualbox
<mlankhorst> plars: testing the fix I put up on my ppa on precise-lts-quantal is fine too, i can verify the fix on real hardware for quantal
<plars_> mlankhorst: not sure how much of that you caught before my isp so rudely interrupted, but I'm digging up a quantal image to try it again real quick
<mlankhorst> 15:46 < plars> mlankhorst: I can check that, but last I tried quantal it worked fine under virtualbox
<mlankhorst> 15:47 < mlankhorst> plars: testing the fix I put up on my ppa on precise-lts-quantal is fine too, i can verify the fix on real hardware for quantal
<mlankhorst> 15:50 < plars_> mlankhorst: not sure how much of that you caught before my isp so rudely interrupted, but I'm digging up a quantal image to try it again real quick
<plars> mlankhorst: yes, with quantal everything works fine
<plars> mlankhorst: to be specific, the host machine for all of these is quantal, booting a quantal image works fine, booting 12.04.1 works fine, 12.04.2 does not come up in X under live mode though
<mlankhorst> can you grab xorg-server from my ppa?
<mlankhorst> https://launchpad.net/~mlankhorst/+archive/ppa/+packages seems to be done building
<geser> pitti: aboudreault asked in #ubuntu-motu if postgresql-9.2 will be in raring and if not what's the reason
<pitti> geser: the main reason is the Debian freeze
<pitti> geser: we need to pick between 9.1 with lots of packaged extensions
<pitti> geser: or 9.2 with no packaged extensions at all
<pitti> geser: and I think we are better off with 9.1 for now
<pitti> geser: 9.2 is in my PPA FYI
<geser> pitti: thanks. will forward this to aboudreault
<xnox> pitti: is ubuntu up on apt.postgresql.org (or whatever is the name of the day for that archive?)
<pitti> xnox: yes, but only lucid and precise for now
<xnox> pitti: the only that matter =)
<pitti> LTSes are the most common platform for db stuff anyway
<xnox> (developers get cranky)
<pitti> xnox: I can ask Christoph for more, but I don't think it's that useful
<pitti> apt.postgresql.org is the grand culmination of my good old backports PPA, Debian backports, and Christoph's pgapt.debian.net, I'm really quite happy about it
<sconklin> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Open | Dev' 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: xnox, sconklin
<plars> mlankhorst: ok, installed, what should I restart to try to make it come back?
<plars> lightdm?
<mlankhorst> yeah
<mlankhorst> probably it stopped and attempted to start failsafe-x
<mlankhorst> i think 'start lightdm' would work though
<plars> mlankhorst: nope, still just end up at a black console
<mlankhorst> erk
<mlankhorst> log?
<pitti> oh, I made it to http://lwn.net/ :)
<plars> mlankhorst: looks to be about the same, but let me pastebinit
<alexbligh1> Should userspace services modprobe -r (remove) kernel modules they use on service stop? This seems dangerous if other people might be using them. My specific problem is that openiscsi modprobe -r's the iscsi initatiator module during its init.d's 'stop', which is bad if other things are using it. I'm trying to work out why it does this or whether it's a straight bug.
<plars> mlankhorst: http://paste.ubuntu.com/1639709
<mlankhorst> plars: any quantal log too by any chance?
<xnox> wookey: doko: i guess db5.3 should also get the cross-building/bootstrapping fixes that are applied against db package
<infinity> xnox: Yes.
<wookey> xnox: yes I assume it's much the same
<mitya57> pitti: also you're on http://worldofgnome.org/continuous-integration-of-gnome-modules-on-the-top-of-jenkinscontinuous-builds/ (with a photo) :)
<pitti> ah, credit jibel, credit jibel!
 * xnox is cross-patch-piloting
<pitti> mitya57: added a comment, thanks
<xnox> pitti: You are famous now =)
<pitti> xnox: oh my, all these groupies!
<mitya57> :)
<pitti> seriously, I'm quite happy how well it has been taken already
<pitti> hughsie fixed the colord tests, I was looking into the two gst failures with tpm, and pwhitnall already fixed friends
<plars> mlankhorst: http://paste.ubuntu.com/1639744/
<cjwatson> siretart: The easiest solution is probably to write out (from preseed/early_command or partman/early_command; if the former then you'll need a mkdir -p as well) an executable hook in /lib/partman/finish.d/ starting with a two-digit number greater than 20
<cjwatson> Say, /lib/partman/finish.d/99create_some_files
<mlankhorst> plars: doesn't seem to detect the vesa bios at all for some reason
<stgraber> doko: you broke upstart!
<xnox> stgraber: how =) ?
<stgraber> doko: or to be precise, the new gcc causes one of the upstart tests to fail and cause a build hang ;)
<xnox> stgraber: so FSF broke upstart ;-)
<ogra_> xnox, fsf ?
<ogra_> xnox, was doko renamed ?
<mlankhorst> plars: any chance it could be a configuration issue? what if you set the precise iso as a quantal image, which would probably make sense since it's quantal kernel  + xserver
<plars> mlankhorst: setting the precise iso as a quantal image? I'm not sure what you mean
<xnox> ogra_: *giggle*
<plars> mlankhorst: I'm sure I'm pointing at the right image if that's what you mean
<cjwatson> plars: How did you go about upgrading to mlankhorst's new server package?
<plars> cjwatson: I added the repository and did apt-get update/dist-upgrade
<mlankhorst> plars: I mean it would probably count as quantal from virtualbox's point of view
<plars> mlankhorst: I don't think virtualbox knows or cares
<mlankhorst> well my only guess is a kernel regression now
<cjwatson> mlankhorst: I was away for a while.  Have you had any positive reports regarding this virtualbox-related change?
<ogra_> or oracles secret plan of undermining established linux dstros
<ogra_> conspiracy !
<mlankhorst> cjwatson: what I just said ^
<cjwatson> Uh - I see your responses to plars; I was asking whether you'd had any positive responses as well as that negative one
<mlankhorst> well it fixes my connectorless setup, just not the issue here it seems
<plars> psivaa: any chance you can give that ppa a try again? just boot the image, add-apt-repository, update/dist-upgrade, and restart lightdm should do it
<psivaa> plars: sorry i have already tried that and i get the same failure as yours
<plars> ok
<plars> thanks for confirming
<psivaa> plars: yw, sorry dint do it before since it was the same outcome :)
<cjwatson> OK, so it sounds like the answer here is a release note
<mlankhorst> I suspect it's a bug somewhere else though
<mlankhorst> cjwatson: https://bugzilla.redhat.com/show_bug.cgi?id=785652 ?
<ubottu> bugzilla.redhat.com bug 785652 in xorg-x11-drv-vesa "Xserver does not start in virtualbox" [Unspecified,Closed: errata]
<tjaalton> libpciaccess-lol-dev-port.patch :)
<mlankhorst> sounds good
<mlankhorst> I'll throw up a libpciaccess in a bit, food first
<mlankhorst> can I sru the xorg-server headless fix too then in that case?
<cjwatson> Sure, but I'm only going to take the libpciaccess one for .2, unless you have a very good argument to the contrary
<mlankhorst> same failure mode under different conditions :)
<mlankhorst> bbiab
<cjwatson> Well, sure; but the conditions for the libpciaccess one are only marginally a .2 blocker as it is
<cjwatson> Can you describe the conditions for the other fix in detail?
<cjwatson> I have <2 days until I need to release 12.04.2, so I want to have a good reason for any risk
<cjwatson> And avoid burning out testers
<happyaron> jbicha: unfortunately ibus-table seems to need a revert.
<happyaron> jbicha: I'll wait for a few days to see what's upstream's reaction, if there is patch then all good.
<jbicha> happyaron: ok, thanks!
<SpamapS> definitely something broken in newer google chrome. It just sits there.. :-P
<mlankhorst> cjwatson: it's just when no outputs are found, for example when you disconnected all monitors, the cd will fail to boot whereas 12.04.1 lts works, but sure it can wait I suppose
<fishor_> hallo all, are there any reason why libapt do not use openssl? I just wundered why http porcess takes ~30% of my intel i5-3317. Perf shows this result:
<fishor_>  14,81%  http  libapt-pkg.so.4.12.0  [.] SHA512_Transform(_SHA512_CTX*, unsigned long const*)                                        â
<fishor_>   8,11%  http  libapt-pkg.so.4.12.0  [.] SHA1Transform(unsigned int*, unsigned char const*)                                          â
<fishor_>   5,62%  http  libapt-pkg.so.4.12.0  [.] MD5Transform(unsigned int*, unsigned int const*)
<Sarvatt> plars: can you test https://launchpad.net/~sarvatt/+archive/sru7/ out?
<plars> Sarvatt: sure, one moment
<cjwatson> mlankhorst: OK - it's certainly a bug and should be fixed for .3, but it's not a blocker for .2 so I'm not going to risk it
<mlankhorst> ok sure
 * cjwatson <- conservative today
<Sarvatt> 2 hours to build, ugh
<fishor_> this funktions in libapt do not have any optimisation. beside  current openssl has avx optimisation for this hashes
<mlankhorst> Sarvatt: copying to my ppa
<mlankhorst> I have a build bump there
 * Sarvatt should have urgency=critical'ed it :)
<cjwatson> fishor_: The apt developers are on #debian-apt on irc.oftc.net; or you could file a bug
<fishor_> cjwatson, ok thx
<mlankhorst> Sarvatt: building now ;P
<mlankhorst> https://launchpad.net/~mlankhorst/+archive/ppa/+packages
<cjwatson> fishor_: There are probably licensing difficulties with using OpenSSL
<cjwatson> fishor_: APT is GPLed and the OpenSSL licence is incompatible with that
<plars> Sarvatt: I'm watching the ppa from mlankhorst and will pull it in from there as soon as that finishes
<mlankhorst> it fails to build
<plars> doh
<doko> xnox, maybe, I think we don't use it yet
<xnox> doko: you respond right about when it's almost finished building here and passing sanity checks before an upload =)
<xnox> doko: i'll upload anyway, but good to know it's not on the critical path.
<cjwatson> mlankhorst: your build-dependencies are weak, old man :)
<mlankhorst> that's why it was going to a ppa first!
<coder2> where can i get the WebKit reference manual for python? developing a debian browser
<ogra_> coder2, see /topic
<ogra_> coder2, better try #ubuntu-app-devel
<Sweetshark> Hmm, some libreoffice infra shouts at me that I should install pittis postgresql updates. Should i trust them?
<coder2> ogra_, okay sorry thanks
 * ogra_ hands Sweetshark http://www.pctips.in/2013/02/installing-open-office-in-ubuntu.html and runs
<barry> dobey: hey there.  had any time to look at the code?  anything i can do?
 * Sweetshark slowly forms foam around the mouth ...
<Sweetshark> *grrrr*
<sarnold> wow, it's amazing what people will publish as "tips"
 * ogra_ giggles
<siretart> cjwatson: ah, that sounds promising. I've now installed a copy script to /usr/lib/base-installer.d, which *seems* to work as well.
<siretart> cjwatson: I had hoped that something like partman/late_command or something existed
<plars> mlankhorst, Sarvatt: seems to work with the updated libpciaccess0 now :)
<mlankhorst> yay
<roadmr> \o/
<cjwatson> siretart: base-installer.d should work too, yes.  And no, afraid not.
<cjwatson> mlankhorst: precise-proposed upload on its way I hope? :)
<mlankhorst> I can't upload, and it was sarvatt who did the packaging :-)
<cjwatson> Sarvatt: ^-
<cjwatson> (12.04.2 blocker so I'd like it ASAP)
<mlankhorst> he can't upload either )
 * ogra_ points mlankhorst to rge patch pilots ;)
<ogra_> *the
<xnox> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Open | Dev' 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: sconklin
<mlankhorst> hahahahaha
<ogra_> LOL
 * xnox off to volleyball
<cjwatson> sigh, ok, give me the source package and I can sponsor/review it
<cjwatson> would be better if somebody else sponsored it, but ...
<siretart> cjwatson: either way, it seems to have worked for me. thanks for your assistance!
<barry> Laney: ping
<mlankhorst> cjwatson: tjaalton is sponsoring :)
<Laney> sup barry
<barry> Laney: hi.  i'm looking at a couple of things in sessioninstaller.  bug 1084061
<ubottu> bug 1084061 in sessioninstaller (Ubuntu) "Port to GStreamer 1.0" [Undecided,New] https://launchpad.net/bugs/1084061
<barry> Laney: looks like that your mp just got landed in trunk right?
<Laney> yep
<barry> oh, about 2hrs ago?!
<Laney> something like that, correct
<barry> Laney: so the non-ubuntu bug task could be fix committed then?
<Laney> right
<Laney> I'll cherry-pick it into raring tomorrow most likely
<barry> Laney: perfect.  will you drop the depends on python-gst0.10 then?
<Laney> for sure
<barry> fantastic.  that should drop the ubuntu-desktop task from python-gst0.10 i think
<barry> Laney: since i think si was the last dep
<barry> *rdep
<tjaalton> cjwatson: uploaded
<barry> Laney: that makes me very happy :)
 * Laney does $ reverse-depends -c main src:gst0.10-python
<Laney> that and pitivi which is kept in main by the weird usb seed
<Laney> (but isn't on any media)
<barry> Laney: yep
<barry> once again, xapian is the last thing to stop a py3 port :/
<cjwatson> Sarvatt: You decided we didn't need the cloexec patch linked from the bug description?
<cjwatson> Sarvatt: I guess there was already a leak before ...
<cjwatson> OK, accepted
<cjwatson> plars: Which architecture would be most convenient for QAing the package in the archive with a custom image build?
<plars> cjwatson: is it something I can test in a vm? if so, amd64 or i386 - doesn't matter
<dobey> barry: hey. i think the upstream code is wrong in sign(). i need to look at the spec again now though
<cjwatson> plars: Weren't you already testing in virtualbox?
<plars> cjwatson: I was, so if this is about the libpciaccess fix then? I tested the one in the ppa and would be happy to test both images as soon as they are available
<cjwatson> This is the libpciaccess fix
<cjwatson> OK, I need to go out now but when I get back (couple of hours) I'll build a one-off i386 image and pass it to you for testing, if that's OK
<barry> dobey: interesting.  if you file a bug upstream, let me know so i can follow it
<cjwatson> I think we only need one arch
<dobey> barry: ok, so the oauthlib api is really weird, trying to read the code and actually understand it is incredibly hard, and i'm tired of dealing with this so i gave it a +1 as it seems to be the only way to make it work right, because the api and code are just weird there
<barry> dobey: ack.  could you file a bug upstream?  if not that's okay, but i probably can't express exactly what's weird about it in a bug description
<dobey> barry: well, i'm not sure i would be good at expressing it either unfortunately. and i really don't want to waste any more time on it right now. too many other things i need to get done, and no time to do them :(
 * barry nods :(
<tziOm> I dont understand how you guys can keep kernels that panics in 12.10 w/o updating
<tziOm> 3.5.0 all versions available segfaults after 30 minutes with exim/spamass/clamav
<tziOm> after some googleing, it seems you also KNOW ABOUT IT!
<penguin42> tziOm: Help in #ubuntu, kernel in #ubuntu-kernel, if there's a bug report you're referencing please at least say the number
<tziOm> for example this one: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1081054
<ubottu> Ubuntu bug 1081054 in linux (Ubuntu Quantal) "Kernel panic running latest ubuntu 12.10 kernel version (3.5.0-17-generic) under xen." [Medium,Fix released]
<penguin42> tziOm: It's been fixed - what's your problem?
<tziOm> Its not that one
<tziOm> anyway, fixed with 3.8.0rc7
 * penguin42 fails to read your mind as to what problem you're referring to
<tziOm> tried all 3.5.0 releases before I did 3.8
<penguin42> tziOm: If you've got a panic file a bug; if you look at the example you gave that bug was fixed!
<stokachu> in precise could we essentially symlink /proc/mounts to /etc/mtab and disable writing of mtab  within mount/unmount?
<stokachu> we are seeing an issue where mtab is leaving behind a stale mtab~ file during unmounts via automounter
<hallyn> jdstrand: on bug 1101978 (spice MIR), the version now in raring addresses the warning (synced in debian, and pushed upstream).  Does MIR team await another comment from you?
<ubottu> bug 1101978 in spice (Ubuntu) "[MIR] spice" [Undecided,In progress] https://launchpad.net/bugs/1101978
<stokachu> this is of course on a system that contains 14k automounts :\
<jdstrand> hallyn: I'll add another and mark  fix committed then
<stokachu> as per the documentation for mount this seems feasible but not sure of any other side effects then the one about 'user' option not working
<hallyn> jdstrand: thanks!
<jdstrand> hallyn: can you ping me when you adjust your build-deps then I'll adjust the overrides
<hallyn> jdstrand: you mean in qemu?
<jdstrand> hallyn: yeah. by doing that and uploading, you'll need spice to be moved for it to build
<hallyn> jdstrand: will do, thanks.
<hallyn> (will ping you when i push that, that is)
<slangasek> GunnarHj: hey, sorry for the mid-air collision on the lightdm branches.  I'll have a look at your gdm branch today
<GunnarHj> slangasek: Hi Steve, that MP is identical, so I guess you'll change it then.
<slangasek> ah, probably
<slangasek> GunnarHj: do you see any problems with the solution I uploaded in lightdm?  I'm reasonably sure this does what we need, but I'm alert for the possibility that some other pam module could (wrongly) be relying on pam_env output
<GunnarHj> slangasek: But if all the pam_env calls are at the end, then how about parsing /etc/default/locale, which of course needs to be done early?
<slangasek> GunnarHj: why does it need to be done early?
<GunnarHj> slangasek: To control the locale at startup and on the login screen.
<slangasek> GunnarHj: I don't believe that comes from pam_env
<slangasek> GunnarHj: pam_env's output is only exported to the process environment at the end of the stack - not in the middle
<slangasek> setting the locale in the pamh envlist doesn't affect the process locale at all
<slangasek> mind you, I'm talking theory here
<GunnarHj> slangasek: Hmm... You called my attention to PAM and /etc/default/locale in bug 1035498.
<ubottu> bug 1035498 in language-selector (Ubuntu Precise) "language-selector updates /etc/environment when it shouldn't, and gives results that are inconsistent with an initial install" [High,Triaged] https://launchpad.net/bugs/1035498
<GunnarHj> slangasek: But I can test with your lightdm upload.
<dobey> stgraber: ping
<stgraber> dobey: pong
<dobey> stgraber: hey, maybe my timing just sucks. but i sent a mail to devel-permissions a week ago, and haven't seen any reply, and the request hasn't been completed. not sure what i should do (or who i should bug exactly at the moment, given the DMB is changing)
<stgraber> dobey: is that about software-center?
<dobey> stgraber: yes, that one
<stgraber> right, so in short we don't feel like software-center really makes sense under the ubuntuone package set or even under the ubuntuone project on LP (but we can't do much about that one)
<stgraber> so we need to either create a separate set or rename and change the description of the ubuntuone packageset
<ScottK> Seems to me like a completely different thing.
<stgraber> so that's why it's been taking a bit more time than the last few packages :)
<GunnarHj> slangasek: Logging out to reboot.
<robert_ancell> slangasek, wont the change to lightdm in bug 952185 cause login prompts to be untranslated?
<ubottu> bug 952185 in lightdm (Ubuntu) "~/.pam_environment not parsed by default" [High,In progress] https://launchpad.net/bugs/952185
<stgraber> ScottK: yeah, it's a case where it's the same team maintaining both now, but based on discussion without the DMB, that doesn't justify the addition
<slangasek> robert_ancell: I'm aware of no reason that should be true
<ScottK> stgraber: We don't have maintainers in Ubuntu.
<slangasek> robert_ancell: there is *nothing* between the invocation of pam_env and the invocation of the other pam auth modules that would push these env variables to the environment
<stgraber> dobey: if you want to resolve the problem quickly, I'd recommend you ask for PPU for this package on devel-permissions
<stgraber> dobey: we now have a lightweight PPU process where people with existing PPU can be granted additional upload rights without showing up at a meeting
<dobey> hmm, ok
<stgraber> dobey: and I think in this case, it'd make sense for us to grant you those upload rights directly while we figure out what to do with the set
<dobey> i don't think a separate set or renaming the u1 set is the answer
<stgraber> well, I think you'll have an hard time convincing anyone that software-center is part of UbuntuOne so simply including it isn't the answer either :)
<robert_ancell> slangasek, is what you mean that the pam_putenv () calls from pam_env isn't going to affect the gettext calls in the other modules anyway? Which looking into seems to be the case
<slangasek> robert_ancell: correct.  It's only once the application does the for i in pam_getenvlist: putenv(i) that these get exported
<dobey> stgraber: ok, well, sent PPU request then
<GunnarHj> slangasek: I did some tests with lightdm, and the locale environment seems to be set properly. Apparently I was wrong.
<dobey> stgraber: thanks. i guess we can revisit the packageset request in a couple weeks then
<slangasek> robert_ancell: so I'm double-checking in a VM now, but I believe we'll find that the only l10n of the login prompts is whatever is in /etc/default/locale, not per-user settings from .pam_environment; and the /etc/default/locale is being read by something other than pam_env.so
<slangasek> GunnarHj: great, thanks for confirming
<robert_ancell> slangasek, yes, I'd expect that to
<cjwatson> plars: If you're still around, please could you test that http://cdimage.ubuntu.com/custom/20130212/precise-desktop-i386.iso works in virtualbox?
<cjwatson> (temporary link)
<plars> cjwatson: will do, one moment
<hallyn> hm, odd, do-release-upgrade from quantal to raring hung on memtest86+.post (task became defunct)
<plars> cjwatson: my connection bounced it seems, so if you replied, I didn't get it
<slangasek> hallyn: do you have any lvm snapshots currently open?
<cjwatson> plars: Last I saw from you was "will do, one moment", which didn't seem to require a response :)
<hallyn> slangasek: open as in mounted? no.
<slangasek> hallyn: open as in existent
<hallyn> yeah probably
<hallyn> yeah, 3
<slangasek> hallyn: reproducible here
<hallyn> feh
<plars> cjwatson: ah ok... it must have started having problems a long time ago then, here's the rest:
<plars> <plars> cjwatson: well, it got me at least to the screen asking if I wanted to try ubuntu or install, then when I selected to try ubuntu it took me to a dialog saying "The system is running in low-graphics mode"
<plars> <plars> if I press ok there it asks if I want to run in low graphics mode for just one session, reconfigure graphics, troubleshoot the error, or exit to console login
<hallyn> slangasek: is there an open bug about that?
<slangasek> hallyn: I haven't filed a bug report; can you do one?
<hallyn> will do
<slangasek> hallyn: I'm almost positive it's the snapshots causing it, because the two symptoms I had were 1) memtest postinst breaking in os-prober, 2) couldn't end my schroot sessions because of 'device busy'
#ubuntu-devel 2013-02-13
<hallyn> i'll remove the snapshots and re-test
<cjwatson> plars: Is it possible to get as far as a working-ish session?
<plars> cjwatson: I'm trying the various options at the moment, running in low graphics mode doesn't seem to work
<doko> stgraber, https://bugs.launchpad.net/gcc/+bug/1123588
<ubottu> Ubuntu bug 1123588 in upstart (Ubuntu) " [4.7 Regression] wrong code with the fix for PR53844" [Undecided,New]
<plars> cjwatson: neither does reconfiguring
<plars> cjwatson: so no it seems
<cjwatson> plars: OK, so this sounds to me as though we shouldn't bother respinning everything for this because it won't be a worthwhile improvement
<plars> cjwatson: it is at one point trying to LoadModule: "vboxvideo" in the xorg log and failing to find it it seems
<cjwatson> Ah, for details you'll need to talk to X people :)
<cjwatson> Of which I am not one
<plars> cjwatson: ok, was the libpciaccess fix the only thing different in this image?
<plars> cjwatson: I can update the bug
<cjwatson> plars: No, it was a general build against -proposed
<hallyn> slangasek: bug 1123594
<cjwatson> It should have been the only relevant thing, though
<ubottu> bug 1123594 in memtest86+ (Ubuntu) "lvm snapshots cause memtest86+.post to become defunct" [Undecided,New] https://launchpad.net/bugs/1123594
<cjwatson> ogasawara: Do you think you could add specific directions to either https://wiki.ubuntu.com/PrecisePangolin/ReleaseNotes/UbuntuDesktop#LTS_Hardware_Enablement_Stack or https://wiki.ubuntu.com/Kernel/LTSEnablementStack (or possibly both) about how to opt into the kernel and X enablement stacks on upgrade?
<cjwatson> I just noticed it says "the appropriate meta package" and the like but doesn't actually give commands or specific package names
<penguin42> that's interesting; first time I'd read about the HES; I guess that means that bugs found relatively late in Quantal kernel/X become more important because their about to find their way into LTS
<cjwatson> penguin42: for 12.04.3 it'll be raring-based (3.8)
<penguin42> cjwatson: Yes; I'm just thinking that there has been a tendency to worry more about fixing something in an LTS because it's going to have to stay for the long run, but a bug in a non-LTS might not be SRUd for example
<penguin42> it might also make bug triage interesting to try and figure out which series people are actually running when they say it works/fails for them on precise
<hallyn> jdstrand: qemu with spice build-dep has been dput'ed
<jdstrand> hallyn: ack
<Dedunu> hi i need a help
<Dedunu> i bzr branched a source of gnome-power-manager
<Dedunu> but when im going to build it it gives error althoug i do it on original source (with out any change)
<Dedunu> can anybody help me?
<chilicui1> Dedunu: which error?, when compiling software you must ensure you have all the dependencies satisfied
<Dedunu> debian/rules:6: /usr/share/gnome-pkg-tools/1/rules/uploaders.mk: No such file or directory
<Dedunu> debian/rules:7: /usr/share/gnome-pkg-tools/1/rules/gnome-get-source.mk: No such file or directory
<Dedunu> make: *** No rule to make target `/usr/share/gnome-pkg-tools/1/rules/gnome-get-source.mk'.  Stop.
<Dedunu> dpkg-buildpackage: error: fakeroot debian/rules clean gave error exit status 2
<Dedunu> debuild: fatal error at line 1350:
<Dedunu> dpkg-buildpackage -rfakeroot -d -us -uc -S failed
<Dedunu> bzr: ERROR: The build failed.
<Dedunu> chilicui1: error is like this
<Dedunu> i havent created a chroot enviroment is that the problem?
<chilicui1> Dedunu: did you run $ apt-get build-dep before ? , how did you found that problem?, did you use $ dpkg-buildpackage -rfakeroot -us -uc #to compile it?
<chilicui1> Dedunu: no, it should work in your system if you meet all the dependencies, the pkg you're trying to compile is the same version of the you current ubuntu setup?, I mean, it may be a little be harder to compile a pkg which is suppose to be installed in ubuntu raring from ubuntu precise
<Dedunu> ah is that so
<Dedunu> i used bzr builddeb
<Dedunu> i installedpackaging-dev
<Dedunu> packaging-dev
<chilicui1> Dedunu: mm, it's ok, bzr builddeb runs dpkg-buildpackage, so now just be sure you installed the dependencies.., $ apt-get build-dep #also as you've already told.., you branched.., therefore the code you're trying to run should be run against a raring machine, please be sure to compile it in that environment, otherwise the deps may not be the versions you need
<ogasawara> cjwatson: I updated both https://wiki.ubuntu.com/PrecisePangolin/ReleaseNotes/UbuntuDesktop and https://wiki.ubuntu.com/Kernel/LTSEnablementStack with instructions for how to opt into (ie manually install) the kernel and X  enablement meta pkgs
<Dedunu> chilicui1: ok thank you
<Dedunu> ill try on raring environment
<Dedunu> thanks a lot
<chilicui1> Dedunu: have fun, good luck
<pitti> Good morning
<Dedunu> good morning
<dholbach> good morning
<Dedunu> dholbach: hi
<Dedunu> all the day im struggling with a
<Dedunu> papercut
<Dedunu> i found the bug in that fixed it on code
<Dedunu> but i can't build it yet
<cjwatson> ogasawara: Great, thanks
<Dedunu> chilicui1: stil problem is not solved i can builddeb
<Dedunu> :(
<hrw> infinity: any chances to get chromebook stuff from NEW?
<ogra_> ++
<Dedunu> please can anybody help me?
<seb128> Dedunu, hi, if you don't state what help you are looking for, not likely
<Dedunu> I got source with bzr
<Dedunu> of gnome-power-manager
<Dedunu> and found the place to edit also i edited it
<Dedunu> when im going to build using bzr bd -- -S
<Dedunu> it gives and error
<Dedunu> dpkg-buildpackage: source package gnome-power-manager
<Dedunu> dpkg-buildpackage: source version 3.6.0-1ubuntu1
<Dedunu> dpkg-buildpackage: source changed by Dedunu Dhananjaya <admin@dedunu.info>
<Dedunu>  dpkg-source --before-build gnome-power-manager-3.6.0
<Dedunu>  fakeroot debian/rules clean
<Dedunu> debian/rules:6: /usr/share/gnome-pkg-tools/1/rules/uploaders.mk: No such file or directory
<Dedunu> debian/rules:7: /usr/share/gnome-pkg-tools/1/rules/gnome-get-source.mk: No such file or directory
<Dedunu> make: *** No rule to make target `/usr/share/gnome-pkg-tools/1/rules/gnome-get-source.mk'.  Stop.
<Dedunu> dpkg-buildpackage: error: fakeroot debian/rules clean gave error exit status 2
<Dedunu> debuild: fatal error at line 1350:
<Dedunu> dpkg-buildpackage -rfakeroot -d -us -uc -S failed
<Dedunu> bzr: ERROR: The build failed.
<Dedunu> those are end parts
<Dedunu> im using ubuntu 12.04 LTS and i also ran pbuilder-dist raring create before everything
<Dedunu> this is my first fix
<Dedunu> seb128: can you tell me what should i do?
<RAOF> Dedunu: Have you run âapt-get build-dep gnome-power-managerâ?
<Dedunu> nop
<Dedunu> i want to build my code
<Dedunu> i fixed a problem in it
<seb128> what RAOF said
<seb128> run that, it will install the packages needed to build gnome-power-manager
<seb128> janimo, hey
<Dedunu> than you ill try
<seb128> janimo, https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/1123930
<ubottu> Ubuntu bug 1123930 in gnome-settings-daemon (Ubuntu) "memleak in plugins/orientation/gsd-orientation-manager.c" [High,New]
<seb128> janimo, can you have a look? it's an important leak in your orientation patch ... also please go through review from now on rather than direct upload, reviews help to catch such errors before they hit users and have to go back through reports
<Dedunu> seb128: RAOF: now error is change
<Dedunu> d
<Dedunu> sorry i would be much obliged to you if you could help me
<Dedunu> dpkg-source: warning: Version number suggests Ubuntu changes, but Maintainer: does not have Ubuntu address
<Dedunu> dpkg-source: warning: Version number suggests Ubuntu changes, but there is no XSBC-Original-Maintainer field
<Dedunu> dpkg-source: info: using source format `3.0 (quilt)'
<Dedunu> dpkg-source: info: building gnome-power-manager using existing ./gnome-power-manager_3.6.0.orig.tar.xz
<Dedunu> dpkg-source: info: local changes detected, the modified files are:
<Dedunu>  gnome-power-manager-3.6.0/src/gpm-statistics.c
<Dedunu> dpkg-source: error: aborting due to unexpected upstream changes, see /tmp/gnome-power-manager_3.6.0-1ubuntu1.diff.dDUvhp
<Dedunu> dpkg-source: info: you can integrate the local changes with dpkg-source --commit
<Dedunu> dpkg-buildpackage: error: dpkg-source -b gnome-power-manager-3.6.0 gave error exit status 2
<Dedunu> debuild: fatal error at line 1350:
<Dedunu> dpkg-buildpackage -rfakeroot -d -us -uc -S failed
<Dedunu> bzr: ERROR: The build failed.
<pitti> Dedunu: for applying changes to the upstream source, please see http://developer.ubuntu.com/packaging/html/patches-to-packages.html; you can't do that in-plce
<pitti> "place"
<RAOF> Dedunu: You probably want to use a pastebin for such a lot of text.
<seb128> Dedunu, please stop doing big pastes on the channel, use http://paste.ubuntu.com for that
<Dedunu> sorry im new to irc
<Dedunu> thank you
<Dedunu> seb128: RAOF: i patched it using quilt after that what should i do
<Dedunu> im sorry
<Dedunu> pitti: i did it after that what should i do
<seb128> Dedunu, you should be able to run the command then
<Dedunu> which command bzr bd -- -S
<Dedunu> it is again failing
<seb128> bzr revert your inline change if you put it in a quilt patch
<seb128> bzr revert src/gpm-statistics.c
<seb128> Dedunu, what issue are you working on btw,
<seb128> ?
<Dedunu> https://bugs.launchpad.net/hundredpapercuts/+bug/923292
<ubottu> Ubuntu bug 923292 in One Hundred Paper Cuts "shortcut for closing power statistics app not working" [Low,Confirmed]
<seb128> good ;-)
<Dedunu> oh im sorry
<Dedunu> omg
<Dedunu> seb128: i reverted it
<Dedunu> seb128: ubottu: is that uploaded to lp?
<seb128> Dedunu, ubottu is a bot, it's not going to reply to questions ;-)
<Dedunu> im realy new
<seb128> Dedunu, you should be able to bzr bd if you reverted it
<Dedunu> im very sorry if i annoy you
<seb128> Dedunu, no, you don't, everybody has to start and has questions when starting, that's ok ;-)
<seb128> Dedunu, I would just ignore IRC if I was annoyed ;-)
<Dedunu> thanks
<Dedunu> it hasn't revert things
<seb128> how so?
<Dedunu> my lines are there stil
<seb128> can you copy the log to http://paste.ubuntu.com and give the url here?
<Dedunu> lines i added are there
<seb128> with a bzr diff and bzr status output as well
<Dedunu> http://paste.ubuntu.com/1643366/
<Dedunu> bzr status is this
<Dedunu> bzr diff gives nothing
<Dedunu> shall i start from the begining?
<Dedunu> first i init a repo
<seb128> yeah, not sure what you did
<seb128> wait
<Dedunu> shall i explain you what i did?
<seb128> yes please
<seb128> basically you want to
<seb128> bzr branch ubuntu:gnome-power-manager
<seb128> export QUILT_PATCHES=debian/patches
<Dedunu> yeah
<seb128> bzr bd-do
<seb128> quilt new 923292-fix.patch
<seb128> quilt add src/gpm-statistics.c
<seb128> edit src/gpm-statistics.c
<seb128> quilt refresh
<seb128> exit 0
<seb128> bzr add debian/patches/923292-fix.patch
<seb128> bzr bd
<seb128> dch -i "updated changelog for fix"
<seb128> as well maybe
<Dedunu> how can i test it i want to see whether i works
<Dedunu> bzr bd will it give a output
<Dedunu> ?
<Dedunu> i mean a .deb
<seb128> Dedunu, sorry, that's for slightly different bzr format ... ignore the bzr bd-do and exit0 lines
<seb128> Dedunu, basically just follow http://developer.ubuntu.com/packaging/html/patches-to-packages.html and that should work
<seb128> you should get a patch in debian/patches with your diff
<seb128> Dedunu, yes, bzr bd will give you a .deb
<Dedunu> hmm
<Dedunu> then i cann install deb and see whether it works?
<Dedunu> other wise build will fail
<Dedunu> ?
<seb128> you can install the deb and test it yes
<seb128> Dedunu, build will fail? just try to start from scratch following http://developer.ubuntu.com/packaging/html/patches-to-packages.html and tell me if you hit an issue
<Dedunu> ok
<Dedunu> thank you
<Dedunu> very much
<seb128> you're welcome
<Laney> bah
<seb128> Laney, bah?
<Laney> seems the qemu update broke launching VMs
 * xnox notes to himself not to upgrade
<Daviey> Laney: who does THAT?
<Laney> xnox: what does getfacl /dev/kvm show for you?
<Daviey> Laney: we can't cater for every edge case.
<Laney> Daviey: No worries, I heard arch is better anyway.
<xnox> Laney: http://paste.ubuntu.com/1643467/
<Laney> merci, same as me
<xnox> (where tdlk is my user account, naturally)
<xnox> Laney: although I may already have the new-new qemu stack
<Daviey> fn'ar, Laney - as xnox is pointing to.. ownership is a problem we have been seeing for a little while
<Daviey> something seems racey.
<seb128> Laney, oh, that got updated, sorry I didn't see it in the middle of all those haskell uploads :p
<xnox> Laney: do you use command line? then kvm needs -kvm option.
<Laney> xnox: virt-manager or virsh
<Laney> lemme file le bug
<xnox> Laney: ack. that should "just work always"(tm)
<Daviey> xnox: erm, it shouldn't.. it should use kvm by default, and gracefully fall back to non-accelerated
<Laney> bug #1123998
<ubottu> bug 1123998 in qemu (Ubuntu) "Can't launch VMs from virt-manager or virsh: Could not access KVM kernel module: Permission denied" [Undecided,New] https://launchpad.net/bugs/1123998
<Dedunu> seb128: i followed until bzr commit
<Dedunu> after that i bzr bd
<Dedunu> it got failed
<Dedunu> before changing i tried to build it also got failed
<seb128> Dedunu, can you pastebin the log with the fail?
<Dedunu> seb128: http://paste.ubuntu.com/1643504/ yeah sure this is before change build fail
<Dedunu> it is about failed debsign
<Dedunu> what is it?
<seb128> Dedunu, that didn't fail
<seb128> Dedunu, you should have a deb in build-area/
<Dedunu> ok
<Dedunu>  ill
<Dedunu> check
<seb128> Dedunu, the message is confusing, it failed to sign the files, which is needed if you want to upload to Ubuntu (because we need to check who has upload rights, etc)
<Dedunu> ok
<seb128> Dedunu, but signing is not needed for local builds
<Dedunu> thanks it is there
<Dedunu> now i changed as on tutorial
<Dedunu> and bzr commit also i ran
<Dedunu> now how should i test my changes?
<Dedunu> i got my old deb
<Dedunu> where the patch now?
<Dedunu> seb128: how to apply my changes on my system now?
<seb128> Dedunu, install the deb (sudo dpkg -i build-area/gnome-power-manager*.deb)
<Dedunu> is that include my changes?
<seb128> if you did a build with your patch commited etc it should
<seb128> Dedunu, what's the deb version?
<Dedunu> 3.6.0-1
<seb128> the name of the deb
<seb128> what is the current version in debian/changelog?
<Dedunu> how to check it
<seb128> Dedunu, editor debian/changelog
<seb128> in the checkout of the source
<seb128> the first line
<Dedunu> there's nothing inside it
<Dedunu> im sorry
<Dedunu> i developed c/c++ things
<Dedunu> never worked with those bzr
<seb128> no worry, there is a learning curve ;-)
<seb128> are you sure you are in the checkout dir?
<seb128> there is a debian/changelog and it has content for sure in there
<rbasak> Is there a standard way for an upstart job's pre-script to log a message to the terminal when it fails? Writing to stdout or stderr redirects to /var/log/upstart/<job>.log, which is fine, but isn't so helpful to a sysadmin starting a job by hand. Eg. bug 1121874.
<ubottu> bug 1121874 in mysql-5.5 (Ubuntu) "MySQL launch fails silently if < 4MB of disk space is available" [Medium,Triaged] https://launchpad.net/bugs/1121874
<Dedunu> seb128: 3.6.0-1ubuntu1
<Dedunu> i was in buildare
<Dedunu> a
<seb128> Dedunu, ok, so the deb you build should have this number
<seb128> Dedunu, try running bzr bd again ?
<seb128> 3.6.0-1 was the version you first built
<seb128> or you maybe have the 2 debs in build-area if built both?
<ogra_> rbasak, there is a "console" option that can be set to print to plymouth
<Dedunu> seb128: http://paste.ubuntu.com/1643532/
<Dedunu> this is build
<Dedunu> i think its failed?
<ogra_> rbasak, http://upstart.ubuntu.com/cookbook/#console
<rbasak> ogra_: looking, thanks!
<seb128> Dedunu, yeah, can you pastebin the output of both "bzr diff" and "bzr status"?
<ogra_> i think "console log" or "console output"
<Dedunu> seb128: bzr status http://paste.ubuntu.com/1643539/
<Dedunu> bzr diff nothing
<seb128> Dedunu, bzr add debian/patches/series and try bzr bd again
<xnox> bzr add debian/patches .pc
<xnox> (also quilt push, but one needs to setup the series file pointer...)
<seb128> xnox, he followed http://developer.ubuntu.com/packaging/html/patches-to-packages.html
<seb128> which recommends
<seb128> bzr add debian/patches/name
<seb128> bzr add .pc/*
<seb128> that doesn't work for a package that had no patch before and the series not in the vcs...
<Dedunu> seb128: http://paste.ubuntu.com/1643540/
<xnox> sounds about right, if there was a quilt push and/or commit (bzr bd does quilt push)
<Dedunu> i took little bit of time
<seb128> Dedunu, ok, great, it's failing in your patch on a code error
<xnox> heh, true about first patch ever ;-)
<Dedunu> ok than
<Dedunu> thanks ill check it
<seb128> Dedunu, sorry it was tedious, you should be set now
<seb128> bzr commit the addition of the series file
<seb128> Dedunu, you might just want to iterate builds by doing ./configure --prefix=/usr && make in your checkout and do "make" until you got the patch right
<seb128> rather than going through a bzr bd every time
<Dedunu> seb128: ok thanks
<seb128> then do it properly once you are happy with the diff and get it to build
<rbasak> ogra_: that's making it go to /dev/console rather than the tty "sudo start mysql" is connected to
<rbasak> Is the answer just that jobs aren't supposed to talk to root's terminal for manual jobs?
<xnox> rbasak: hm? in recent upstart all jobs stdout/stderr is redirected to /var/log/upstart/job.log
<ogra_> might be, ask jodh
<xnox> rbasak: and stdin is /dev/null
<rbasak> xnox: yes, but that doesn't seem optimal
<rbasak> (in this case)
<xnox> rbasak: it is for most things
<rbasak> xnox, jodh: in a pre-script, if it cannot continue, then it makes sense to tell root directly on his terminal if he called "start <job>", right?
<xnox> rbasak: lets start from the beginning. What's your usecase / problem? and maybe upstart can help solving it in a different way =)
<rbasak> xnox, jodh: bug 1121874
<ubottu> bug 1121874 in mysql-5.5 (Ubuntu) "MySQL launch fails silently if < 4MB of disk space is available" [Medium,Triaged] https://launchpad.net/bugs/1121874
<ogra_> you might be able to add a TTY=$(tty) call and redirect explicitly to it ... not sure, depends if you have an environment thats handed to upstart in that case
<rbasak> I've amended it to echo to stderr, and that ends up in /var/log/upstart/mysql.log just fine. But I think it makes sense to do better and write to root's  terminal too
<xnox> rbasak: usually pre-start should issue stop command, and then the output from strart command will be: foo is stopped, rather than started.
<rbasak> Yes, but the reason for the failure isn't obvious. And /var/log/upstart/mysql.log isn't timestamped (though I can run date of course).
<xnox> rbasak: the problem is that it uses "exit" instead of "stop" which would correctly print the message that the job is not starting.
<xnox> it will not, however print why it didn't start. But at least there will be some feedback.
<rbasak> With exit 1: $ sudo start mysql
<rbasak> start: Job failed to start
<rbasak> With stop: $ sudo start mysql
<rbasak> mysql stop/pre-start, process 18925
<rbasak> I think the result of "exit 1" is clearer!
<xnox> =)
<xnox> rbasak: fair enough and it's more consistent with missing my.cfg & failing to load apparmor profile
<xnox> which also do not print messages.
<ogra_> effectively this test should live inside mysqul imho and just log to syslog
<rbasak> ogra_: I'd rather not patch mysql for this if it can be done in a pre-start!
<xnox> ogra_: no, because stuff that starts on starting mysql would have fired by then.
<rbasak> And I can still log to syslog from the pre-start with logger if I want to.
<ogra_> xnox, hmm ? if the upstart job failed nothing depending on it should start
<xnox> rbasak: in the pre-start script you can do: echo "`date` Pre-start Sanity checks"
<rbasak> I think I understand the options now, thanks. So now the question becomes: what is the standard, or what should the standard be?
<xnox> rbasak: and then you get timestamps and reasoning in the /var/log/upstart/mysql.log
<rbasak> xnox: yeah I guess that's the best option for now. Thanks!
<xnox> ogra_: started - mysql started to run and didn't fail, starting - mysql is about to be launched
<xnox> rbasak: possibly more messages for the other two fails (missing my.cnf & failing to load apparmor-profile)
<rbasak> xnox: ack
<rbasak> I'll fix it up
<xnox> jodh: you might want to look at the mysql upstart job, it does some funny stuff in pre-start and post-start =)
<xnox> rbasak: upstart cannot predict what is being tested in pre-start or script so the job itself should somehow hint to the user as to what it is doing. And since we log everything, stdout & stderr is your friend.
<mjt> why ubuntu uses apparmor instead of selinux?
<rbasak> xnox: the post-start is pretty close to http://upstart.ubuntu.com/cookbook/#post-start, no?
<mjt> maybe it's possible to (re)use selinux policies from redhat and thus share efforts, instead of developing new set of rules...
<xnox> if one increases upstart logging $ initctl log-priority debug then you get detailed events emitted, but they go to like dmesg and not individual job logs.
<xnox> mjt: selinux is harder for admins to get right, apparmor offers more flexibility/sanity.
<xnox> mjt: although people on #ubuntu-hardened (security team) can answer that question better.
<rbasak> mjt: apparmor works really well. Witness all the sysadmins who end up disabling selinux because they don't understand it and it's blocking them
<xnox> jdstrand: ^ mjt
<rbasak> mjt: why doesn't redhat use apparmor instead of selinux? Then we could share efforts, instead of developing a new set of rules... :-)
<Laney> He didn't suggest switching but finding a way to share policies...
<rbasak> Good point. Sorry.
 * mjt is back (was afk for a bit)
<mjt> well. I ended up disabling selinux on a few redhat systems I manage exactly because it was constantly staying on the way
<mjt> and it required quite some amount of time to get to actually fixing the problem
<janimo> seb128, jibel added a proposed debdiff to the bug
<janimo> I have just added one that is
 * mjt wonders why, after typing `apparmor suse' in google the first suggestion it offers to complete the search term is `disable'...
<seb128> janimo, thanks, I will review it in a bit
<xnox> mjt: was the completion "disable apparmor" or "disable suse" ?!
 * xnox =D
<mjt> heh
<mjt> in that context i remember a subject in qemu-devel@ recently -- "Discard improvements" by Paolo Bonzini...
<mjt> that meant to be improvements for "discard" command (to a virtual disk), not to discard any improvements made so far...
<xnox> yeah, I know.
<Nafallo> hello o/
<Nafallo> I got an archive question :-)
<Nafallo> a package seems to have gone AWOL... cjwatson? :-)
<Nafallo> and when I say one, I mean two.
<xnox> Nafallo: which src package names?
<Nafallo> xnox: not sure, but binary package names would be open-vm-tools and open-vm-dkms
<Nafallo> I would imagine the source being open-vm-tools
<xnox> Nafallo: https://launchpad.net/ubuntu/+source/open-vm-tools/+publishinghistory it's published in multiverse
<xnox> Nafallo: do you have multiverse enabled?
<Nafallo> yeah, all of the four
 * xnox is waiting for rmadison results....
<Nafallo> hrm
<Nafallo> for some reason I don't have the package lists for multiverse...
<Nafallo> *scratches head*
<Nafallo> thanks for checking. seems I've got bigger issues.
<xnox> Nafallo: it's on disk on mirrors, either you don't have multiverse enabled or the mirror you are using doesn't have multiverse.
<Nafallo> yeah, I don't have the lists in /var/lib/apt/lists, so something isn't right on this server. thanks for confirming :-)
<Nafallo> xnox: fixed by magic... I blame the squid proxy.
<soren> I wonder why the postgresql security update hasn't propagated to updates yet? I thought that usually happened almost immediately (to offload the security mirrors).
<jdstrand> soren: hi! I think that was turned off in preparation for the precise point release
<soren> jdstrand: Hey :)
<soren> jdstrand: Why wouldn't we want security updates to be included in the point release?
<jdstrand> soren: we would, but, aiui, the point release was more or less imminent
<jdstrand> testing done, etc
<soren> Oh, I see.
<soren> Oh, well. As long as it's intentional, it's probably all good.
<jdstrand> I think that may all get turned back on today
<soren> Cool beans.
<cjwatson> soren: I turned it off because we were iterating on candidates and I wanted exact control over what changed in each one
<jdstrand> mjt: xnox was right. apparmor is easier to use on many levels. selinux is available in Ubuntu as well. We do work with other distros to share apparmor policy, but sharing policy like this (apparmor or selinux) is difficult because of distro nuances
<jdstrand> mjt: if you want some more info, I suggest taking a look at: https://wiki.ubuntu.com/AppArmor (which has a bunch of links for more info)
<Dedunu> seb128: i fixed it and finally built it
<Dedunu> seb128: thank you lot
<seb128> Dedunu, great, you're welcome!
<Dedunu> seb128: now i pushed my code to my lp
<Dedunu> so i should ask for a sponsership nah?
<seb128> Dedunu, did you submit a merge request for it?
<Dedunu> seb128: nope
<Dedunu> how to request a merge
<Dedunu> ?
<soren> cjwatson: Ok, cool. I just wanted to make sure it wasn't an unknown problem.
<Dedunu> seb128: ubuntu wiki makes me confuse im sorry for asking steps
<Dedunu> by step
<seb128> Dedunu, http://developer.ubuntu.com/packaging/html/udd-sponsorship.html
<Dedunu> seb128: how to find a person to review?
<cjwatson> You don't, it goes into the sponsoring queue
<seb128> Dedunu, what cjwatson said, see http://reqorts.qa.ubuntu.com/reports/sponsoring/
<cjwatson> That is, you don't explicitly find a victim, er, reviewer up-front
<Dedunu> seb128: k i got it
<Dedunu> seb128: cjwatson: thanks guys
<seb128> Dedunu, thanks for the work ;-)
<Dedunu> seb128: hey! thank you in advance
<jamespage> is anyone in channel familiar with the package importer? I have a requirement I think it might fulfill but have not idea really
<jamespage> .win 19
<jamespage> gah
<caribou> cjwatson: I'm working on an issue on Lucid that you fixed last year on debootstrap 1.0.39 (Debian & Ubuntu)
<caribou> cjwatson: it's in precise-update but in my case, the issue is on lucid
<caribou> cjwatson: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=618920
<ubottu> Debian bug 618920 in debootstrap "debootstrap: needs more robust download error handling" [Wishlist,Fixed]
<caribou> cjwatson: I just need one confirmation : if it was to be fixed in Lucid, it would make it into lucid-backport which is currently offering 1.0.37, right ?
<caribou> cjwatson: no chance of ever seeing it on the .iso ?
<xnox> caribou: yes. You should be able to backport 1.0.39 to lucid.
<xnox> caribou: there are no more point lucid releases and hence no more iso releases for lucid.
<caribou> xnox: my current issue is that preceed installs off a mounted .iso file are hitting this bug
<caribou> xnox: ok, this confirms what I wanted to know
<xnox> caribou: net-inst / pxe-boot on the other hand should be able to pick it up (i think)
<xnox> not sure if we have preseed option to use backports, we do have presseed options to use -proposed / -updates.
<xnox> or you can point to your own archive with just that debootstrap deb.
<caribou> xnox: ok, that's what I needed to know
<caribou> xnox: thanks
<cjwatson> netboot installs pick up udebs from -updates by default, and there's an option to use -proposed for the purpose of validation
<xnox> ack.
<Dedunu> seb128: if you didn't help me i will not do that
<sconklin> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Open | Dev' 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:
<caribou> xnox: cjwatson: I see a preseed option for -backport as well, but I suppose that it doesn't apply to udebs
<cjwatson> It does not
<cjwatson> I wouldn't recommend using backports for this anyway; surely it is a bug fix not a feature backport
<caribou> cjwatson: indeed, but that specific fix is in 1.0.39 and 1.0.37 is already in lucid-backport
<cjwatson> Yeah but that was for the addition of newer series
<cjwatson> Ignore it
<cjwatson> Even if we added udeb backport support I wouldn't expect to spend any time backporting *that* to lucid :)
<caribou> cjwatson: so what would be the preferred solution : cherrypick this specific patch over 1.0.20ubuntu1.4 which is in lucid-updates ?
<cjwatson> The patch should be cherry-pickable in an SRU by somebody with time to do that
<cjwatson> Yes
<caribou> cjwatson: I have time for that, I'll look into it
<caribou> cjwatson: then I'll subscribe the SRU & sponsor for a victim, er sponsor :)
<doko> tkamppeter, hplip ping
<tkamppeter> doko, hi
<doko> tkamppeter, do you know if upstream is preparing a move to python in hplip?
<doko> barry, ^^^
<tkamppeter> doko, they have used Python all the time, do you mean a switchover to Python 3?
<doko> tkamppeter, well, yes ...
<doko> tkamppeter, I know that python3-reportlab isn't yet there, but it looks to me this is only used conditionally for pdf and fax
<tkamppeter> doko, I could report a bug on HPLIP upstream telling that Python2 is deprecated and they need to switch to Python3.
<tkamppeter> doko, pure printing and scanning is even done in C, so for mobile devices one could even install only this core part of HPLIP. Python is only used for admin and GUI stuff.
<jdstrand> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Open | Dev' 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: jdstrand
<barry> tkamppeter: +1 for py3.  is there any way to subscribe me to an upstream bug tracker?  i'd be willing to help out
<barry> tkamppeter: also, did you see my email about system-config-printer?
<tkamppeter> barry, HPLIP uses Launchpad for upstream, so you can upstreamize any Ubuntu HPLIP bug by adding an HPLIP upstream task and you can directly report HPLIP upstream bugs via http://launchpad.net/hplip/ and naturally subscribe to all these.
<barry> tkamppeter: perfect, thanks
<tkamppeter> barry, there was something about the automatic firmware file download mechanism, was it you who mailed me about that?\
<barry> tkamppeter: not me.  i was emailing about s-c-p and py3
<tkamppeter> barry, there was no effort about passing it over yet, volunteers welcome, and otherwise postpone this WI in the Blueprint.
<barry> tkamppeter: thanks!
<tkamppeter> barry, will you report the Py2-is-deprecated-use-Py3 bug to HPLIP upstream?
<barry> tkamppeter: doing that right now :)
<barry> tkamppeter: do you want me to subscribe you to the bug?
<hallyn> pitti: bug 1103022 updated
<ubottu> bug 1103022 in udev (Ubuntu) "70-udev-acl.rules needs to put g+rw on /dev/kvm" [High,Confirmed] https://launchpad.net/bugs/1103022
<hallyn> jamespage: ^ that finally shows exactly what is going on (with that part of the bug, ignoring the inotify bug :)
<barry> tkamppeter: bug 1124208
<ubottu> bug 1124208 in HPLIP "Port to Python 3" [Undecided,New] https://launchpad.net/bugs/1124208
<xnox> tkamppeter: auto-firmware download somthing like ubuntu-drivers-common ?! highlighting pitti ?!
<pitti> hallyn: thanks
<pitti> xnox: u-d-common doesn't download anything by itself; it's an API for mapping hardware to apt packages
<pitti> (and CLI tools)
<hallyn> pitti: do you by any chance know how you can tell if a acl_get_file() result is real or representing regular perms?
<xnox> pitti: ah so hplip still will need .debs (in restricted?!) with correct mod-aliases.
<xnox> pitti: hmm... I was thinking to use mod-aliases to correctly install mdadm for intel matrix raid instead of dmraid.
<pitti> hallyn: no, I've never used libacl; that might be the difference between ACL_TYPE_DEFAULT and ACL_TYPE_ACCESS?
<hallyn> pitti: I'm not sure - I *thought* default meant "a default acl", not the regular file perms, but I'm not sure
<hallyn> pitti: well, I guess there is *one* way -
<hallyn> it's tediuous, but we could check whether acl group == file group owner, and acl perms == file group perms, and if so drop it from the acl...
<pitti> xnox: if the printer can be expressed in terms of modaliases, that's the best way; if not, one can write some code to do the detection
<hallyn> but that's probably deemed nto right
<tkamppeter> barry, thank you very much.
 * xnox reboots to test some plymouth
<smoser> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Open | Dev' 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: smoser, jdstrand
<tkamppeter> xnox, pitti, I am seeing now that I have once switched HPLIP to its own firmware auto-install mechanism but returned to the Ubuntu mechanism due to a bug. I will retry using HPLIP's mechanism so that we can do away with the hack in update-manager (or whereever it was).
<Tatuus> Howdy how! Not sure if this is the right place to suggest this, but could it be possible to have an added function to Firefox bookmarks? Kind of which, when i press certain letter on the keyboard, the selection jumps to the start of according alphabetical part on the list? This is in on Windows version of FF already.
<smoser> seb128, around ? i'm looking at https://launchpad.net/bugs/1110379
<ubottu> Ubuntu bug 1110379 in pocketsphinx (Ubuntu) "New upstream release (0.8.0)" [Wishlist,New]
<smoser> and wondering if you think lack of LICENSE file in a tarball necessitates .dsfg.orig.tar.gz
<dupondje> Sweetshark: there ?
<dobey> Tatuus: i think you need to talk to firefox developers about that
<Tatuus> Where can i reach Linux FF developers in irc the best ?
<dobey> i don't know. i'm sure a quick search on your favorite search engine will tell you though
<cjwatson> I'd have thought they'd prefer enhancement requests in bugzilla
<dobey> but i'm sure they'll also just tell you to file a bug :)
<dobey> right
<Tatuus> Well i'll try =) this is "sort of" bug as this function is on the Win version
<cjwatson> bugzilla has an "enhancement" severity
<cjwatson> per https://bugzilla.mozilla.org/page.cgi?id=fields.html
<Tatuus> k thnx
<Aristide> Hi !
<Aristide> Its possible to test Ubuntu mobile ?
<ogra_> Aristide, if you mean ubuntu phone OS, yes, once it is released by end of the month
<Aristide> Ok :)
<Aristide> ogra_: Its possible to install Ubuntu phone OS on Samsung galaxy Note ?
<ogra_> i think the image that will be released will only run on the galaxy nexus first ...
<Aristide> Ok
<ogra_> LO
<ogra_> L
<ogra_> i haven an ssh -X session running to my nexus7
<ogra_> running dconf-editor from my desktop through it ... and having maliit installed
<ogra_> clicking inot a text field actually fires up maliit on my desktop now
<seb128> smoser, hey, I had that discussion with ogra_ and cjwatson recently, if the license is included in /usr/share/common-licenses you can do without the license text in the tarball
<ogra_> *into
<smoser> seb128, thanks. then i'll review that a bit further and maybe upload.
<xnox> slangasek: so current mdadm hooks try to display more than 127 characters of text messages, which plymouth doesn't want to print.
<ogra_> your debian/changelog needs to point to the license on disk though
<seb128> smoser, that would be great, thanks
<cjwatson> ogra_: debian/copyright
<xnox> slangasek: is it possible to send plymouthd an escape sequence to show bootup messages? e.g. does "display-message" works after "hide-splash" ?
<ogra_> err
<ogra_> what cjwatson said, sorry
<Laney> hmm
<Laney> Quintasan_: Did you manage to get non-dbus-activated maliit to work? i.e. via input method selection
<Laney> I get the option but the keyboard doesn't appear
<Laney> err. wait. I didn't install a keyboard.
<Laney> That might help.
<Laney> hmm, no, it doesn't help
<Laney> seb128: are the retracers ok?
<seb128> Laney, let me check, I've s suspicion that the amd64 one is down, I meant to look at it earlier and didn't get to it yet
<seb128> Laney, shrug, down for 1.5 weeks
<Laney> ha
<Laney> moar monitoring
<seb128> Laney, well, the idea is that those retracers are going away in profit of the ones from errors.ubuntu.com
<seb128> but I don't know if the e.u.c are dealing with launchpad timeout issues, etc any better than the old ones atm
<Laney> mmm, but as long as apport wants to keep filing bugs
<seb128> Laney, I removed the lock, let's see if that works
<Laney> ok
<Laney> thanks
<seb128> the previous retracing errored-out on a launchpad timeout
<seb128> Laney, ev and mpt lobby for disabling apport for good I think, I've been fighting back until we get a way through e.u.c to request for extra infos from the next submitter
<seb128> otherwise we are stucked with reports but no content and no way to ask for details
<seb128> no content -> no description
<seb128> I still think it would be better to have an input field on the submission dialog
<seb128> but I think mpt disagrees with that
<mpt> seb128, I don't feel strongly either way. I did a design for a comment form, but ev + bdmurray + pitti decided against it.
<seb128> mpt, ok, I need to try to convince ev again I guess then ;-)
<seb128> I didn't have the feeling that pitti was strongly against in the past
<mpt> seb128, as described in the bug report, the replacement way to get more details would be by asking for it to be collected. https://wiki.ubuntu.com/ErrorTracker#extra-info
<seb128> mpt, right, that's a plus, I still think the input field would bring value
<seb128> mpt, 99% of descriptions are poor or useless but over 1000 reports have 10 descriptions might be enough to see a pattern in what the users were doing
<seb128> have->having
<Sweetshark> dupondje: pong.
<Sweetshark> dupondje: /win 6
<doko> barry, are you looking at newt/_snack?
<doko> looks like it re-runs the build at install time, and then gets things wrong
<slangasek> xnox: sorry, what do you mean by "bootup messages"?
<mjt> jdstrand: thank you for (apparmor) references!
<xnox> slangasek: something like booting _without_ spash quiet
<xnox> such that i can spew loads of messages and they are all visible.
 * xnox is thinking to do just a short explanation message  and wait for keystroke with a timeout
<xnox> it's better than it currently is, and it's UX friendly to have short message with plymouth instead of paragraphs of scary texts about failed hardware.
<jdstrand> mjt: np
<GunnarHj> cjwatson: ping?
<slangasek> xnox: so 'Esc' will toggle between splash and details
<cjwatson> GunnarHj: is it 12.04.2-critical?
<GunnarHj> cjwatson: No.
<cjwatson> GunnarHj: then not now :-)
<slangasek> xnox: but you're asking whether the client can switch the mode?
 * cjwatson trying to clean up loose ends
<GunnarHj> cjwatson: oK.
<cjwatson> GunnarHj: and yes I've seen your localechooser bangla branch, it's on my to-do list ...
<xnox> slangasek: yes via plymouth CLI
<GunnarHj> cjwatson: Not that. :)
<slangasek> xnox: unless you count show-splash/hide-splash, no
<xnox> slangasek: ok. i have something to test for now.
<seb128> janimo, still around?
<seb128> janimo, I guess you didn't use the packaging Vcs for your gnome-settings-daemon uploads? Or you did but forgot to push?
<ogra_> seb128, i dont thik he uploaded the latest fix
<seb128> ogra_, I'm speaking of the 4 previous revisions
<ogra_> (for the memory hole)
<ogra_> oh
<seb128> ogra_, I was trying to merge the fix in :p
<seb128> ogra_, but the vcs is 4 revisions behind
<ogra_> well, the old prob that we all dont read Bzr-Vcs
<ogra_> since UDD is around
<seb128> ogra_, between that and the obvious bug I'm going to get grumpy and ask that people go through merge requests in the futur :p
<ogra_> it shouldnt happen more than once per uploader though ...
<ogra_> at least i remember it now for desktop packages ... and i did the same mistake in the beginning
 * seb128 downloads each version from launchpad and commit manually...
<seb128> ogra_, yeah, I curse UDD regularly for those :p
<ogra_> i apt-get source my stuff usually ... plain oldschool ...
<ogra_> and only for desktop packages i add an extra commit
<ogra_> (and for some native foundations packages)
<dobey> barry: do you have privilges to upload pyflakes to debian?
 * xnox has access to UDD. I should start fixing packages
<xnox> dobey: I do ;-)
<xnox> or are you after flakey
<happyaron> debfx: Hi, I wonder is there any update/plan for LP #1101867? It's a bit annoying without the guest module, :)
<ubottu> Launchpad bug 1101867 in virtualbox (Ubuntu) "virtualbox-guest-dkms 4.1.22-dfsg-0ubuntu2: virtualbox-guest kernel module failed to build [VBoxGuest-linux.c:206:49: error: expected â=â, â,â, â;â, âasmâ or â__attribute__â before âg_VBoxGuestPciIdâ]" [Undecided,Confirmed] https://launchpad.net/bugs/1101867
<dobey> xnox: no, pyflakes. there's a new version that would be very nice to get in (and into raring)
<xnox> dobey: ok. let me upload that into experimental & sync.
 * xnox waits for raid VM to install anyway
<dobey> xnox: 0.6.1 is the version. fixes a few important issues.
<dobey> xnox: and thanks! btw, did you find any other motherboards? mine is nice, i just wish the ivybridge kernel driver was fixed
<xnox> dobey: right so somebody else commented on my blogpost with a very nice gigabyte suggestion. It beats intel motherboard by having displayport/hdmi/dvi-d/vga as well as a second raid chip. Such that I can write installer support for Intel Matrix and Marvell RAID.
<xnox> i think i will go for that one.
 * xnox is picking an Intel CPU with AES instruction set at the moment
<xnox> and then I should be ready to max out my credit card again /o\
<dobey> ah. yeah, the important thing for me to have was 2 DVI ports, as that's the only thing my monitors support
<xnox> dobey: well i have dvi-d & vga on my monitors. But I'm open to have DP & hdmi for the future =)
<dobey> xnox: right. vga doesn't work well for 2048x1152 on an lcd though :)
<xnox> show off =)
<penguin42> dobey: One of the 23" Samsung's ?
<dobey> penguin42: yeah, two of them :)
<penguin42> nice, don't seem to be able to get them anymore; everything is 1920
<dobey> penguin42: yeah, they don't make them any more, but you can occasionally find used or refurb models. i want to upgrade, but philips hasn't released the panel i want to consumer production models yet
<penguin42> why what spec is it?
<dobey> 3840x2160 21 inch
<penguin42> hoho oooh
<dobey> and probably won't use as much power or weigh as much as the ibm t22s. those things are just ridiculous
<stgraber> stgraber@castiana:~/Desktop/netcfg/netcfg-1.68ubuntu17$ xrandr | grep "*"
<stgraber>    2560x1080      60.0*+
<stgraber> I like having dual-1280x1024 on a single monitor ;)
<stgraber> (can get two VMs at 1280x1024 side to side with the Unity decorations without cutting any of it. The display also supports splitting the the area in two, showing an input in the first half and another input in the other)
<lifeless> dobey: you have ibm t22s?
<dobey> lifeless: no. they're too heavy and power hungry
<lifeless> dobey: I was going to say :)
<dobey> lifeless: i have samsung 2343bwx
<dobey> i do have an old sgi 1600sw sitting in the box though
<dobey> that was a really nice monitor
<dobey> i need to sell it though
<lifeless> hmm, I really should find out how big a monitor my work laptop can drive
<lifeless> it has dp
<dobey> lifeless: is it a thinkpad?
<lifeless> dobey: hah! I work at HP now...
<dobey> oh right
<theadmin> Alright, I'm new at this so bear with me. I'm trying to make a PPA for a small app I have made (just 3 files, actually), but the process of building a Debian package is amazingly confusing. I seem to have gotten debian/control right, and now I can't get the Makefile correctly. I install into $(DESTDIR)/usr/bin (am I doing that right or...?) but when I bzr builddeb, it complains about being unable to create /usr/bin/appname due to insufficient
<theadmin>  permissions (doh). What am I missing? Why isn't $(DESTDIR) being set?
<dobey> keeping track of who went where is too much work :)
<ScottK> theadmin: You will probably have more luck in #ubuntu-packaging.
<theadmin> ScottK: Oh, thanks. Geez, there's so many channels
<ScottK> You're welcome.
<dobey> doh, i forgot to do an mir
<lifeless> dobey: it is a 9470m - http://h10010.www1.hp.com/wwpc/us/en/sm/WF06a/321957-321957-64295-5228908-5228906-5271146.html?dnr=1
<dobey> lifeless: i'm not sure what the specs for dp 1.1a are. with 1.1 i think the max is maybe 2560x1600 or something near that
<dobey> at least, based on the table in the wikipedia article
<lifeless> thanks!
<barry> doko: i'm looking now
<barry> dobey: i don't think so
<dobey> barry: xnox replied saying he did. thanks :)
<barry> cool.  hopefully i will soon be able to answer 'yes' too ;)
<dobey> mterry: hey, can you do a trivial MIR approval for me? :)
<mterry> dobey, looking now
<dobey> thanks mterry
<mterry> yw!
<jdstrand> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Open | Dev' 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: smoser
<GunnarHj> slangasek: Hi Steve! There is no plan to backport the latest PAM upload to Precise or Quantal, is there?
<slangasek> GunnarHj: nope
<slangasek> GunnarHj: nothing from the pam side should be needed in precise/quantal, should it?  and if you want to fix the locale bug, changing lightdm is enough
<GunnarHj> slangasek: Right. So most of the Precise tasks at bug 952185 are redundant, I suppose.
<ubottu> bug 952185 in lightdm (Ubuntu Precise) "~/.pam_environment not parsed by default" [High,Triaged] https://launchpad.net/bugs/952185
<slangasek> GunnarHj: well, changing the pam configs (without changing pam) would still help with the ecryptfs problem
<GunnarHj> slangasek: Yes, but that aspect is limited to lightdm and gdm, isn't it?
<slangasek> GunnarHj: possibly, yes
<slangasek> GunnarHj: ah, no; atd, ssh, sudo are also all affected because they use 'auth pam_env.so' at the top of the stack
<slangasek> (that's why I added those tasks)
<GunnarHj> slangasek: But that has not been an issue, has it? Even if it's not the "right" way...
<slangasek> GunnarHj: sure it has
<slangasek> GunnarHj: the bug may only have been /reported/ for lightdm logins, but the same problem with not parsing .pam_environment on ecryptfs will affect these other services too
<GunnarHj> slangasek: You mean that the environment has been something else than intended?
<slangasek> sure
<slangasek> actually, for atd this is a low-priority issue
<slangasek> because atd never prompts for passwords, so never unlocks an ecryptfs mount
<slangasek> but sudo, ssh are certainly affected
<GunnarHj> slangasek: Maybe I'm stupid, but if the environment is set correctly at login (by changing lightdm), what's the remaining problem for e.g. sudo?
<slangasek> GunnarHj: because sudo is meant to set up the environment based on the /target/ user's .pam_environment file, not the source user's
<GunnarHj> slangasek: Aha, that clarifies it for me. Thanks! :)
<GunnarHj> slangasek: ... OTOH, root does not have any ~/.pam_environment, at least not set via the UI.
<slangasek> GunnarHj: sudo is also used for changing between multiple non-root users, not just from non-root to root; but yes, to the extent that this is a problem it's likely to be because of other environment settings besides locale
<slangasek> GunnarHj: so I'm perfectly ok with the atd, sudo tasks being closed 'wontfix' for precise
<GunnarHj> slangasek: Ok. I'm just trying to avoid (almost) unnecessary work. ;-)
<psusi> cjwatson: I've got a production server here where grub upped and stopped recognizing the lvm inside the raid array.. I'm trying to trace through to see why, but grub-probe has no debug symbols when I build it and I can't figure out the make system... where do I need to shove the -g? ;)
<cjwatson> The Debian packaging for grub2 uses -g unconditionally
<cjwatson> It goes in HOST_CFLaGS
<cjwatson> HOST_CFLAGS
<psusi> hrm...
<psusi> Reading symbols from /home/psusi/grub2/quantal/grub-probe...(no debugging symbols found)...done.
<psusi> bzr branch from lp, configure, make
<cjwatson> configure/make => not the Debian packaging :)
<psusi> ahh
<cjwatson> HOST_CFLAGS='-O0 -g -Wall -Wno-error=unused-result' ./configure --with-platform=pc && make
<cjwatson> should do it
<psusi> yea, this is very odd.. it was runing 12.04, and that grub just says lvm signature not found when it probes the array... 12.10's actually appears to print out a bunch of invalid garbage in the -vv output when it discovers the array
<cjwatson> Might be the gettext bug
<cjwatson> I should backport that fix
<cjwatson> psusi: You might try http://paste.ubuntu.com/1646455/
<cjwatson> If it's that, then it won't necessarily reproduce cleanly in grub-probe (unfortunately)
<cjwatson> Though 12.10 should have a superset of that fix
<matlock> so, I'd like to build ubuntu with the kernel found in android
<ikonia> matlock: what did I JUST tell you in #ubuntu
<ikonia> matlock: that this channel is NOT a support channel for the android kernel
<ikonia> matlock: less than 20 seconds ago I told you that
<matlock> tell #android that
<matlock> this is an ubuntu issue
<matlock> not #android
<ikonia> this is not a support channel
<matlock> so what you want me to ask in #ubuntu again?
<ikonia> no
<matlock> then i shall ask here
<ikonia> no idea
<ikonia> ubuntu doesn't use the android kernel
<ikonia> it's nothing to do with ubuntu and this is not a support channel
<matlock> ubuntu for phones does
<matlock> then why did they state they do
<cjwatson> It's probably simplest to wait until the first Ubuntu phone software release and pick it apart for the necessary bits of userspace support
<ikonia> matlock: there is no information on the ubuntu phone, so you don't know that
<cjwatson> ikonia: It does
<matlock> yes there is
<ikonia> cjwatson: has that been announced now ?
<cjwatson> Yes
<cjwatson> A while back
<matlock> galaxy nexus is said to be released with ubuntu this month
<ikonia> thank you
<ikonia> ????
<ikonia> well, try #ubuntu-phone then
<ikonia> but this channel isn't a support channel
<matlock> omg ty
<cjwatson> It's not clear to me that the method of gluing the Android kernel into Ubuntu userspace is exactly a support issue at this point
<ikonia> sorry about that, I tried to get him to listen before joining
<cjwatson> I think you should leave -devel moderation to us, TBH :)
<Quintasan> Laney: I did not try that BUT we are soon going to work on Plasma Active so I will probably have to deal with it sooner or later
<psusi> nope, it's got trash in array->name when diskfilter.c:insert_array is called
<Quintasan> sorry for no response - uni stuff
<cjwatson> It's not always obvious what is and isn't unreasonable to ask here
<ikonia> cjwatson: the topic is pretty clear
<ikonia> I suggest changing the topic if you want it looser
<cjwatson> ikonia: That's sophistry
<ikonia> thats what....
<cjwatson> ikonia: It's clear if you think that the question was support, which is the exact point at issue
<slangasek> well, creating a frankenstein image with an android kernel isn't exactly "app development"
<cjwatson> It's legitimate for people to ask how it works; if we get tired of it then we can send them elsewhere
<slangasek> nor is it end-user support
<ikonia> based on his comments in #ubuntu, it was pretty clear what he wanted
<cjwatson> I'm not sure I want to be defended in the aggressive way I saw here
<ikonia> what agressive way
<cjwatson> The one you used
<ikonia> oh you mean the one where you tell someone 5 times that ubuntu-devel isn't the place to ask about how to build an android kernel
<ikonia> and he ignores it and still does it
<cjwatson> That isn't what he asked here
<ikonia> yeah, I guess it's pretty agressive to point out that you've just done the opposite of what you've been told the channel is for
<cjwatson> I have no context from #ubuntu, but what I saw was somebody turning up with a reasonable question and you blew their head off.  Please stop it and don't do it again here.
<ikonia> building ubuntu with the kernel in android....is running the android kernel in ubuntu, which is what he put in #ubuntu
<ikonia> he just worded it slightly different
<ikonia> cjwatson: I'm sorry you feel that way
<cjwatson> I don't need a non-apology, thanks
<ikonia> it wasn't a non-apology
<ikonia> please don't try to be sarcastic, I was just being polite and saying sorry
<cjwatson> "I'm sorry you feel that way" is a classic non-apology technique, FYI
<ikonia> it's just as rude as blowing someones head off
<ikonia> oh, so you're telling me that I wasn't apologising
<cjwatson> It's the first example in https://en.wikipedia.org/wiki/Non-apology_apology
<ikonia> I don't need a wiki page
<ikonia> I am sorry my comments made you feel that way
<ikonia> is that clearer for you ?
<cjwatson> Yes, thanks
<marrusl> slangasek, bet you thought I was done asking multi-arch questions.  :)  So... ah... would it be insane to mark alsa-utils and alsa-base multi-arch:foreign?
<cjwatson> Those look foreign-able to me ...
<slangasek> I concur
<slangasek> not that most packages ought to be depending on them
<marrusl> cjwatson, slangasek... oh great.  I was trying to determine if they were M-A in debian, and I don't think so yet.
<slangasek> but it's not buggy to M-A: foreign them
<marrusl> slangasek, well there I agree.  It seems like if you have, let's say, some sort of Chat/IM/AV app.... you don't really have to depend on this.  but others disagree.  ;-)
<cjwatson> There are exceptions, but in general we're ahead of Debian on at least M-A: foreign application
<cjwatson> Not only due to i386-on-amd64 kind of stuff, but also because of its applicability to cross-building where we've been focusing
<slangasek> marrusl: well, depending on alsa-* is contraindicated because *using* alsa interfaces is contraindicated. :)
<marrusl> cjwatson, aha, yeah that makes sense.
<marrusl> slangasek, aaaand there's that.  But for some reason this particular 3rd party app likes to manipulate alsa directly.  the reasoning for that has never made it's way back to me.
<slangasek> yeah, that's not going to work so well when pulseaudio is in the mix
<slangasek> but, <shrug>
<marrusl> in any case, since it's just a control file change, easier to just make it happen.  I'll file bugs/diffs later.
<slangasek> ok
<marrusl> yeah, no... I know.  but they feel they know what they're doing.
<TheMuso> ...or not worry about it, given an alsa 1.0.26 update is currently in QA testing, and I can queue the change for upload when thats done.
<TheMuso> In otIn other words, I've just observed this conversation, and will make the change in the bzr branches now.
<slangasek> TheMuso: I guess marrusl may want an SRU to precise as well, but thanks for taking care of raring at least :)
<TheMuso> np
<marrusl> TheMuso, ROCK!  I need to stop by this channel more often.  :-)
<psusi> wow this is weird... grub is finding the raid superblok a second time.. inside the raid array itself
<marrusl> and indeed... precise and quantal.  I'll skip the raring patch then and get it going.  thanks again~!
<TheMuso> marrusl: You're welcome.
<TheMuso> marrusl: Feel free to subscribe me to the qnalta/precise bug, and I'd be happy to take care of things for you.
<TheMuso> marrusl: Launchpad nick is themuso.
<marrusl> TheMuso, righto.  I'll find it.  that's great.
<slangasek> smoser: bug #1124384> mounted-tmp is expected to run synchronously after /tmp is mounted and before the 'filesystem' event is emitted
<ubottu> bug 1124384 in mountall (Ubuntu) "cloud-init parses yaml incorrectly" [High,New] https://launchpad.net/bugs/1124384
<slangasek> smoser: indeed, I'm working with xnox on what amounts to a converse bug, caused by mounted-tmp taking too long to run and holding things up in mountall
<smoser> slangasek, it seems unreliably indeterminable
<smoser> wait. what?
<smoser> my file created after 'filesystems' event is definitely getting wiped
<slangasek> well, that would definitely be a bug
<slangasek> and I'm saying there's evidence that seems to contradict the possibility of this bug existing in mountall
<slangasek> I guess some logs would help?
<slangasek> probably logs of a boot using --verbose
<slangasek> to see the ordering of all events (including the start/stop events for mounted-tmp)
<smoser> slacker_nl, what about something like this
<smoser> sorry slacker_nl
<smoser> slangasek,
<smoser> http://paste.ubuntu.com/1646616/
<smoser> find /tmp '!' -newermm /proc/1
<smoser> something to that effect seems like it might work
<slangasek> smoser: well, I think that's a workaround for whatever's actually going wrong
<slangasek> (and thus it may not be reliable at all)
<smoser> no its not.
<slangasek> yes, it is
<smoser> well, if you're saying thats supposed to block everything
<slangasek> because mounted-tmp should *never* be doing what you describe
<slangasek> yes, it is supposed to, and everything I've seen elsewhere shows that it is doing so
<smoser> slangasek, ok. so what debug do you want here ?
<slangasek> and if it's *not*, then we'll have big problems elsewhere
<smoser> --debug to mountall ?
<slangasek> smoser: upstart logs booted with --verbose
<smoser> and --verbose to init ?
<slangasek> smoser: the mountall --debug is probably not necessary, but if you want to grab them both at the same time sure
<slangasek> smoser: separately, storing such files at fixed locations under /tmp is contraindicated for security reasons; you could probably sidestep this issue by using /run...
<psusi> cjwatson: wow... for some reason I had an older md 1.0 superblock at the end of the partition in addition to the correct 1.2 at the start, and grub found the old one first, then when it looked inside the old raid array, saw the new superblock at the start so it tried to stack a new raid array on top of the old raid array and in the processes, came up with a totally corrupt array name
<smoser> slangasek, "such files" ?
<smoser> ah. yeah. its a test.
<slangasek> smoser: /any/ file
 * psusi wonders why mdadm wasn't confused by this
<infinity> psusi: mdadm looks for 1.2, 1.1, and 1.0 in that order, and breaks on the first one it finds.  So, it would likely explode in the inverse situation (an old 1.2 superblock and a new 1.0 one)
<infinity> psusi: The proper answer being "you should never have conflicting superblocks".
<smoser> slangasek, http://paste.ubuntu.com/1646687/
<smoser> you're interested in the final boot
<psusi> infinity: ahh... that explains it... yea, I have no idea how that happend too since I made sure to mdadm --zero-superblock the old one before creating the new
<slangasek> smoser: "final boot"? this log has more than one?
<psusi> probably a good idea to check all 3 and report an error if more than one is found...
<smoser> there is are boot there at line 359
<slangasek> smoser: I see references to mounted-tmp from lines 178 to 207 and nothing after
<smoser> right. which is very odd.
<smoser> but its hard to disagree that a boot occurred in the middle
<smoser> :)
<slangasek> smoser: this seems to be plymouth-mediated log output, yes?  Can I get the output from upstart as logged to /var/log/dmesg?
<smoser> http://paste.ubuntu.com/1646707/
<slangasek> hmm, the plymouth disconnect also happens much earlier than it has any right to
<smoser> well, it ate a bug lunch of data that was supposed to go to /dev/console, so it took an early nap.
<slangasek> smoser: ok.  mounted-tmp is from lines 438 to 467, the filesystem event is line 1251.  So I don't think mountall is your culprit.
<smoser> yehah, i noticed that too.
<smoser> but i' not completely convinced.
<cjwatson> infinity: It's certainly possible that GRUB searches in a different order, though, which I think I would consider a bug
<smoser> slangasek, ok. i'll poke more later.
<cjwatson> Same way I don't think GRUB should be stricter than (say) parted or Linux about partition tables
<slangasek> smoser: well, if the actual failing symptom reproduced on this boot, there's no way it could be due to mounted-tmp, which absolutely finished running before the filesystem event was emitted
<smoser> slangasek, would you come in to poke around?
<slangasek> smoser: sure - where to?
<smoser> ubuntu@ec2-54-234-173-208.compute-1.amazonaws.com
<smoser> slangasek, ok. so user-data provided to that instance ends up in '/var/lib/cloud/instance/scripts/runcmd' being written by cloud-config.conf and then being executed.
<smoser> to reproduce a semi fresh-boot
<slangasek> smoser: ok.  where do I look to see the failure?
<smoser> sudo rm -Rf /var/log/cloud-init* /var/lib/cloud
<smoser> and reboot
<smoser> you *should* have a /tmp/done file
<smoser> (i had one once)
<smoser> i dont have an easy way for you to change the user-data that is going in
<smoser> so 'touch /tmp/done' is all you're going to get.
<smoser> :)
<slangasek> heh, ack
<smoser> unless you patch cloud-init locally there to read that and modify the string
<smoser> but i'm out now.
<smoser> just /sbin/poweroff when you're done
<slangasek> ok, cheers
<infinity> cjwatson: Sure, it may well be a bug for GRUB to do things differently, but I think the behaviour with conflicting superblocks is largely undefined anyway.  mdadm with no arguments searches in the way I said, I *think* (I'd have to double-check the code), but usually it's not run without arguments, it knows in advance what to look for, GRUB can't.  And it's always wrong to have multiple conflicting superblocks.
<xnox> ikonia: to be honest we want to welcome any kernel/android involvement. the current linux-nexus7 kernel in the archive is an android kernel, although targetting nexus7. If users are more on a technical side of things redirect them to #ubuntu-arm where a mixed friendly support/development happens.
<xnox> ikonia: for user-centric enquiries to #ubuntu-phone.
<xnox> ikonia: if they end up here =) we have plently of "moderators" here. and typically if someone doesn't listen to one person, there is a slight chance for different people to tell them off ;-)
 * xnox and my mate at work used to call-up each other as "higher authority" when customers were getting pissed off with us. Little did they know both of us were actually the same rank within that establishment.
<slangasek> smoser: fwiw I've just ruled out mounted-tmp for sure; I edited /etc/init/cloud-config.conf to touch another file under /tmp, and *that* file appears but /tmp/done does not
<cjwatson> infinity: Yeah.  It's just troublesome because if something is working in practice then a boot loader is a bad place to find out that it's technically broken.
<xnox> infinity: well 0.9,1.1 are in the beginning, 1.0 is at the end, 1.2 is 4k from the beginning. So potentially one can have 3 conflicting superblocks if one tries very hard =)
<xnox> and nested mdadm raid levels to confuse things further.
<hrw> new version of linux-meta-chromebook and chromium-mali-opengles sent to NEW queue
#ubuntu-devel 2013-02-14
<GunnarHj> slangasek: still there?
<slangasek> GunnarHj: yep
<GunnarHj> slangasek: In sudo they have user_readenv=0, so I  take it that the sudo tasks are invalid on bug 952185.
<ubottu> bug 952185 in lightdm (Ubuntu Precise) "~/.pam_environment not parsed by default" [High,In progress] https://launchpad.net/bugs/952185
<slangasek> GunnarHj: yep, sounds like they are
<slangasek> GunnarHj: good catch, sorry I overlooked that
<GunnarHj> slangasek: Ok, then my thinking was right for once. ;-)
<smoser> slangasek, ok... new theory.
<smoser> cloud-fconfig actually just writes the shell script.
<smoser> cloud-final would run it
<smoser> cloud-final runs on
<smoser> start on (stopped rc RUNLEVEL=[2345] and stopped cloud-config)
<slangasek> smoser: well, that doesn't look problematic to me
<smoser> no?
<smoser> i think this was reported as https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/1103881
<ubottu> Ubuntu bug 1103881 in upstart (Ubuntu) "cloud-final is never executed if upstart is upgraded during initialization of the image " [High,Confirmed]
<slangasek> ah
<smoser> which i think is a wrong diagnosis, i'm seeing this without upgrade of upstart.
<slangasek> mm
<slangasek> well, jibel seemed convinced it was happening only when upstart was getting upgraded
<smoser> in our pastebin here http://paste.ubuntu.com/1646707/
<smoser> we never see 'rc' stop
<slangasek> ah
<slangasek> so what all is in /etc/rc2.d/ ?
<slangasek> the only thing I know of that would prevent 'rc' from stopping is an init script that's hanging
<slangasek> and jibel's bug does show rc being stopped (https://launchpadlibrarian.net/129295546/LP1103881.dmesg)
<slangasek> so I think you have two different bugs with the same symptom
<smoser> hm... so maybe they're coincidence.
<smoser> just 'set -x' on rc
<smoser> into /run/log
<smoser> so i'll see that here  in a minute.
<slangasek> ok
<smoser> slangasek, i've got to run again. i'm really confused now.
<smoser> http://paste.ubuntu.com/1647304/
<slangasek> smoser: well, this shows no rc (or rc-sysinit) job running at all... ?
<smoser> right.
<smoser> tomorrow
 * xnox waves from february 14th =) the international day of loving to debug mysterious presents in boot stacks
<slangasek> it's a niche holiday
<mwhudson> not really the right place to ask the question but
<mwhudson> are there any docs on building custom initramfses?
<mwhudson> i want mkfs + friends in one
<TheMuso> You need only write a hook for update-initramfs to run to put the files you want in the initramfs.
<mwhudson> sounds suspiciously easy
<hallyn> hm, my boot time in raring just got really bad in the last few days.  from about 8 secs to about 30 secs.  bootchart doesn't show disk use or anything...
<TheMuso> mwhudson: Look in /usr/share/initramfs-tools/hooks/ for some good examples.
<TheMuso> mwhudson: Then its just a matter of writing extra hooks to be run in the initramfs.
<mwhudson> ok
<mwhudson> do you have to build the initramfs on the same arch as you're going to run it on?
<mwhudson> i guess practically speaking yes
<cjwatson> Yeah
<cjwatson> Since it copies stuff from the host fs
<hallyn> really dbus-daemon is the only thing that stops right when gnome stuff finally starts
<mwhudson> i suppose you can chroot + qemu-arm-static
<mwhudson> but
<cjwatson> In principle yes
<cjwatson> amd64 <-> i386 probably works fine with chroots; not sure if there mightn't be some weird quirk with ARM, but worth trying if it would make life easier
<mwhudson> not sure if it would tbh
<mwhudson> just the tediousness of copying files around
<penguin42> mwhudson: You can, it does work for simple stuff (or did 18 months or so ago last time I tried it)
 * xnox does qemu-arm-static a lot. For most things it's quicker than panda, but nexus7 beats it, as compared to my i5
<pitti> Good morning
<YokoZar> *files bug against 6 packages, uploads debdiffs for all, makes sponsorship queue sad*
<YokoZar> Is it correct for apt-get-install foo to bail out if recommends are uninstallable without the --no-install-recommends flag, or should apt be trying to get as many as it can?
<slangasek> YokoZar: unsatisfiable recommends should not cause apt-get to bail out, though they will cause warnings to be output
<YokoZar> slangasek: Then this is also an apt bug :D https://bugs.launchpad.net/ubuntu/+source/winetricks/+bug/1123710
<ubottu> Ubuntu bug 1123710 in winetricks (Ubuntu) "wine1.4:i386 not installable on raring amd64" [Low,Triaged]
<slangasek> YokoZar: I'm reasonably certain that the problem there is not that the recommends are uninstallable, but that the recommends are available, apt follows them, and as a result renders one of the *depends* uninstallable
<slangasek> so... yes, apt could be smarter about skipping the recommends in that case, but this is a complicated problem
<YokoZar> slangasek: so apt is considering switching a recommended (arch all but not M-A: foreign) package to it's "i386" version, then trying to get i386 versions of the arch:all's package depends, and then hitting a conflict and giving up rather than just ignoring the recommend
<slangasek> hitting a conflict because it's managed to break one of the dependencies in the process and is too far down the rabbit hole to unwind
<YokoZar> slangasek: I think that's right...and I think correct for apt in this case would be to ignore the recommended package rather than count the installed arch:all version as conflicting with itself.
<slangasek> well, it wouldn't try to use i386 packages to satisfy the dependencies of an Arch: all package, no
<YokoZar> I meant transitive i386 deps
<YokoZar> eg when an arch: all package had arch specific deps
<slangasek> still no
<slangasek> an Arch: all package will have its deps satisfied by packages of the native arch
<YokoZar> only if it's marked M-A foreign, yes?
<YokoZar> (in the case of installing a non-native package that depends on the arch:all package)
<slangasek> no
<slangasek> an Arch: all package is treated as equivalent to a package of the native arch, in every way
<YokoZar> Err then I'm confused because all the conflicts in question in the linked bug are recommends of arch:all packages
<YokoZar> indeed, already installed arch:all packages
<slangasek> well, I can't reproduce that error output on a raring system, so
<slangasek> I get a completely different set of conflicts
<YokoZar> apt-get install wine1.4 first
<slangasek> ah right, I have wine1.5 installed
<YokoZar> then remove it (but not the stuff it pulls in) and apt-get install wine1.4:i386
<slangasek> YokoZar: still can't reproduce this in a clean chroot (and I'm not clobbering the wine1.5 install on my desktop for testing right now)
<YokoZar> slangasek: The fact that you want to protect your wine1.5 install makes me kinda happy :D
<slangasek> I'd be happier if the software in question didn't need it ;)
<YokoZar> slangasek: I'll see if I can nail down an exact repro step on a new VM
<dholbach> good morning
<Dedunu> good morning
<Adri2000> I've got a bug waiting for archive admin action since last december (#1086468). did I do something wrong? :)
<seb128> bug #1086468
<ubottu> bug 1086468 in obm (Ubuntu) "Please remove obm source and binaries from raring" [Wishlist,Confirmed] https://launchpad.net/bugs/1086468
<seb128> Adri2000, seems not, it's just that removal are not always done regularly I think
<Adri2000> as long as it's processed before raring is released, it's ok for me :)
<seb128> it will, no worry
<didrocks> doing right now :)
<didrocks> Adri2000: done
<Adri2000> didrocks: thanks
<didrocks> yw
<pitti> seb128: I'm not a big fan of a comment field for whoopsie reports because we are never going to actually review them all
<pitti> seb128: and it would create the impression that this is a kind of bug report
<pitti> seb128: I'd much rather see the "collect extra information" or "request filing a bug report the next time" flag
<seb128> pitti, we could have both ;-)
<seb128> not denying we need the "request info"
<seb128> but as said going through an hundred description can be enough to see a pattern
<seb128> like "I was changing user when it happened"
<seb128> 5 of those in a long stack can be enough to give an useful clue
<pitti> seb128: for those I'd personally prefer a bug report
<pitti> seb128: but anyway, I'm not strongly vetoing this, I'm just not a fan of it
<seb128> pitti, @bug report, I though the idea was to stop reports to launchpad, so we need to get the infos we need linked to the whoopsie reports
<pitti> seb128: right, but add a flag "the next person to encounter that please file a bug report", and it waits until someone actually does
<pitti> there will always be cases where we need a proper dialog with reporters
<seb128> pitti, right, I just feel like if we start automatically abusing that feature to ask "what were you doing" on most bugs then it's a sign that something is not right in the system
<seb128> and that maybe the info should be asked upfront
<seb128> oh well, let's see how it works in practice
<seb128> bdrung, so, after sponsoring libreoffice for Sweetshark, do you feel more comfortable for the ppu? should he run again, or is there anything you recommend him to work on/change to be accepted?
<seb128> bdrung, the details you found/fixed in your review seems mostly small and old packaging glitches, mostly cosmetic or coming from Debian, not mistakes from Bjoern
<davmor2> hey guys I have done a fresh install of Raring on my Lenovo Y580, good news bluetooth now works out of the box huzzah, bad news the screen is black because it is dimmed right down, I have to wait for the drums and then I can up the brightness, is there any info I can get on it for you
<xnox> micahg: announcement? =)
<mdeslaur> cyphermox: FYI, I'm going to nag you to get dnsmasq 2.66 into raring as soon as it comes out
<mdeslaur> cyphermox: 2.65 breaks local resolution with libvirt
<cyphermox> mdeslaur: ok
<smoser> jodh, ping wrt https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/1124384
<ubottu> Ubuntu bug 1124384 in cloud-init (Ubuntu) "reload-configuration can confuse upstart" [High,Confirmed]
<jodh> smoser: were you running upstart in debug mode at the time?
<smoser> have have dmesg output with --verbose
<smoser> i can easily get you --debug
<jodh> smoser: yes please
<smoser> slangasek, i'd appreciate your thoughts/input on bug https://bugs.launchpad.net/ubuntu/+source/cloud-initramfs-tools/+bug/1123220
<ubottu> Ubuntu bug 1123220 in cloud-initramfs-tools (Ubuntu) "cloud-image VM causes kernel panic if image is resized" [Low,Triaged]
<SpamapS> are there known bugs in raring causing X to repeat keypresses a lot? like just normal typing but suddenlllllllllllly l repeates a bunch?
<smoser> i've not seen that.
<SpamapS> I hesitate to report bugs from my old macbook pro.. because it has been dist-upgraded early in each cycle since it was installed with 10.10 alphasomething
<SpamapS> but its getting rather frustrating :-P
<dobey> i've never seen that either
<infinity> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Open | Dev' 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: infinity, smoser
<dobey> only on my phone, which isn't ubuntu
<jdstrand> hallyn: hey, fyi, I just pushed libivt ubuntu5 for an apparmor denial
<jdstrand> hallyn: libvirt*
<smoser> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Open | Dev' 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: infinity
<hallyn> jdstrand: ok.  possibly related to the nova bug zul was mentioning?
<jdstrand> I doubt it: access to @{PROC}/sys/vm/overcommit_memory r
<jdstrand> seemed like a harmless denial
<jdstrand> (but noisy)
<hallyn> oh, ok
<apw> slangasek, can you remind me when and who switches us to vt during boot
<apw> slangasek, in the non vt-handoff case
<user12423> is ubuntu 12.04.2 released yet?
<cjwatson> user12423: Nearly but not quite
<cjwatson> Sorting out the tail end of testing
<user12423> cjwatson: how much time will be take? Will it be released today?
<cjwatson> Let's just say that I'm doing the release, I'm in the UK, and I want to be able to go to the pub with a clear conscience this evening
<mdeslaur> hehe
<user12423> cjwatson: I have read that ubuntu 12.04.2 comes with kernel 3.5. Will it work with proprietary ati drivers for radeon 4000 series as they are not compatible with quantal?
<cjwatson> I'm afraid I don't know; you'll have to ask X folks, perhaps #ubuntu-x
<user12423> cjwatson: ok thanks
<infinity> user12423: Installing with 12.04.1 media and upgrading will have you on a 3.2 kernel by default, if you have a proprietary blob that hates 3.5
<user12423> infinity: amd recently updated their legacy drivers to version 13.1, don't they work too in 3.5?
<infinity> user12423: I have no idea, they may well work.  I was just saying "if they don't.."
<user12423> infinity: ok
<seb128> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Open | Dev' 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: infinity, seb128
<hallyn> slangasek: is the ovmf package intended to have a readme?
 * hallyn wiating for src to d/l over slow link
<hallyn> ok, i guess it's just my iso that's the problem - waiting for an even longer release iso d/l :)
<quadrispro> hi everybody
<quadrispro> I see dogtail is currently blacklisted, could anyone remove it from the sync-blacklist? Upstream has started again to develop and support dogtail, I took it in Debian
<quadrispro> the latest release is available in experimental
<mitya57_> quadrispro: https://bugs.launchpad.net/ubuntu/+source/dogtail/+bug/460210/comments/8
<ubottu> Ubuntu bug 460210 in dogtail (Ubuntu) "Sync dogtail 0.8.1-1 (universe) from Debian experimental (main) and remove it from the blacklist" [Wishlist,Triaged]
<quadrispro> mitya57_, cool! thanks, I'll look into it
<quadrispro> mitya57_, uploading the patch to experimental in few minutes
<mitya57_> quadrispro: great, please also leave a comment on that bug
<didrocks> barry: it seems you didn't merge oneconf 0.3.3 to lp:oneconf?
<barry> didrocks: in a meeting...
<mitya57_> quadrispro: did you really want to remove "def _getEncoding(self):" line?
<mitya57_> nevermind, I've got confused by diff output :)
<quadrispro> eh yes :) np
<quadrispro> see you around
 * mitya57_ wishes good night to everybody
<seb128> stgraber, hey, can you set https://code.launchpad.net/~baltix/ubuntu/precise/ubuntu-defaults-builder/remove-quotes-from-firefox-bookmarks-titles/+merge/137107 as "work in progress"?
<stgraber> seb128: done
<seb128> stgraber, thanks
<slangasek> smoser: bug #1123220> hmm, that seems to me that your a) option is the best (kernel not attaching /dev/console to something that doesn't work)
<ubottu> bug 1123220 in cloud-initramfs-tools (Ubuntu) "cloud-image VM causes kernel panic if image is resized" [Low,Triaged] https://launchpad.net/bugs/1123220
<slangasek> apw: what do you mean by "to vt"?
<timrc> wookey, Hi, I've been trying to figure out multistrap.. I noticed in raring version, 2.1.6ubuntu3, still contains /usr/share/multistrap/ubuntu/crosschroot-maverick.conf -- would you like me to file a bug on this?
<slangasek> hallyn: I didn't put any readme in the ovmf package, no
<smoser> slangasek, but kernel is really dumb
<smoser> and that assignment happens really early
<smoser> back some time ago i had smb investigate a bit and he seemed to think that was non-trivial
<smoser> even in the event that the kernel was smarter, having safety code in upstart and initramfs seems like it wouldn't hurt.
<slangasek> smoser: well, in this case you say it's crashing in the initramfs, right?  we might reasonably be able to make upstart itself more robust against a broken /dev/console... but not every command that might write to stdout in the initramfs.
<smoser> sh -e 'echo hi; echo by' should not exit failure.  thats just not friendly to anyone.
<smoser> slangasek, my suggestion was that in the initramfs (early) we do the code i posted.
<slangasek> smoser: yes, but afaics that would merely be advisory?
<smoser> basically redirecting to somewhere in /run or /dev/null if we can't find something useful.
<smoser> huh?
<slangasek> oh, you're proposing actually redirecting, ok
<smoser> oh. yes, clearly if some other script in the initramfs opened /dev/console explicitly, then i can't stop that.
<smoser> but stdout shouldn't be broken.
<slangasek> well, init will reopen the console
<slangasek> I don't know if it fails in this case
<smoser> right.
<smoser> so upstart would need the same thing.
<smoser> open succeeds
<smoser> writes fail
<slangasek> I really think this needs to be fixed in the kernel
<slangasek> trivial or not
<slangasek> /dev/console should not be broken when you write to it
<smoser> slangasek, it seems like maybe my suggested work aroudn wouldn't work.  see https://bugs.launchpad.net/maas/+bug/1061977/comments/4 . i'm not certain  that is correct, but i seem to remember that some writes to /dev/console worked fine.
<ubottu> Ubuntu bug 1061977 in MAAS "Machine fails to commission when console=ttyS0 is present on kernel opts" [Critical,Fix released]
<smoser> as if there was a buffer that got filled up and it didn't fail until kernel tried to flush that
<slangasek> smoser: yeah, I was just going to say, if this is related to the other bugs I've seen before in this area, there's probably kernel buffering making a mess of it besides
<smoser> fwiw, we have 'console=ttyS0' (and want to keep that) because cloud providers (ec2 and openstack at least) give you access to data written to the serial device
<smoser> so you can view that log.  if we have *no* console= parms, then it goes to a vga device, which is completely useless.
 * slangasek nods
<hallyn> slangasek: ok - i just wasn't sure if there was something i could/should do to work around the 'secure boot not enabled' msg.
<slangasek> hallyn: you can nag me to fix that output from shim :)
<hallyn> nag, i can do that :)
<seb128> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Open | Dev' 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: infinity
<ogra_> geez
<ogra_> nighflight
<zykes-> 7win 38
<m4n1sh> Laney, cjwatson : is the feature freeze applicable to a main package which has a revamped UI but hardly any new features. I hope so, but just cross checking
<m4n1sh> AFAIK you both are in release team
<RAOF> The UI would most certainly be considered a feature. :)
<m4n1sh> RAOF: please tell me you are joking
<m4n1sh> or maybe my sarcasm detector is broken
<xnox> m4n1sh: https://wiki.ubuntu.com/FeatureFreeze
<RAOF> I'm not sure how you'd significantly rework the UI *without* requiring a FFe.
<xnox> m4n1sh: also note https://wiki.ubuntu.com/FreezeExceptionProcess#UserInterfaceFreeze_Exceptions
<RAOF> Or, to put it another way, a revamped UI is *definitely* a feature.
 * xnox once revampted a non-essential ubiquity screen - only to crash by default the installer due to i18n error
<xnox> m4n1sh: the point is that it's potentially disruptive and can introduce bugs.
<xnox> when one least expects them.
<m4n1sh> yeah, introducing bug is surely the biggest problem
<m4n1sh> xnox: Thanks. So that means I am really short of time
<xnox> m4n1sh: what package is it?
<m4n1sh> xnox: activity-log-manager
<m4n1sh> The new design by matthew paul thomas
<m4n1sh> it has been present since long and implemented too, but I am fighting with the code (some startup issues) and build system
<xnox> m4n1sh: right so User Interface Freeze is on the 21st. Just work through it and polish it, then request FFe and everything will be good.
<xnox> m4n1sh: you have 5 weeks \o/
<RAOF> You might also want to ask for a *preemptive* FFe; the release team like to know what's coming up.
<m4n1sh> xnox: yeah. Just hopeful it doesnt break anything new.
<m4n1sh> RAOF: Yes. that would be better
<m4n1sh> xnox: this is the mockup https://lh4.googleusercontent.com/aYbxFHevnMXUmWkVF73FXF1IGj8AaxMRWCZKJb71V3vsKpWWEVmlZ7S9U-QKV3UuquFSbeU5PxnFoVXxMSlwxzfQCDmh38wKJF9ztV7MW_v_kcvO31U
<m4n1sh> Just FYI
<xnox> m4n1sh: the joined up dropdown + and - buttons with toolbar inline style in gtk has a bug where it will not look joined up, just so you know
<lifeless> cjwatson: can grub2 read kernel + initramfs from within a raid6 mdadm array ?
 * xnox has some glade work with a similar pattern from mpt for ubiquity
<m4n1sh> xnox: in raring?
<xnox> m4n1sh: it did in quantal, didn't check raring recently.
<xnox> m4n1sh: yeap still broken - open "Videos" (totem) and look at the buttons just below the playlist
<m4n1sh> xnox: I can see this http://i.imgur.com/vUJkhpT.png
<xnox> m4n1sh: the most right "v" button should be rounded on the right
<xnox> e.g. (+ | - | v | ^ | v ) not (+ | - | v | ^ | v ]
<m4n1sh> xnox: oh yeah. It slipped my eyes, I thought you were talking about the buttons being spaced apart
<m4n1sh> yeah, that is a bug
<xnox> but it's a theming issue.
 * xnox filed it against light-themes but still not fixed. maybe i'll have to write the patch =(
<xnox> m4n1sh: i could also trigger it to appear as ( | )[ | | ] which is even more ugly =/
<m4n1sh> yeah, or every button be squared
<m4n1sh> atleast that would have consistency
#ubuntu-devel 2013-02-15
<cjwatson> lifeless: believe so, it certainly had raid6 code last I looked
<cjwatson> not sure how well-tested but I think it's been at least tried ...
<lifeless> cjwatson: cool, thanks.
<lifeless> cjwatson: I'll poke around, I just couldn't seem to get a clear 'should' or 'no chance' from google ;)
<slangasek> smoser: regarding bug #1080841, what was the use case for overlayfs on /etc/init?
<ubottu> bug 1080841 in cloud-init "should reload configuration if an upstart job is added" [Medium,Fix committed] https://launchpad.net/bugs/1080841
<psusi> lifeless, I know it works for raid5, and there is a raid6 module as well, so I assume it works too
<lifeless> ok cool
 * lifeless is nearly ready to cut over his migrated home server
<psusi> migrated?
<lifeless> psusi: same chassis, 4 new 3TB disks in an external enclosure;
<psusi> I was playing with grub today trying to come up with an install that has everything in the core image since with partitions being 1mb aligned these days, there's plenty of room for it... be nice to have access to everything you might need to recover from a failed boot
<lifeless> psusi: once its all checksummed etc I'll move them inside the chassis
<lifeless> psusi: but I'm tossing the seperate /boot
<psusi> I have a server at work that only can boot from cd, so now that cd installs are no longer supported, recovering on it is a pain when grub fails as it did for me the other day
<lifeless> psusi: in favour of gpt + bios boot partition
<psusi> hrm... 3 tb?  make sure /boot partition is under 2tb
<lifeless> the old disks are from - uhm, 2007 IIRC.
<lifeless> psusi: no /boot at all; a ef02 partition instead
<lifeless> psusi: thats 10MB
<psusi> you'll need a /boot since the bios can't access past 2tb
<psusi> or you might get it to work with the grub ata disk module to bypass the bios
<lifeless> fallback plan is a usb stick shoved in the front :)
<psusi> no uefi? ;)
<lifeless> motherboard was made in 2007.
<psusi> at least it boots from usb.. my server at work won't even do that
<lifeless> it even has a floppy drive
<psusi> to get it to boot I finally ended up booting the precise server cd in recovery mode, mounting the drives, and using kexec to boot the installed kernel ;)
<psusi> but yea, watch out for the 2 tb limit... if parts of the fs needed to access the kernel and initrd are above that, you'll have a problem
<lifeless> I thought that was a fdisk partition table limit
<psusi> it's that too, but it is also a bios limit iirc... 32 bit lba in the extended lba bios disk call
<psusi> afair
<lifeless> :(
<lifeless> will find out
<StevenK> That's why I have a /boot as the first partition on large disks
<psusi> hrm... time to go look up extended int 13 again
<psusi> oh wait.. no... looks like the extended int13 is 64 bit according to wikipedia
<psusi> though most biosen probably ignores the upper 32 bits ;)
<psusi> lifeless, oh, and the bios_grub partition only needs to be 1MB... even when I threw everything and the kitchen sink into the grub core image today it was just a hair over 512k
<psusi> which it turns out is too large to load in real mode ;)
<ScottK> Sigh.  I'd appreciate any suggestions why opendkim now FTBFS?  There does not appear to be anything in the diff between the two uploades - http://paste.debian.net/234349/ - that at all relates to the build failure: https://launchpadlibrarian.net/131287010/buildlog_ubuntu-raring-i386.opendkim_2.8.0~beta4-1_FAILEDTOBUILD.txt.gz - openldap hasn't changed either.  Was there a recent change in linker behavior?
<pitti> Good morning
<dholbach> good morning
<pitti> tjaalton: I was looking at https://jenkins.qa.ubuntu.com/view/Raring/view/JHBuild%20Gnome/job/jhbuild-amd64-mutter/113/artifact/mutter.log and discussed that with upstream; they said that our libxi package is "marked as a version that supports barriers, but we reverted that feature"
<pitti> tjaalton: is that known?
<tjaalton> pitti: this is new mutter?
<pitti> tjaalton: upstream git head, yes
<pitti> PKG_CHECK_EXISTS([xi >= 1.6.99.1],
<pitti>                  AC_DEFINE([HAVE_XI23],[1],[Define if you have support for XInput 2.3 or greater]))
<pitti> tjaalton: it's doing that -- would it be prudent to also revert the version in the .pc while the "revert barriers" patch is applied?
<tjaalton> we're staging the upstreamed barrier events stuff in canonical-x/x-staging, needs unity ported until it's useful
<tjaalton> oh
<tjaalton> yeah I accidentally uploaded the new libxi to raring
<tjaalton> that sounds doable yes
<pitti> tjaalton: mind if I just do that, or would that disrupt some git/bzr packaging tree?
<tjaalton> pitti: nah just do it, I'll pull the diff if needed
<tjaalton> need to hardcode it in xi.pc.in
<pitti> tjaalton: ok, thanks; I don't see a .pc change in http://launchpadlibrarian.net/130564301/libxi_2%3A1.6.1-1_2%3A1.6.99.1-0ubuntu1.diff.gz , I guess it's determined from configure.ac
<tjaalton> yep
<happyaron> Who should I ask for NEW processing?
<Dedunu> HI im going to fix this https://bugs.launchpad.net/hundredpapercuts/+bug/694283 so how to check installation fixes any idea?
<ubottu> Ubuntu bug 694283 in One Hundred Paper Cuts ""Encrypt my home folder" should be disabled when "Log in automatically" is selected" [Low,Confirmed]
<caribou> what would be preferable for a debootstrap SRU patch : Merge proposal or debdiff ? I'm fine with both
<caribou> this is for Lucid btw
<cjwatson> caribou: don't much care but I find MPs a bit awkward for stable releases to be honest
<caribou> cjwatson: ok, I'll attach a debdiff to the bug
<caribou> cjwatson: btw, I had to slightly adapt your commit: yours used checksum & verify_checksum while the old version was still using md5/check_md5
<cjwatson> Doesn't surprise me
<Dedunu> caribou: cjwatson: so im working on papercuts
<Dedunu> cjwatson: caribou: i want to test those after fixing
<caribou> Dedunu: my guess is that you'll need to recreate the install media to test it, but I'm not an expert @Ubiquity
<caribou> Dedunu: that's partly what I had  to do to test my debootstrap fix
<caribou> Dedunu: I used https://help.ubuntu.com/community/InstallCDCustomization to rebuild my archive
<cjwatson> with ubiquity it's easier to just boot into a live session, apply your fix to the installer (which you can generally do just with an editor since it's mostly in interpreted languages, or perhaps by scp-ing files into place), and then run the installer
<Dedunu> caribou: cjwatson: im a starter its better to keep it away for a while
<cjwatson> recreating the install media is usually about ten times more work :)
<Dedunu> i think it is very easy to fix but hard to test for me
<cjwatson> *if* you already know what you're doing
<Dedunu> i thought recreating installation media it easy
<caribou> cjwatson: true, I just went through that pain :-/
<cjwatson> Dedunu: it's considerably more effort than editing a file
<cjwatson> no matter what way you slice it
<Dedunu> hmm
<Dedunu> thanks guys ill look into something else
<Dedunu> on papercuts
<cjwatson> ntfs-3g (1:2013.1.13-1) raring; urgency=low
<cjwatson> xnox: ^- uh, didn't you just steal a Debian version number?  please don't do that ...
 * cjwatson anticipates future merge pain :(
<xnox> cjwatson: yes i did.
<xnox> =(
<xnox> and it even has ubuntu changes, so it totally should have been -0ubuntu1
<Laney> ruh roh
<OdyX> tkamppeter, pitti: as you maybe saw, I uploaded cups 1.6.1-2, that you can just sync.
 * xnox ponders about 1:2013.1.13-1+0ubuntu1
 * xnox files a bug against bzr-builddeb
<seb128> Riddell, hey, I just newed qtscript, only source left in the queue is qt3d ... did you start looking at this one?
<Riddell> seb128: I've not looked at it no
<seb128> Riddell, do you plan to today? or should I give it a try? ;-)
<Riddell> seb128: looking at New queue is on my todo for the day but low down
<Riddell> seb128: so either do it yourself or keep poking me to do it
<seb128> Riddell, ok, I will get started on it then, let's see if I manage to go through this one, I will let you the other stuff in the queue then ;-)
<pitti> OdyX: thanks!
<mpt> m4n1sh! Long time no see!
<syntroPi> Why is firefox still not using the system libcairo2? the integrated libcairo2 has a bug that prevents it from unsing gnome3 subpixel rendering (I have BGR monitor but only FF renders RGB rainbow fonts, very annoying to read)...?
<shadeslayer> cjwatson: any news on updating live-build?
<mpt> syntroPi, I think you have just explained a bug I have been suffering from for years ... For me, Firefox and Thunderbird fonts are extremely hinted, while all other apps look fine
<syntroPi> mpt there were bugs in libcairo2 from ubuntu which caused it not to respect gnome subpixel rendering set from BGR to RGB. there was a patch for that (a switch statement had a "break;" missing) and in newest version on quantal it seems to be resolved. but thats only system libcairo2, the ff version still seems to have this bug included therefore I suspect it not to use "--enable-system-cairo"
<syntroPi> but maybe thats for a reason since ff uses heavy patched versions of cairo2
<Laney> Perhaps firefox's cairo could pick this other patch up then
<syntroPi> i hope it would be integrated but im not sure im competent enough to submit such a patch
<m4n1sh> mpt: yeah. Your mockup has been implemented and added to alm. Only if I could get the thing working. Some gtk issues and as usual autotools is acting weird
<mpt> m4n1sh, awesome! (Took me a few seconds to work out what "alm" meant)
<m4n1sh> oh yeah. sorry for that. I should call it privacy
<mpt> m4n1sh, I think it would be fine for all those buttons to be square, actually
<m4n1sh> is there a way to override the theme?
<mpt> They aren't a radio set, or a navigation set
<mpt> I don't know, sorry, that's more of a question for Cimi
<m4n1sh> yeah. I think so. First I need to get that gtk issue solved. The application isn't showing the window. I know very stupid issue, but I think I made some change which broke it
<syntroPi> someone here who knows the internals of firefox package and willing to help me with integrating a known patch to libcairo2 in it?
<syntroPi> am currently compiling it to take a browse at the patched sources
<syntroPi> and that thing is _HUGE_
<seb128> syntroPi, talk to chrisccoulson
<syntroPi> seb128, thx but i will need some time to gather all info when the compile is complete...
<seb128> syntroPi, well, you asked "who", I just replied to that
<syntroPi> yup
<wookey> what is libaudit-dev for? New pam uses it and is getting in the way of my bootstrap
<wookey> can I just turn it off? or does it need to be made to work, along with libcap-ng (which woulw need de-swiging)
<cjwatson> wookey: -> slangasek
<cjwatson> but from the changelog:
<cjwatson>   * Enable audit support, by popular demand.  This should have no major
<cjwatson>     impact unless you're also running auditd; but I reserve the right to
<cjwatson>     disable this again in the event that this causes a performance hit or
<cjwatson>     breaks upgrades (since the dependency is pulled into libpam, not just
<cjwatson>     into pam_tty_audit).  Closes: #699159, LP: #937005.
<ubottu> Launchpad bug 937005 in pam (Ubuntu) "pam_tty_audit.so is missing in oneiric/precise" [Undecided,Fix released] https://launchpad.net/bugs/937005
<wookey> there is a --dsiable-audit know so I shall use it
<cjwatson> Disabling it for the bootstrap doesn't seem like it would be a massive problem, based on that.  I'm not sure whether that's the correct place to insert a stage.
<wookey> yes. It may be better to build libcap-ng without language bindings, but this'll do for now
<wookey> I got rid of a bootstrap-modified package momentarily as nice new pam had updated autofoo, but then it broke with audit :-(
<caribou> pitti: just read your reply to my email about apport mods for kdump-tools
<caribou> pitti: looks like I may have mixed up the order. Which solution do you think would be better to implement ?
<caribou> pitti: have the upstart script traverse the /var/crash/{timestamp} dirs or /usr/share/apport/kernel_crashdump ?
<pitti> /usr/share/apport/kernel_crashdump does all the processing you want, but that's just my gut feeling
<pitti> caribou: I don't have a strong opinion either way, but smearing out the logic over many doesn't seem to make things easier
<pitti> caribou: bbl, lunch
<caribou> pitti: sure, ttyl
<dupondje> pitti: any chance to check https://bugs.freedesktop.org/show_bug.cgi?id=53029 ? :)
<ubottu> Freedesktop bug 53029 in PAM module "There is no authentication function when printing using CUPS on the network" [Major,Reopened]
<pitti> dupondje: re (meeting)
<pitti> dupondje: I'm afraid this bug doesn't tell me anything -- it speaks about LibreOffice, cups authentication, and is against ConsoleKit !?
<jcastro> Now that cd size doesn't really kill us anymore can we put real vim on the default install again?
<cjwatson> jcastro: can't say I'd object, certainly ...
 * cjwatson â hugely biased
<jcastro> yeah me too, I mean, it's some kind of law, we have to have vi, and the one in there isn't very good.
<jcastro> I am wondering if it's worth bringing up seriously, or if it's too geeky
<dupondje> pitti: well didn't create that bug :) The issue is that when printing in LibreOffice to a network printer (samba), it doesn't ask a password
<dupondje> so the print job cannot be sent to the network printer
<dupondje> if you print in gedit for example, it just gives a popup for credentials
 * xnox would like to change nano to have -E option enabled by default
<xnox> jcastro: only if we add zile as well
<tjaalton> xnox: that would be bad for makefiles :)
<xnox> tjaalton: but it's totally bad for python files
<pitti> dupondje: I reassigned it to LibO
 * xnox ponders to wrap a file call around nano to set -E for python.
<dupondje> pitti: thx, I guess its libreoffice gui that should ask for a passs?
<pitti> dupondje: they have their own dialogs, yes; they don't use the GTK ones
<dupondje> k :) cause not being able to print in a office package is quite a blocker imo :P
<pitti> well, it's one rare use case
<pitti> it doesn't seem to me that a lot of office workers woudl be required to supply a password every time they print
<dupondje> password protected print share isn't that weird
<dupondje> anyway :) should get fixed
<cjwatson> actually that's the wrong way round isn't it
<ogra_> whats wrong with his connection ?
 * ogra_ doesnt see crazy join/part messages or so
<ev> woo, thanks cjohnston
<ev> cjwatson:
<cjwatson> it was broken some days ago but Fuchs removed the ban last night
<ogra_> oh
 * ogra_ sees the other channel
<cjwatson> 00:08 -!- mode/#ubuntu-devel [-b *!*@ubuntu/member/evand$##fix_your_connection] by Fuchs
<ogra_> yep
<cjwatson> So I didn't actually do anything other than accidentally restore it briefly :)
 * ogra_ found the answer in #ubuntu-context :)
<ogra_> (also called -release)
<hallyn> all right so when you boot without 'quiet splash', after the boot text has scrolled by, the text font changes right before x starts..  is that the console-setup-tty done the udev rule (85-kbd-cofig)?
<hallyn> or the actual loading of fb module?
<ogra_> there are two console-setup runs ... one is from the udev rule the other from an upstart job
<ogra_> (both do the same afaik)
<ogra_> and if you set FRAMEBUFFER in your initrd config you can enable a third one in the initrd
<ogra_> (or if you use break=)
<hallyn> right i've commented out the one from upstart
<hallyn> (locks up right after that)
<ogra_> then it should be the udev rule
<hallyn> ok thanks
<slangasek> wookey, cjwatson: I've actually already had to re-disable libaudit in Debian because unstable is still using libaudit0 which isn't multiarched; so if you guys think this is a problem for bootstrapping we can back it out in Ubuntu too for now.  Though in any case, stage patches welcome
<pitti> so, I keep getting "Connection was refused by other side: 111: Connection refused." with current juju in raring and CanoniStack/EC2; that did work until some weeks ago; is anyone else using this?
<pitti> (both for bootstrap and for status)
<hrw> btw - does someone know some xmodmap/xkb editor which can be used by person lacking any knowledge of x11 internals?
<cjwatson> slangasek: I feel stagifying pam for this would be the wrong answer; best to do the staging further down, I think in libcap-ng in this case
<pitti> I used xev to determine keycodes, and then just write reasignments into ~/.xmodmaprc
<pitti> hrw: ^
<hrw> pitti: chromebook is nice laptop for travelling but lack of pgup/dn and delete keys makes some things complicated
<pitti> hrw: my ~/.xmodmaprc swaps Escape and Caps Lock
<pitti> I need Esc all the time (vim), but never ever Caps Lock
<hrw> I usually have Ctrl on CapsLock
<hrw> \
<hrw> Chromebook has Meta instead of CapsLock
<wookey> slangasek: I've done a stage patch. Will file shortly
<slangasek> wookey: thanks
<wookey> filed https://bugs.launchpad.net/ubuntu/+source/pam/+bug/1126404
<ubottu> Ubuntu bug 1126404 in pam (Ubuntu) "pam needs a build profile for bootstrapping without libaudit" [Undecided,New]
<cjwatson> Ah, I hadn't realised audit needed explicit porting to new architectures
<cjwatson> Fair enough then
<scientes> also the audit defines for arm is in <elf.h> but <audit.h> for x86
<scientes> * <linux/audit.h> i believe
<scientes> AUDIT_ARCH_ARM
<bigon> wookey: are you planning to proposed that patch for pam to debian too?
<cjwatson> bigon: "16:04 <slangasek> wookey, cjwatson: I've actually already had to re-disable libaudit in Debian [...]"
<stokachu> in the installer i see things such as debconf: --> GET netcfg/get_ipaddress followed by debconf: --> INPUT critical netcfg/bad_ipaddress
<stokachu> but im not sure where in the code for the installer this is located
<cjwatson> stokachu: apt-get source netcfg
<bigon> cjwatson: ah well, thanks
<stokachu> ah there we go
<cjwatson> and that's due to preseeding static networking without preseeding all the necessary things that go with it
<cjwatson> wouldn't happen interactively - you'd be asked for the IP address
<stokachu> i think from the logs it stated it was using ubuntu-server preseed file
<stokachu> lemme double check
<cjwatson> Certainly not the stock one on server CD images
<stokachu> Command line: file=/cdrom/preseed/ubuntu-server.seed vga=788 initrd=/install/initrd.gz DEBCONF_DEBUG=developer
<stokachu> thats not one we provide?
<cjwatson> We do, but I bet that's been modified by somebody somehow
<cjwatson> Because our default preseeding does not use static networking
<cjwatson> It should be possible to see what that file contains a bit earlier in the log, when file-preseed runs
<stokachu> the OP stated that in debug mode it will ask the user for static ip
<cjwatson> Somebody's probably preseeded netcfg/use_autoconfig=false, or interactively answered an equivalent question
<stokachu> and without it is when the malformed IP address error is shown during interactive mode
<stokachu> ok
<cjwatson> If you show me the whole bug and syslog I can look
<cjwatson> ah, right, it's fallen back to static networking because DHCP failed, I guess
<stokachu> yea it looks like the link isn't ready in time
<stokachu> cjwatson: i pm'ed you the case
<stokachu> the link seems to become available and it looks like we try to get the ipaddress from that
<stokachu> and thats where the failure occurs with the malformed ip
<cjwatson> Don't agree :)
<cjwatson> I'm following up to the bug
<cjwatson> But the IP address error is a red herring
<wookey> bigon: pretty much everything I've filed in last month needs to go to debian too
<wookey> but I've not got round to making corresponding patches for whatever the debian version is
<cjwatson> stokachu: followed up
<stokachu> cjwatson: interesting, do you think b/c dhcp took longer than someone was willing to wait they cancelled it
<stokachu> ?
<cjwatson> stokachu: look at the timestamps though
<stokachu> ah yea
<cjwatson> If they did cancel it deliberately they were bloody quick off the mark
<stokachu> someone had a trigger finger
<cjwatson> Which is why I was wondering if somebody might have left a book on the F12 key :)
<cjwatson> Or something along those lines
<stokachu> hah ok ill see if they can run some more tests
<stokachu> cjwatson: thanks :)
<cjwatson> Actually, following up again
<doko> what was the replacement for jockey in quantal?
<cjwatson> ubuntu-drivers
<cjwatson> -common
 * ogra_ wtaches doko tunring into a gamer 
<ogra_> :)
<Sarvatt> doko: last tab in software sources if you're asking where the gui is (yeah that makes no sense to me either)
<ogra_> it didnt make much sense where it was before either ...
<ogra_> when we had it pop up and show a notification icon, that made sense ...
<ogra_> but that is gone
<cjwatson> stokachu: demonstration: boot a server image in kvm and hold down enter.  you'll see exactly the same effect.
<stokachu> ah interesting
<stokachu> yea from the SS itlooks like they are using some virtual console through ilo to do the installation
<slangasek> hallyn: have you seen anything like bug #1126488, by chance?
<ubottu> bug 1126488 in dnsmasq (Ubuntu) "libvirt instance of dnsmasq in raring fails to forward DNS requests" [Undecided,New] https://launchpad.net/bugs/1126488
<hallyn> slangasek: no, not that i've noticed
<hallyn> zul: ^ ?
<slangasek> ok
<sarnold> slangasek: does this look like it? https://bugzilla.redhat.com/show_bug.cgi?id=894486
<hallyn> (but for most vms that i end up hitting the net with, i don't use libvirt)
<ubottu> bugzilla.redhat.com bug 894486 in vulnerability "CVE-2013-0198 dnsmasq: Incomplete fix for the CVE-2012-3411 issue" [Low,New]
<zul> hallyn: nope
<sarnold> slangasek: 2.66test13 has a fix for the fix for the fix.... see if https://launchpad.net/~mdeslaur/+archive/testing dnsmasq fixes your issue?
<slangasek> sarnold: thanks, I'll give it a try later today
<slangasek> xnox: do you know the status of bug #1095117?  You had it marked 'in progress', someone else marked it 'fix released', I've just seen the crash here
<ubottu> bug 1095117 in software-center (Ubuntu) "update-software-center-channels crashed with NameError in trigger_axi_update_and_wait(): global name 'GLib' is not defined" [High,Fix released] https://launchpad.net/bugs/1095117
<slangasek> sarnold: looks like mdeslaur's package fixes the dnsmasq issue
<xnox> slangasek: i know the fix went into lp:software-center. I did request for it to be released into raring + stable releases.
<slangasek> ok
<xnox> I don't know if it has or not.
<slangasek> xnox: I've reopened the bug; it's still assigned to you, dunno if that's correct
<xnox> we have an software-center uploader now
<xnox> maybe i should just cherry pick....
<xnox> dobey: can you cherry-pick bug 1095117 into raring/quantal/precise (i think it applies to all three)?!
<ubottu> bug 1095117 in software-center (Ubuntu) "update-software-center-channels crashed with NameError in trigger_axi_update_and_wait(): global name 'GLib' is not defined" [High,Triaged] https://launchpad.net/bugs/1095117
<dobey> xnox: well, i plan to do a software-center release as soon as i can. i don't know when i'd be able to get the quantal/precise SRUs done though
<xnox> dobey: that bug is high on errors
<dobey> my cup, it overfloweth with things i need to do
<xnox> =/
 * xnox notes down to buy a bigger cup for dobey
<xnox> no worries =)
<dobey> xnox: ok, there are a few others too. and the switch to python-oauthlib has created a few critical issues;
<xnox> dobey: will you be able to pick things up if I cherry pick and upload stuff and not loose it in subsequent uploads?
<dobey> switch in u1
<xnox>  /o\
<dobey> xnox: i don't know what you mean by cherry pick exactly. software-center is a native package (and a pain)
<dobey> xnox: if you want to propose branches against the older series, i can review them though, and you can make releases into {precise,quantal}-proposed from the appropriate series branches i suppose
<xnox> dobey: oh is that how you manage it, sounds good.
<xnox> dobey: which branches are used for what?
<xnox> well 5.2 and 5.4 easy =)
<dobey> xnox: no. i only started dealing with software-center recently. so mostly nothing is how i would generally manage things at the moment :)
<dobey> but that will change soon
<xnox> i'll follow current state of affairs and i hope that won't break things much for the future
<xnox> dobey: will it be autolanding?
<dobey> xnox: only trunk is managed by tarmac at the moment
<dobey> i haven't had time to deal with getting all the older branches converted to it
<dobey> xnox: but just go ahead and include the changes to debian/changelog in your branches for the older series as well, and i'll review/merge them, and then you can do the releases into -proposed for them
<xnox> ack.
<doko> jamespage, do you mind having bnd (and deps) in main?
<doko> to generate osgi files
<doko> bdrung, well, you added apparently hardening flags for these lo b-d's but did forget to add verbose build logs ... so how to validate from the build log?
<cjohnston> slangasek: ping
<slangasek> cjohnston: heya
<doko> bdrung, I had to look at the debdiff to understand "Fix hardening-no-fortify-functions lintian warning."
<cjohnston> slangasek: sorry. on shift and got a call right after i pinged you. iirc you were working on a fix in lp as far as blueprints being exported
<slangasek> cjohnston: well, once upon a time I was; IIRC though, Curtis nacked that branch
<cjohnston> slangasek: Do you remember the reason?
<slangasek> let me see if I can find it in LP
<slangasek> https://code.launchpad.net/~vorlon/launchpad/lp.994110/+merge/105078
<cjohnston> slangasek: i haven't made it back yet, and am still on my cell so i can't open the link right now
<slangasek> cjohnston: I frankly didn't understand that response, so I haven't followed up
<cjohnston> ok. ill look when i get back. it's something I'm very interested in right now.
<slangasek> '"We should only need to target the blueprint to the sprint to get it into the scheduler" is the insight needed to do the proper fix. Re-targeting is not updating the SpecificationDefinitionStatus for the drivers and workers to make it clear the definitionneeds to be realigned with the rest of the work for the series.'
<slangasek> I guess he means that this should be fixed deeper in LP, such that when you retarget a blueprint, the definition status is automatically changed
<slangasek> however, sprint != series
<slangasek> so I'm not sure I agree with that
<cjohnston> hrm. ok.
<cjohnston> thanks slangasek
<cjohnston> slangasek: fwiw, I read what he wrote as that the definition shouldn't be relevant to the blueprint being exported.. The blueprint should be exported if the blueprint is proposed for a sprint AND accepted for a sprint, regardless of what the definition is.. So removing the logic for the definition effecting what appears on the list
<slangasek> cjohnston: well, except that was what my branch implemented and he rejected it? :)
<cjohnston> He didn't reject it, he put a comment on it.. I am unable to tell from his comment if he is in favor of the change or not.
<cjohnston> nm. I stand corrected
<cjohnston> missed that
<doko> kirkland, https://launchpad.net/ubuntu/+source/ssh-import-id/3.12-0ubuntu1/+build/4304611
<kirkland> doko: hi
 * kirkland looking
<kirkland> doko: thanks
<kirkland> doko: why didn't I get a build-failure message?
<doko> kirkland, I don't know
<YokoZar1> slangasek: a fresh install of raring64 seems to reproduce the unable to install wine1.4:i386 without any additional futzing, not sure why it wasn't working in a chroot for you (maybe no ubuntu-desktop?)
<slangasek> YokoZar1: it was a chroot, definitely no ubuntu-desktop installed
<YokoZar1> slangasek: Yeah so the conflict is probably with some default but not essential package
<mlankhorst> YokoZar1: could you upload wine?
<YokoZar1> mlankhorst: new wine1.5 to PPA?  If it doesn't require any changes to the patches, sure.
<mlankhorst> afaict probably not
<YokoZar1> mlankhorst: kk
<mlankhorst> thanks
#ubuntu-devel 2013-02-16
<cjwatson> slangasek: mind if I sort out bug 1087843 for raring?
<ubottu> bug 1087843 in shim-signed (Ubuntu Raring) "[MIR] secureboot-db" [Undecided,New] https://launchpad.net/bugs/1087843
<cjwatson> Just an added Recommends
<slangasek> cjwatson: be my guest
<cjwatson> done, thanks
<psusi> hrm.. looks like ntfs-3g has ABI upstream ABI breakage
 * YokoZar1 has been finding a lot of edge cases where apt's resolver is wrong
<YokoZar1> This is slightly blowing my mind
<psusi> YokoZar1, oh?
<psusi> I spent today getting pissed at dpkg and it's slowness and trying to figure out debootstrap, and cdebootstrap, and patching them to use libeatmydata to get around the dpkg brokenness that the dpkg maintainers refuse to fix
<psusi> drives me nuts to see installs and upgrades spend several seconds on each of many very small packages, and constantly rebuilding initramfses and other things, many times over and over
<TheMuso> I thought initramfs rebuilding was taken care of by a trigger...
<sarnold> heh, at first I thought, "go try rpm for a change", but I'm pretty sure I've seen rebuilding initramfs twice in an upgrade before too...
<psusi> TheMuso, yea. and you would think that the introduction of triggers would have fixed it so it only gets rebuilt once, but it doesn't!
<psusi> I must normally see it 6 or 8 or 10 times in a dist-upgrade, I swear
<penguin42> yeh that really annoys me when doing cleanups - like removing 20 old kernels and seeing it rebuild for each damn one
<psusi> I found today that using libeatmydata makes a bare bones debootstrap time drop from 9m to 1m
<penguin42> psusi: That on spinning rust or ssd?
<psusi> raid5 array of spinning rust
<penguin42> yeh, it's a heck of a lot different on SSD
<psusi> dpkg really abuses the hell out of fsync and friends these days and it's absurd to watch it spend 1+ second on each of two dozen packages that are each under 100k in size
<penguin42> psusi: Conversely it's a heck of a lot worse on something like an SD card
<penguin42> yeh
<psusi> yea, but it's also putting a lot of wear and tear on your ssd which has limited write cycles
<penguin42> yeh, on an ssd it's not too bad, on the simpler SD cards they don't last a year
<psusi> I think dpkg syncs like 6 times per package, which is absurd
<penguin42> nod
<sarnold> a full sync(2)?
<sarnold> or fsync()?
<penguin42> psusi: It's not the only thing though; firefox is insane as well - try running a live slow-write USB stick image and firefox, it crawls because of it's sync's
<psusi> no, it tries to keep it limited with fsync or sync_memory_range, but still, it blocks until disk buffers, stripe caches, journals, hardware write caches, etc are all flushed
<psusi> oh yea.. that also keeps laptop drives from sleeping
<penguin42> which ends up blocking some entirely irrelevant read that means your GUI grinds to a crawl
<cjwatson> You should get mad at the filesystems that made all this necessary; dpkg didn't introduce any of this until compelled
<cjwatson> This is all pretty clear if you check the history
<psusi> that's not quite true.. it got worse because of the issue uncovered in ext4
<psusi> but it was always fairly bad
<cjwatson> If that was so, it wasn't due to sync
<sarnold> cjwatson: that's tytso's fault, right? :)
<psusi> iirc, it always fsynced the status file after every package status change, so for each package, it unpacks, writes unpacked status, fsyncs status file, then configures, writes status, fsyncs status again
<psusi> but it got worse with ext4 because it was using rename to atomically replace the old file with the new on upgrade, and in the case of ext4, it can commit the rename prior to the new file actually hitting the disk
<psusi> and ttyso thinks this is not a bug and told dpkg maintainers to fsync the new file prior to the rename...
<psusi> imo, that was bullshit.. ext4 should make the journal commit for the rename dependant on the flush of the original file to maintain proper atomic replace semantics
<psusi> but even without the fsync on the new data file, dpkg still has multiple syncs per package
<psusi> just for the status file
<cjwatson> the status file is important :)
<YokoZar1> psusi: I remember slangasek mentioning that either the dpkg or apt maintainer wouldn't accept any Ubuntu-originated patch of any kind, I can't remember which one.
<cjwatson> YokoZar1: nonsense
<cjwatson> there's some of that elsewhere but it's not in dpkg or apt.
<YokoZar1> *by that I mean "ubuntu-committed before filed upstream"
<YokoZar1> I think
<cjwatson> I know who you mean but he maintains neither dpkg nor apt and never has.
<penguin42> it strikes me the problem is a lack of API for dpkg or anything else to state the ordering requirements it actually needs, and so is left with a rather blunt weapon of fsync
<psusi> dpkg should have the brains to unpack multiple new packages to temp files, update the status file with *multiple* updates, then fsycn it once, then do the atomic renames all in one batch
<psusi> that is to say, if the filesystem is too brain damaged to just make the rename journal commit depend on flushing the new file
<YokoZar1> cjwatson: ? I'm not saying slangasek maintains those packages, rather that I think he was making a statement about the maintainer of them
<cjwatson> YokoZar1: And you've misattributed it.  He quite probably made that statement because Joey has said such a thing, but it was not about the maintainer of either dpkg or apt.
<YokoZar1> ahh ok
<YokoZar1> I don't actually know the people involved, to my detriment
<cjwatson> There have been many, many Ubuntu-originated patches in both dpkg and apt, many of which have been in Ubuntu first.
<psusi> penguin42, that has been the general concensus... but nobody has put forward such an api... and it seems to me that the big thing dpkg needs, aside from batching commits to the status file, is for atomic renames to work properly, which means ext4 needs to make the journal commit depend on flushing the new temp file, which ttyso doesn't seem to think it should
<YokoZar1> So I wouldn't have to worry about stepping on some political minefield were I to decide to fix this particular problem
<cjwatson> No
<penguin42> psusi: What does Posix say?
<psusi> posix doesn't say anything about journals... it only says that the rename is atomic, so you should either get the old file or the new file
<penguin42> psusi: well there you go, until someone defines an API with a stronger constraint he's right - but annoying, but right
<psusi> ttyso seems to think that ext4 satisfies this because you do either get the old file or the new file thanks to the journal transaction... the problem is that the new file might be empty because it wasn't flushed first
<psusi> imho, it goes with the "spirit" of the concept that you either the old or new to make sure that you don't get new until after any pending writes to new are themselves flushed
<cjwatson> YokoZar1: but if you're going to do so, you get to read through the several hundred pages' worth of bug reports that have led to the current state first, to avoid reinventing previous mistakes :)
<cjwatson> shouldn't be too hard to track them down through the dpkg changelog
<psusi> the ext4 file thing won't be solved unless ext4 is patched to make the rename transaction depend on flushing the writes to the new file first
<psusi> but dpkg damn well can and should batch up multiple packages into one status file flush
<psusi> instead of flushing the status file twice per package
<cjwatson> Please take this somewhere more appropriate
<cjwatson> You've made your point :)
<cjwatson> I can't say I agree with you but the dpkg developers would be much better people to respond
<cjwatson> So if you want to press this, -> bug report on dpkg in Debian
<psusi> at this point I'm trying to just patch debootstrap to use libeatmydata to bypass the dpkg stupidity, at least for new installs ;)
<psusi> since that is what the dpkg devs suggested last time I brought this up to them
<penguin42> psusi: Yeh that makes a lot of sense; you just don't care about the state of your debootstrap'd world until it's complete
<YokoZar1> cjwatson: I'm more poking at the apt resolver rather than dpkg here.  I dont' think we have a lot of automated test cases for that.
<psusi> yea... if a new install is interrupted, who gives a shit?  it's trash anyhow... ;)
<cjwatson> New installs (at least via d-i) already use --force-unsafe-io, which deals with most of it
<psusi> that only deals with part of it, and actually, I'm pretty sure it DOESN'T do that because I was just adding that switch to it today
<cjwatson> Feel free to look in base-installer for yourself if you don't believe me.  Note that I said via d-i, not specifically debootstrap.
<psusi> specifically, that deals with the part where it now flushes each individual file before the rename due to the ext4 bug
<psusi> still a lot of fsyncs to the status file
<psusi> d-i uses cdebootstrap doesn't it?
<cjwatson> Hell no.
<psusi> oh?
<cjwatson> We're not insane.
<psusi> I read today that cdebootstrap is what d-i uses so I was looking into patching that to use libeatmydata too after making debootstrap do it
<cjwatson> You read wrong.
<cjwatson> cdebootstrap is essentially a playground and its only useful differential feature was obsoleted by debootstrap something like eight years ago
<psusi> so... d-i uses regular deboostrap?
<cjwatson> And it's never been configured properly for Ubuntu as far as I know
<cjwatson> Yes
<cjwatson> I don't expect that to change
<psusi> that explains some things.. I was wondering why I kept getting errors running cdebootstrap
<cjwatson> Given that the d-i team maintains debootstrap
<cjwatson> I mean, base-installer will prefer cdebootstrap if it's available, but it basically never is in the d-i context :)
<psusi> not sure what the error was for sid, but for ubuntu, it was that initramfs-tools uses awk in its preinst, and at the time, mawk has not been configured so the awk -> mawk alternate symlink has not been set up
<cjwatson> So that's basically just so that you can add cdebootstrap-udeb to your image if you're strange
<psusi> debootstrap seems to have a hack to manually create that symlink but cdebootstrap doesn't
<cjwatson> Yes, because debootstrap understands that hacks are needed sometimes
<xnox> psusi: "<psusi> [01:03:13] hrm.. looks like ntfs-3g has ABI upstream ABI breakage" care to elaborate? =)
<xnox> psusi: never mind, found your bug.
<cjwatson> That's not the only place where cdebootstrap is wrong - it has insufficient handling of base-files/base-passwd too, last I checked
<psusi> xnox, see bug #1126547 for details... basically it looks like upstream went from major lib rev 835 to 84, so they aren't doing lib versioning right
<ubottu> bug 1126547 in ntfs-3g (Ubuntu) "ntfs-3g: abi breakage" [High,Triaged] https://launchpad.net/bugs/1126547
<psusi> cjwatson, well, that's good to know that patching debootstrap is sufficient to speed up installs
<cjwatson> Eh, nothing says sonames have to be ordered
<psusi> debian policy re lib versions
<cjwatson> exact citation please
<psusi> there is quite a lot of material I don't happen to remember eactly where it is now, but i know it's the reason that libparted has a -debian0 in its version
<cjwatson> No, that was a special case
<psusi> and I think it was you that tried to explain that one to me
<cjwatson> I introduced that and I know why it was, and it's not the same situation
<cjwatson> It was because of a soname *clash*
<psusi> special case because upstream libparted versioning was broken.. i.e. they didn't maintain ABI comatability for each SONAME
<cjwatson> Well, no, it was more complex than that
<cjwatson> Anyway, it's different
<cjwatson> We don't need to consider it
<cjwatson> There's nothing wrong with upstream deciding to go from 835 to 84, as long as there wasn't previously an 84
<cjwatson> Debian policy only says that the soname must change
<cjwatson> If you think otherwise the burden's on you to provide an exact quote
<psusi> sure there is... libtool specifications... major number means ABI compatability... same major number means backward compatabile
<xnox> and the soname was changed.
 * xnox looks at depends generated.
<cjwatson> libtool specifications aren't policy
<cjwatson> they're one particular implementation that happens to satisfy policy when used correctly
<xnox> (but something  to bash upstreams with, as far as I recall correctly)
<slangasek> libtool specifications are a special sort of madness
<cjwatson> what matters is that the soname changes; anything that is doing any kind of ordering comparisons on sonames other than equality is ipso facto broken
<cjwatson> and I am not aware of any such thing other than in package-local build systems
<psusi> well, I suppose it is theoretically possible to go backwards, but obviously upstream meant for 84 to be a greater but backward compatible to 835
<cjwatson> Generally upstream ntfs-3g changes its soname basically every release, and reverse-dependencies need to be rebuilt
<cjwatson> I don't think it's at all obvious that they intended backward compatibility at the binary level; in fact I think it's just false
<psusi> ohh... hrm... so let me see... ok.. so the major/SONAME has changed it looks like... so why does the package satisfy the dependancy of testdisk?
<cjwatson> Now, ntfs-3g used to have a libntfs-3g-blah package
<cjwatson>   * Removing libntfs-3g library package and folding it into ntfs-3g
<cjwatson>     itself as there's not much point in micro-packaging here (nobody
<cjwatson>     except ntfs-3g uses the shlib anyway, upstream bumps soname with
<cjwatson>     almost every release and going through NEW is annoying).
<cjwatson> ntfs-3g 1:2011.4.12AR.3-2
<cjwatson> So I think the claim there is essentially that the reverse-dependencies are broken
<cjwatson> This has absolutely zero to do with upstream ABI handling
<psusi> ok, so it *is* a packaging error in ntfs3g?
<cjwatson> Either it's an argument to be had with the Debian maintainer of ntfs-3g to reintroduce the separate library package for the benefit of testdisk, or testdisk needs to stop using what is currently being treated as a private library
<psusi> I could have sworn I read somewhere that this is basically upstream being stupid and debian has to deal with it by carefully packaging it with a -debianX version in its SONAME to make sure that packages depending on it don't think that they can be satisified with a new upstream release
<xnox> or .shlibs should be much tighter to generate tigher reverse-depends
<cjwatson> psusi: No, entirely wrong.
<psusi> what you said seems to be the same thing that I did in different words? ;)
<cjwatson> -debianX SONAMEs are for extremely specialised and fraught cases and are very much not a good idea if you can possibly avoid it.
<cjwatson> I didn't say at all the same thing as you.
<slangasek> well, it's at least an ntfs3g bug for providing a .shlibs if the intent is that the library be internal
<cjwatson> And note that libparted does *not* have a debianX SONAME
<cjwatson> So that's not a valid example
<slangasek> shlibs is a declaration that "if you link against this library, you should use this dependency"
<slangasek> this is incompatible with "if you link against this library, go jump in a lake of molten lava"
<cjwatson> slangasek: Yeah, that much is an ntfs-3g bug one way or the other
<cjwatson> It could be improved slightly by making the shlibs have tight versioning, as a compromise
<cjwatson> I don't know that it's what I'd do, but it would at least have caused this to be caught by proposed-migratio
<cjwatson> n
<psusi> right, so ntfs-3g should have a .shlibs so that testdisk can link to the proper version, even if that means it needs to change with every new ntfs-3g release
 * xnox wants to use dh_makeshlibs -V
<cjwatson> -V isn't quite right; it also needs << next-upstream
<cjwatson> Or something
<cjwatson> Actually, I don't know why ntfs-3g doesn't just use Provides for this
<psusi> though really, ntfs-3g /shouldn't/ be breaking ABI on every release, but if it is going to do that sillyness, the packaging should at least make sure testdisk requires that specific version of testdisk, and not a newer, not backward compatible one
 * xnox building to see what it will generate and weather that will help or not....
<cjwatson> It won't, it'll be >= current-upstream
<cjwatson> Provides: libntfs-3g84; .shlibs => libntfs-3g 84 libntfs-3g84
<cjwatson> Would make this work, perhaps with some extra care to avoid a self-dependency via the new virtual package
<psusi> right... and that should cover it as long as the major number is part of the debian package version, which it seems it used to be, and then they removed it
<cjwatson> And that way it would also avoid Daniel's concern about going through NEW
<xnox> Oh, that's neat.
<cjwatson> It's a bit curious and it doesn't permit coinstallation of different version
<cjwatson> But maybe it's a workable compromise that Debian would take
<cjwatson> Ah, testdisk depends on the old libntfs in Debian
<cjwatson> That's probably why Daniel hasn't noticed the problem
<cjwatson> I changed it to build against ntfs-3g so that we could drop the deprecated libntfs-dev
<cjwatson> I'm pretty sure Daniel wants to kill libntfs with fire, so I can see him being receptive to this plan
<psusi> basically ntfs-3g should ship the libs in a binary package named for example, libntfs-3g-835, and that is what testdisk or other dependencies should depend on, thus it is coinstallable and not backward compatbile from libntfs-3g-40
<cjwatson> I quoted the reason in the changelog why it doesn't; I don't necessarily find it productive to go head-on against a Debian maintainer's convenience-to-self argument when there's another workable possibility available
<psusi> if it really is supposed to be a private library, then it should be statically linked to by ntfs-3g and not provided in /usr/lib shouldn't it?
<cjwatson> It's not ideal for various reasons (well, one, mostly) but it would do well enough given that it doesn't matter desperately if testdisk doesn't work at all points during an upgrade - it doesn't have to behave as if it's Essential
<cjwatson> And I can understand Daniel's wish to not have to deal with frequent NEW processing for a library that changes SONAME a lot
<cjwatson> So offering him something that will improve matters without making things much less convenient for him seems likely to be a good approach at least for the time being
<cjwatson> You are correct from a purist point of view but it isn't vitally critical to be purist here
<Atlantic777> I'm reading ubuntu packaging guide and other wiki pages for beginners in ubuntu development and I'm not sure how (actually) where you do development. I mean, I don't want to ruin my system for everyday work. Do you use virtual machines, chroot or separate physical machines for development?
<Atlantic777> Or it is safe to start playing on my system for everyday work? :)
<psusi> so you are saying there is a way for ntfs-3g to export a shilbs such that testdisk will require == that version of ntfs-3g rather than >=, so that at least if there is temporary breakge that requires rebuilding testdisk, it will show up as a dependancy that can't be resolved, rather than a lib that can't be found at runtime?
 * psusi uses one machine and fixes it on the rare occasion things go tits up
<sarnold> Atlantic777: chroots for building are superb, they help prevent unintented dependencies from creeping in
<cjwatson> psusi: I'm following up to the Debian bug
<sarnold> Atlantic777: and virtual machines for testing are superb, you can roll them back to a known pristine state without much hassle, do what you want, then blow them away again, without any consequences
<cjwatson> And yes - furthermore doing it that way would have kept the new ntfs-3g in raring-proposed out of users' sight until it was resolved
<psusi> cjwatson, wait, you mean because it wouldn't be allowed out of -proposed until the dependency breakage was resolved?
<psusi> hrm... cool.
<cjwatson> Correct
<cjwatson> For the record: the issue with libparted was that upstream switched to libtool's versioning system and thereby reused a SONAME that was used for a few months back in 2000.  In practice I think it is unlikely that that would cause any real problems, and I can certainly see why upstream was entirely unbothered by the possibility (if they even realised).
<cjwatson> However, because that SONAME had been around ages ago, some of parted's binary packages had a historical Conflicts: libparted0 lying around
<cjwatson> And it turned out to be extremely difficult to deal with that in a way that didn't cause upgrade problems: https://bugs.launchpad.net/ubuntu/+source/parted/+bug/535368
<ubottu> Ubuntu bug 535368 in parted (Ubuntu Lucid) "old Conflicts cause libparted0 upgrade problems" [High,Fix released]
<cjwatson> So I renamed the binary package from libparted0 to libparted0debian1, WITHOUT changing the upstream SONAME which would have been a dangerously incorrect thing to do, purely in order to resolve the upgrade problem
<cjwatson> (There's still a libparted0 dummy package for convenience, but it doesn't interact with upgrades any more)
<cjwatson> If there hadn't been Conflicts against libparted0 still lying around, it really wouldn't have mattered a jot that upstream decided to go from 2.1 to 0
<psusi> cjwatson, so I'm glad cdebootstrap isn't actually used by the installer, because it means it just requires libeatmydata to be MIR, which I filed a bug for and got approval of today, and a two line patch to debootstrap to make use of it.. but... that just covers part of the install doesn't it?  it d-i uses debootstrap to install required, and important packages, but then invokes dpkg to install the standard seed separately right?
<cjwatson> Sure
<cjwatson> In lots of different places which I'm not at all wild about patching independently
<psusi> so somewhere in d-i it needs to set up the LD_PRELOAD for libeatmydata for all of those dpkg invocations... hrm...
<cjwatson> Yeah, that's not happening.  Get a --force-foo option in dpkg for it instead
<psusi> ohh?  why?  I tried that two years ago and it was rejected
<cjwatson> That way it can be set in dpkg.cfg
<psusi> the dpkg maintainers didn't like the idea of another --force option that could be set in dpkg.cfg
<cjwatson> And this d-i maintainer doesn't like the idea of patching dozens of dpkg calls separately
<psusi> should be sufficient to just make sure the LD_PRELOAD environment variable is set in whatever process invokes dpkg... or somewhere up the hierarchy
<cjwatson> There are many and they are not in a strict hierarchy
<cjwatson> It's not practical in d-i AFAICS
<psusi> whatever the highest process is then ;)
<psusi> should be inherited by all children without harm
<cjwatson> That would be actively harmful because of chroots
<cjwatson> So no, please trust me that I have some clue what I'm talking about here ...
<psusi> eh?
<cjwatson> The highest process is operating in the installer environment where libeatmydata wouldn't exist
<psusi> that's fine... then no harm
<cjwatson> And in any case the highest process is a generic menu process which has absolutely no business knowing about this
<cjwatson> So no
<psusi> listing a non existing library in LD_PRELOAD doesn't seem to cause any harm
<psusi> it's just silently ignored
<cjwatson> I'm not complicating main-menu for this
<cjwatson> It's simply the wrong place
<psusi> that's why wrapping debootstrap in eatmydata wasn't enoguh, because it runs dpkg in a chroot and in the chroot, it didn't have the lib, so it was ignored
<psusi> one of the problems they mentioned on dpkg-devel with adding it as a --force option is that it would only affect dpkg, not any of the scripts it calls... so they said it should just be added to the caller of dpkg... and rather than patch every dpkg call, it seems easy enough to just add it to one place, high up in the call tree
<cjwatson> It's not easy.
<psusi> why?
<cjwatson> I give up.
<cjwatson> Sorry, don't have the energy for this.
<psusi> it's just setting an environment variable that all children will inherit... if the installing environment doesn't have the lib, it just gets ignored
<cjwatson> It is necessary to learn how d-i is laid out before proposing modifications to it
<cjwatson> It does not have the structure you seem to think it has
<cjwatson> The only possible place I can think of for this would be in-target (and friends)
<psusi> afaiui, the structure is that there are a bunch of scripts that run in the installer, and eventually chroot into /target and run dpkg... at that point is where you want the LD_PRELOAD set.. but if it is also set in the calling environment, it will just be ignored
<cjwatson> In debian-installer-utils
<cjwatson> It's still pretty delicate though; that doesn't use debconf and probably can't without breaking hand-rolled preseed scripts, so some alternate means of configuring it would need to be devised
<psusi> configuring it?
<cjwatson> You need a much better understanding than "a bunch of scripts" - it has a fairly clear architecture and there's documentation on it and everything
<cjwatson> Configuring in-target to use eatmydata where appropriate
<psusi> I'd love to read documentation on it, but what's the harm in setting the variable as high as you can unconditionally, and letting it trickle down to where it matters?
<cjwatson> It's not going in main-menu, end of story
<psusi> why?
<cjwatson> But it's possible that it could go in in-target, which would probably cover most of the requirements
<cjwatson> There'll probably still be some things that chroot manually
<cjwatson> But a distinct minority
<psusi> chroot into /target you mean?
<cjwatson> Yes
<psusi> and?
<cjwatson> Since in-target is what deals with such things as debconf passthrough and lots of stuff ends up caring about that
<cjwatson> So in practice the big bulk package installations happen via in-target
<psusi> you think there may be other cases that chroot into /target that should NOT use libeatmydata?
<cjwatson> I don't think it matters
<cjwatson> I mention it merely for completeness
<cjwatson> Now I wish I hadn't
<cjwatson> Because I don't deal very well with a full congressional grilling at 3am I'm afraid
<psusi> lol... I'm just trying to figure out where having libeatmydata set in the environment would be UNdesirable
<cjwatson> It would probably be OK in in-target and that would deal with enough of your cases that I'm confident you wouldn't care about the odd leftover
<psusi> I"m sure it would too.. I'm not not sure why you object to setting in in the environment in a broader sense
<cjwatson> I object to putting anything at all in a small and simple program like main-menu that doesn't absolutely have to be there
<cjwatson> This doesn't absolutely have to be there
<sarnold> psusi: could you set it _before_ calling main-menu?
<psusi> I suppose it doesn't, it just seems a hell of a lot easier to set an environment varible one time, there, rather than every time in-target is called
<cjwatson> Er, no - in-target is a script
<cjwatson> I'm suggesting you put the variable setting in that one script
<psusi> hrm... ok
<psusi> for that matter, I was wondering... are the packages copied from the cd to /target first, then chroot into /target to run dpkg to install them?  it looks like that may be the case and that seems wasteful
<psusi> rather than just running dpkg with --root=/target from the install cd
<cjwatson> We use the apt cdrom method
<cjwatson> Which AFAIK doesn't bother copying
<jamespage> !regression-alert
<ubottu> cjwatson, jdong, pitti, skaet, ScottK, kees, Daviey, pgraner: reporting regression in a stable release update; investigate severity, start an incident report, perhaps have the package blacklisted from the archive
<jamespage> bug 1125611
<ubottu> bug 1125611 in openvswitch (Ubuntu) "Upgrade to 1.4.0-1ubuntu1.4 breaks brcompat support" [Critical,Confirmed] https://launchpad.net/bugs/1125611
<jamespage> SRU for openvswitch for 3.5 kernel in 12.04.2 breaks brcompat module for 3.2 kernel
<jamespage> confirmed; looking into fix now
<jamespage> brcompat: module license 'unspecified' taints kernel.
<Malsasa> Hello, how to package .run in Ubuntu?
<JanC> Malsasa: maybe #ubuntu-packaging is a better place to ask that (but if by .run you mean an install script, that's probably not the best source to make a package from if there is another choice)
<Malsasa> JanC: ooooh, i dont know there is a channel named packaging :) Thank you....
<bdrung> doko__: i used lintian to verify that the warning are gone. "using debhelper 9 to pass hardening flags" might be more descriptive.
 * tumbleweed wonders why our nvidia packages now Provide fglrx
<infinity> tumbleweed: Overexhuberant copy and paste between Replaces, Conflicts, and Provides, I'd guess.
<tumbleweed> we also have an nvidia-current transitional binary package, which is fairly useless when all the nvidia-XXX packages conflict with it
<tumbleweed> or is it still useful to help apt with upgrades?
<infinity> tumbleweed: Yeah, I haven't looked into how it all works (or doesn't).  Feel free to tackle tseliot at some point and refine his packaging, though.
<tumbleweed> heh. the breakage of the cuda stack because of incompatibilites between Debian & Ubuntu's approach to nvidia drivers has annoyed me for a while, but it seems that we are still on divergent paths
<ejat> bug 1127404
<ubottu> bug 1127404 in qtmultimedia-opensource-src (Ubuntu) "conflict between libqt5multimediaquick5 and libqt5multimediaquick-p5" [Undecided,New] https://launchpad.net/bugs/1127404
<ejat> can someone help me on that ..
<slangasek> ejat: only one of these packages is in Ubuntu.  Whatever your libqt5multimediaquick5 package is, you'll want to remove it by hand from your system.
<ejat> slangasek: ok thanks .. there is discussion about this on #ubuntu-phone .. they notice the issues ..
<pavolzetor> hi guys, how do I know that notification is being displayed?
<pavolzetor> so I do
<pavolzetor> not = Notify.Notification.new('test', '', '')
<pavolzetor> not.show()
<pavolzetor> and I need to know if notification is sitll on screen (so program will not show next one)
<pavolzetor> does it emit some sginal that it was hidden from screen?
<pavolzetor> is there any way to get default timeout or something like this?
<xnox> folks on #ubuntu-app-devel or #ubuntu-unity might now the api better. As far as I understand there is no way to query if it's on the screen or off the screen. as it could be queued behind other notifications
<xnox> and a user can be fading it in and out by hovering over it, and thus preventing it from timing out
<xnox> pavolzetor: better question is why do you need to know if it's displayed or not?
<xnox> and what are you trying to achieve
<pavolzetor> xnox: I am updating my feed reader
<pavolzetor> so when new articles arrives
<pavolzetor> model updated -> notification object listens and display notification
<pavolzetor> but it can update many times
<pavolzetor> but I want to show only one notification for 100 items
<xnox> one can set the ID on the notification (or something like that) and if you push a new notification with the same ID it will either update the existing bubble, or create/show a new one.
<pavolzetor> ahh, cool ;)
<xnox> thus fire all 100 items and users will get a popup with grown numbers of "28 new items"
<pavolzetor> I will do that
<xnox> pavolzetor: check the API docs.
<pavolzetor> but when does the notification disappears
<pavolzetor> ?
<xnox> "after some time"
<pavolzetor> I mean if it disappears, you might want start from 0
<xnox> fire notifications every time you have new items.
<pavolzetor> I do not want to show count there (it will be on badge), okay
<xnox> you will be rate limitted if it's too much, and generate the new ID for each batch.
<pavolzetor> I see
<pavolzetor> okay, thanks ;)
<xnox> e.g start poll -> generate notification id -> push out notifications -> stop
<pavolzetor> start poll?
<xnox> (start whatever you do to walk all the feeds and get new articles thingy....)
<pavolzetor> "0
<pavolzetor> :)
<pavolzetor> cheers
<pavolzetor> also
<pavolzetor> one thing
<pavolzetor> why does not badge show up ?
<xnox> pavolzetor: check with #ubuntu-unity or #ubuntu-app-devel
<pavolzetor> okay ;)
 * xnox never coded against notification api, btw =)
<pavolzetor> me neither ;)
<pavolzetor> I got it, but I rewrote it using MVC
<pavolzetor> and fixed a lot things
<xnox> and also this channel is not fully appopriate to discuss these things. Folks here are mostly devel ubuntu core operating system.
<pavolzetor> and now I am splitting code to classes
<xnox> refactoring is always good
<pavolzetor> http://bazaar.launchpad.net/~floaty-devs/floaty/trunk/revision/92
<pavolzetor> this commit
<pavolzetor> Ahh I see
<pavolzetor> will go to correct room ;)
<xnox> #ubuntu-app-devel is for developing on/for/against ubuntu
<pavolzetor> what I miss are some guidelines and help with gnome stack development, like that my MVC, I am not sure if I did it right way
<pavolzetor> cool
<pavolzetor> thanks for your time
#ubuntu-devel 2013-02-17
<Malsasa> Hello, lintian says: missing-dep-on-jarwrapper when checking my debian.deb from my JAR. How can I fix this?
<Malsasa> Hello all, how can I make my DEB package installable in system and appear in menu? Is there any tutorial?
<Elbrus> Malsasa: you need to create a *.desktop file and install that
<Malsasa> Elbrus: wow, thank you... i think nobody in this channel. I planned to borrow from existing DEBs official from repo so it will be okay :D
<Elbrus> sure
<Malsasa> Elbrus: thank you for support...
<ogra_> cd ..
<GuidoPallemans> I did an "export QML_IMPORT_PATH=$PWD/modules" in a folder to get the latest QML ubuntu components, but now I can't use any ubuntu components anymore?
<GuidoPallemans> http://paste.ubuntu.com/1671263/
<GRex> I need some help here guys...am trying to install ubuntu 12.10 on my Acer One zg5. I created usb installer, checked the iso and everything else but still the installation stucks at the syslinux 4.06 EDD
<GRex> Anyone?
<GRex> I need some help here guys...am trying to install ubuntu 12.10 on my Acer One zg5. I created usb installer, checked the iso and everything else but still the installation stucks at the syslinux 4.06 EDD
<GRex> Nobody there?
<GRex> I need some help here guys...am trying to install ubuntu 12.10 on my Acer One zg5. I created usb installer, checked the iso and everything else but still the installation stucks at the syslinux 4.06 EDD
<auntie> I think you want #ubuntu man
<auntie> this is the dev channel
<GRex> Oh..I thought developers knew better so asked. Sorry.
<auntie> no worries
#ubuntu-devel 2014-02-10
<hyperair> Laney: what's the process for DD's to get PPU access to ubuntu again? just email you a list of packages i'm maintaining?
<hyperair> aha found it: https://wiki.ubuntu.com/DeveloperMembershipBoard/ApplicationProcess
<Noskcaj> hyperair, tip: Don't apply be email, and i think the 19UTC meeting has a waiting list
<hyperair> huh?
<hyperair> Noskcaj: any reason why?
<Noskcaj> Because applying by email takes a month or more
<hyperair> Â¬_Â¬ really?
<Snow-Man> there's a waiting list?  hahahaha
<Noskcaj> Whereas applying by irc take 1 hour max
<hyperair> i'll wait for Laney to say something then.
<hyperair> 19UTC today?
<Noskcaj> It's later this month the 19utc meeting
<hyperair> i see
<hyperair> bleh 19utc is 3am here
<Noskcaj> oh, then you'll want the 15utc meeting
<hyperair> if i'm not asleep by then chances are i don't wake up on time then ext morning.
<hyperair> ah 15utc
<hyperair> when are the meetings anywya?
<hyperair> ah every two weeks on monday eh
<hyperair> hang on there's a 15UTC meeting today right?
<pitti> bdmurray: that's because there currently is no code to try and install versions other than what apt would give you as default
<pitti> Noskcaj: whoa, all-caps ping
<pitti> Good morning
<Noskcaj> pitti, debian just finished the libgphoto transition, but they chose a different -dev package name to you. We might need to do a second transition
<pitti> Noskcaj: right; libgphoto2-dev is indeed saner, but I didn't want to change the naming schema in Ubuntu only
<pitti> Noskcaj: shouldn't be a big deal, it's just adjusting < 10 build deps of packages; that can be done very quickly
<pitti> Noskcaj: ah, were you looking at merging libgphoto2?
<Noskcaj> yeah
<pitti> Noskcaj: if you are, I can do the transition for the build dep renaming
<Noskcaj> I'm trying to get the pkg-phototools stuff in a decent state.
<Noskcaj> I can do all the work, just will need sponsoring
<pitti> we used to be able to sync libgphoto2, perhaps we can even do that again
<pitti> Noskcaj: nah, don't try to do the libgphoto2-6-dev â libgphoto2-dev transition
<Noskcaj> ok
<pitti> that's like zero brain work, just mechanical; without upload privs, sponsoring is more work than just doing it
<Noskcaj> makes sense
<pitti> ooh, Debian has a .hwdb file now?
<pitti> *want*
<pitti> Noskcaj: hopefully the only remaining change is dh-autoreconf (and that can be reported to Debian)
<Noskcaj> looks like just the autoreconf
<Noskcaj> Could you test if we do actually need the autoreconf?
<pitti> Noskcaj: and it's missing the "Replaces: libgphoto2-2" on libgphoto2-6
<Noskcaj> ok
<pitti> it reintroduces libgphoto2-2-dev, that should just be dropped again for our merge, too
<pitti> meh, and debian missed to update some 2-2 to 2-6 in various *.isntall
<pitti> Noskcaj: looks like you actually need to walk through the whole debian/ubuntu diff; there are several fixes that ought to be done to Debian's package, too, so that will spit out some bug reports
<pitti> Noskcaj: autoreconf isn't necessary, debian already has --with autotools_dev
<pitti> Noskcaj: I mean, that delta can be dropped
 * Noskcaj decides to try and fix everything in debian instead
<pitti> *nod*
<pitti> Noskcaj: also, Debian still installs the *.udev file, that ought to go
<pitti> having *both* a .rules and a .hwdb is just unnecessary overhead
<Noskcaj> How do i merge git branches? The debian uploader did his work in a separate branch
<hyperair> git merge
<pitti> sohudl just be "git checkout master; git merge <branch name>"
<pitti> or even pull, for cleaner history
<hyperair> afaik there's no difference between git fetch+merge and git pull
<hyperair> unless you're talking about pull -r
<hyperair> which is equivalent to rebase
<pitti> maybe; so far I never merged in git
<pitti> the git world is pretty deeply entrenched to the concept of "send git-formatted patches to MLs or bug reports"  workflow, at least in the gnome and plumbing world
<hyperair> pitti: yeah, but in the github world it's deeply entrenched in "send me a pull request"
<pitti> *nod*
 * hyperair prefers the git-formatted patches approach though, for individual fixes
<hyperair> for stuff that involves a non-linear history, then i upload somewhere and tell whoever to pull
<pitti> yes, it works quite well for those "little contributions"
<pitti> for developing a major new feature, branches work better though
<hyperair> well, yes
<hyperair> it really depends on the kind of contribution we're talking about
<hyperair> imo it's more about the kind of commits that it generates that determines which approach is better rather than the kind of work you're doing.
<Noskcaj> crap, alioth git is still broken
<Noskcaj> pitti, If you have the time, please do the merge into ubuntu. It will be quite some time before this get's fully fixed in debian, and you actually understand the current changes
<pitti> ok
<Noskcaj> ty
<dholbach> good morning
<pitti> Noskcaj: libgphoto2 built, I sent the two remaining changes to Debian as bugs; I just uploaded all rebuilds/syncs
<Noskcaj> pitti, thanks.
<directhex> are there restrictions on who can post to ubuntu-devel-announce?
<pitti> directhex: not from the sending side; but it's moderated
<Laney> hyperair: don't listen to the trolling, DD-PPU is super quick if you already have some PPU, which you do
<hyperair> Laney: i figured that might be the case. i've already sent the email.
<darkxst> Laney, can you bump the codesearch server?
<Laney> argh
<Laney> that piece of ...
<mpt> ev, bdmurray: Any idea what caused the big dip in reported Trusty errors from January 10th to 28th?
<mpt> Or what caused the lack of data from January 30th to February 3rd?
<Laney> darkxst: there we go
<darkxst> Laney, thanks
<shadeslayer> would it be possible to enable deb-src's in the Buildd's?
<RAOF> shadeslayer: What do you want deb-srcs for on the buildds?
<shadeslayer> RAOF: I have a meta package that should depend on the build depends of another package
<shadeslayer> RAOF: http://paste.ubuntu.com/6908474/
<rbasak> shadeslayer: I can't answer your question, but you might want to know about grep-dctrl(1) if you don't already.
<rbasak> (for line 11)
<shadeslayer> rbasak: how would that help ? I want to get the build depends of kdelibs in the source of meta-kde
<rbasak> shadeslayer: just to parse apt-cache showsrc output a little more "correctly".
<shadeslayer> oh
<seb128> apachelogger, " libkubuntu0 - ((DESCRIPTION))" ... need better description ;-)
<rbasak> shadeslayer: instead of the grep|cut thing you have which I could subvert with an imaginative package :-)
<apachelogger> seb128: huh, lol
<apachelogger> seb128: sounds descriptive enough to me :P
 * apachelogger fixes
<seb128> lol
<seb128> thanks
<seb128> I wonder who NEW reviewed it, could have spotted that :p
<seb128> Riddell, ^?
<Riddell> seb128: hmm, yes, my fail, I normally run .debs through lesspipe as well as lintian but I seem to have only done lintian for these ones :(
<shadeslayer> rbasak: thanks for the tip :)
<shadeslayer> RAOF: so any chance of getting deb-src enabled?
<Mirv> could a core dev possibly ack the following libunity packaging change dropping libgee usage, so that cu2d could be used to publish the package (after finalizing testing on Ubuntu Touch too): http://pastebin.ubuntu.com/6908355/
<apachelogger> Riddell, seb128: fixed
<seb128> apachelogger, thanks
<seb128> Mirv, +1
<Mirv> thank you
<xnox> cjwatson: in the new world order, which branch of click i should target? (as in which one has 0.4.15?)
<cjwatson> xnox: just target lp:click, I should get round to pulling the trivial bump of 0.4.15
<cjwatson> xnox: but feature branches should always target lp:click, and then the other branch is for landing
<xnox> cjwatson: ack, thanks.
<davmor2> tseliot: Morning.  Got hit by bug #1277014 this morning.  I did an apt-get update && apt-get dist-upgrade and everything is working again now.  I'm wondering if it might be that there is something racy there as I was hit by it yesterday when I used it a lot
<ubottu> Error: Launchpad bug 1277014 could not be found
<Chipaca> since the last update, ctrl+space is popping up a keyboard layout switch thingie
<Chipaca> as an emacs user, this is a huge problem :(
<tseliot> davmor2: that doesn't seem to be a valid bug number
<Chipaca> the keyboard layout switcher key was set to super-space, i changed it to ctrl-alt-space just in case, to no avail
<davmor2> tseliot: ah it's private
<tseliot> davmor2: can you subscribe me, please?
<davmor2> tseliot: made it public bug #1277014
<ubottu> bug 1277014 in xorg-server (Ubuntu) "Xorg assert failure: X: ../../dix/dispatch.c:3920: DetachUnboundGPU: Assertion `slave->isGPU' failed." [Medium,Confirmed] https://launchpad.net/bugs/1277014
<seb128> Chipaca, change it in ibus-setup I guess?
<Chipaca> augh
<Chipaca> seb128: indeed, it says ctrl-space there
<Chipaca> seb128: thanks
<seb128> Chipaca, yw
<Chipaca> seb128: are you aware of a bug about this?
<seb128> Chipaca, does changing it resolve the issue?
<Chipaca> seb128: I mean: should changing this (in ibus-setup) do the same as changing whatever the indicator thingie changes?
<seb128> no, I don't know how a bug about that
<seb128> happyaron, ^
<seb128> Chipaca, that was discussed in the past, I'm still unsure what the differences between both are
<seb128> imho the ibus one should be unset by default
<seb128> but I want happyaron to confirm, since he maintains ibus
<Chipaca> also, ctrl-space offering two layouts when i only have one configured is quite surprising
<seb128> what are the 2 ones?
<tseliot> davmor2: ok, thanks, I'll investigate the issue
<Chipaca> seb128: one is "English (US)". The other is "English (interna...". I believe the second one is the one I have configured, which starts with the same string.
<seb128> Chipaca, I think US is added to the list as a fallback, it should probably not be displayed in the switcher though
<Chipaca> also the indicator calling the bar where it's shown it the "menu bar" is not nice
<davmor2> tseliot: I turned on the laptop about 4-5 times yesterday for various bits no issues, this morning turn it on and I was dropped to low gfx mode (which doesn't seem to work at all, by the way) dist-upgrade and now I'm back to a working system :) I Don't think there was anything GFX wise installed I'll double check though
 * Chipaca stops moaning and gets back to work
<mpt> Chipaca, why? Thatâs what itâs called.
<Chipaca> mpt: wait, that bar is called the 'menu bar'?
<shadeslayer> RAOF: still waiting for an answer
<Chipaca> that bar, where a bunch of stuff is always present, and menus are only sometimes present, is called the 'menu bar'?
<shadeslayer> seb128: ping
<seb128> shadeslayer, hey
<shadeslayer> seb128: any idea who maintains apturl? You were the last person to touch it
<seb128> shadeslayer, not sure it's actively maintained, why?
<seb128> shadeslayer, but mvo is the closest from a maintainer for it
<tseliot> davmor2: ok
<shadeslayer> seb128: well because apparently it doesn't work on any of the flavors or ubuntu for that matter
<mpt> Chipaca, except for maximized window buttons, that stuff is all menus. Compare the Power panel of System Settings, and the Clock tab of the Time & Date panel.
<seb128> shadeslayer, do you have a patch?
<shadeslayer> seb128: sort of https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1261178/comments/1
<ubottu> Launchpad bug 1261178 in firefox (Ubuntu) "apturl links stopped working after firefox 16" [Undecided,Triaged]
<shadeslayer> seb128: that sorts it out on Ubuntu and Xubuntu at the very least
<shadeslayer> but not on Kubuntu
<Chipaca> mpt: the indicators are considered menus?
<seb128> shadeslayer, that bug is about firefox, not apturl
<mpt> Chipaca, that was the whole point of introducing them in the first place.
<shadeslayer> seb128: it most certainly is since apturl.js is provided by apturl
<shadeslayer> apturl-common: /etc/firefox/pref/apturl.js
<davmor2> tseliot: no x-org but there was a kernel+headers etc update so that may of had an effect
<seb128> shadeslayer, running e.g
<seb128> $ apturl-gtk apt:samba
<seb128> works fine for me
<shadeslayer> seb128: changed affected package to apturl
<shadeslayer> seb128: sure, but try : apt://samba in firefox
<Chipaca> mpt: the point of indicators was not to call them menus, i'm sure
<seb128> shadeslayer, "sure", you just said that apturl didn't work
<seb128> shadeslayer, do you have an example of website using an apt url?
<mpt> Chipaca, http://design.canonical.com/2010/04/notification-area/
<shadeslayer> okay, maybe I worded it poorly, but the bug is clearly in apturl since it does not symlink the file
<shadeslayer> seb128: apps.ubuntu.com ? :)
<seb128> shadeslayer, ok, I understand what you mean now, but it's not "apturl doesn't work at all", it's "apturl integration is buggy"
<Chipaca> mpt: well i'll be
<shadeslayer> seb128: yeah, to be more verbsoe, apturl integration with firefox is buggy
<shadeslayer> http://www.getdeb.net/software/xVideoServiceThief
<shadeslayer> so get deb uses apturl too ^^
<Chipaca> mpt: i would've never, ever thought we called those things menus
<Chipaca> mpt: i shall use the correct name from here on then
<mpt> :)
<seb128> chrisccoulson, hey, could you have a look to https://bugs.launchpad.net/ubuntu/+source/apturl/+bug/1261178 ? is that a firefox issue?
<ubottu> Launchpad bug 1261178 in apturl (Ubuntu) "apturl links stopped working after firefox 16" [Undecided,Triaged]
<seb128> chrisccoulson, reading https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1169320/comments/2 ... should /usr/lib/firefox/defaults/pref be used indeed?
<ubottu> Launchpad bug 1169320 in firefox (Ubuntu) "Firefox 21 no more apply global default preferences from dir" [Undecided,Invalid]
<seb128> shadeslayer, I'm going to get it fixed, thanks for pointing the issue
<chrisccoulson> seb128, yes, it's a firefox issue
<chrisccoulson> adding a preference override is definitely not the correct fix though
<seb128> chrisccoulson, should apturl just install that file in /usr/lib/firefox/defaults/pref ? that seems to make things work
<chrisccoulson> seb128, no, that's wrong. nobody should be installing any files in there
<seb128> chrisccoulson, ok, what's the correct fix then? ;-)
<chrisccoulson> the URI handling in firefox needs fixing
<seb128> shrug
<seb128> that sounds like something non trivial :/
<seb128> chrisccoulson, can I just do the wrong thing and install the file in that dir nobody should be using until that happens? ;-)
<chrisccoulson> seb128, no, please don't do that ;)
<seb128> chrisccoulson, can you fix the url handling then? ;-)
<chrisccoulson> it needs somebody who understands the code in http://hg.mozilla.org/mozilla-central/file/d8d8fa98ee7d/uriloader/exthandler ;)
<seb128> chrisccoulson, if you say so, I'm unsure why we needed that apturl.js at all, I assumed it was because that's not a standard handler
<apachelogger> can anyone explain what the output regarding kubuntu-full means http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt please? or more to the point, why it is not considered for upgrade
<cjwatson> apachelogger: it means that the arm64 kubuntu-full package would be uninstallable if promoted; proposed-migration won't increase the global uninstallable count
<cjwatson>  kubuntu-full : Depends: calligra but it is not going to be installed
<cjwatson>                 Depends: kdeedu but it is not going to be installed
<cjwatson>                 Depends: kdenetwork but it is not going to be installed
<cjwatson> that's the cause
<cjwatson> we could hack those out of the seeds for arm64, but I'd rather see them all built since that's simpler all round
<cjwatson> the current blocker is https://launchpad.net/ubuntu/+source/opengtl/0.9.18-0ubuntu1/+build/5378634, since arm64 never had llvm-3.3; it might be worth attempting to bump that to llvm-3.4
<Riddell> cjwatson: where do you read those lines you pasted?
<cjwatson> I ran "chdist apt-get trusty-proposed-arm64 install kubuntu-full" in a suitable chdist instance
<Riddell> hmm, chdist sounds like something I should get to know
<cjwatson> It's very handy
<cjwatson> You obviously have to not let it actually try to install anything since it very much won't work
 * rbasak uses a wrapper he calls hcdist which fixes chdist's braindead parameter ordering
<Maulkin> cjwatson: I'm also lurking in here in case people have questions
 * cjwatson nods
<apachelogger> cjwatson: uh, thank you
<Maulkin> cjwatson: you have mail for moderation.
<pitti> Maulkin: ah, the valve games? moderating
<Maulkin> pitti: yup
<Maulkin> Thanks :)
<pitti> nice!
<Maulkin> pitti: Enjoy!
<pitti> so after DoSing the Debian community, the Ubuntu community will be game-DoSed next :0
 * pitti repairs his smiley -- âº
<Maulkin> Pretty much, and there's another one we're looking at too, but working out how to deal with the requests is more tricky. Apparently GPG isn't universal yet!
<cjwatson> pitti: ah, you're too quick for me
<xnox> Maulkin: well, launchpad account must have an email address setup, check launchpad account membership in e.g. ~ubuntu-members (or whatever the restriction is) and mail the activation keys via launchpad contact that user...
<directhex> time to cower in fear of my inbox?
<xnox> Maulkin: most of above is available over API I believe.
<Maulkin> directhex: ack
<xnox> Maulkin: uploading ~ubuntu-members have gpg key attached to their launchpad-id, so can verify that signed requests for a given id matches the key for that id on launchpad.
<xnox> Maulkin: and launchpad does do gpg-signed challenge to add the gpg key to the account.
<directhex> xnox, cjwatson helped me extract all valid keys from LP
<xnox> (gpg-encrypted challenge that is)
<xnox> directhex: i hope they aren't a lot of duplicates =)
<directhex> Maulkin, which ML did that go on?
<Maulkin> directhex: ubuntu-devel-announce
<maswan> directhex: Ok, I'll slack yet another week before dusting off my very dusty gpg key then. :)
<cjwatson> xnox: I used the correct approach, which is to follow ArchivePermission records attached to the primary archive
<xnox> cjwatson: interesting, i see =)
<mterry> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Trusty Tahr Alpha 2 released! | Archive: open | 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: mterry
<mlankhorst> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Trusty Tahr Alpha 2 released! | Archive: open | 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: mlankhorst, mterry
<tseliot> davmor2: I think the problem lies in X, but we'll see...
<davmor2> tseliot: right.
<Riddell> can anyone give me the output of this on ppc64el and arm64? dpkg-architecture -qDEB_HOST_GNU_CPU
<xnox> Riddell: dpkg-architecture -qDEB_HOST_GNU_CPU -aarm64
<xnox> Riddell: dpkg-architecture -qDEB_HOST_GNU_CPU -appc64el
<xnox> =)
<Riddell> xnox: you're a genius
<xnox> Riddell: nah, dpkg just hardcodes _all_ values for any arch =)
<tseliot> davmor2: was the system set to use intel or nvidia when the system crashed?
<davmor2> tseliot: let me double check for you
<davmor2> tseliot: intel for me
<tseliot> davmor2: ok, that's probably good news. Thanks
<davmor2> tseliot: no worries
<rbasak> Conflicting packages can be concurrently be in a removed-but-not-purged state, right?
<cjwatson> Yes
<rbasak> Thanks
<rbasak> So mysql-server-5.5 owns /var/lib/mysql, and conflicts with mysql-server-5.6 (say), which does the same, and they conflict. What's the expected behaviour on package purge? Should /var/lib/mysql, which contains the relevant database itself, be purged? Currently, there's some really ugly code in this area.
<rbasak> There's a debconf option to say what should happen, but also code to try and not do the purge if a different mysql-server-* is installed, since otherwise it would destroy the wrong data.
<rbasak> The whole arrangement seems wrong to me, but I'm not sure of the correct solution.
<arges> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Trusty Tahr Alpha 2 released! | Archive: open | 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: mterry, arges, mlankhorst
 * dholbach hugs arges, mterry and mlankhorst
<arges> lots of patch pilot love today
<Laney> feel the lurve
<mterry> arges, mlankhorst: btw, I was doing a run of syncs.  When I'm done I'll start on merge requests unless ya'll have started any
<mterry> Didn't realize I had so much company today  :)
<Laney> don't forget to prod the harder things along ;-)
<Laney> (re: conversation in #-meeting atm)
<arges> mterry: i'm working on kexec-tools atrm
<mlankhorst> mterry: well hard for me since I'm not core-dev O:-)
<mterry> arges, cool
<Laney> no! you can help by reviewing and then communicating your findings to your fellow pilots so that they can upload
<mterry> mlankhorst, yar if you reviewed a request in main that would make my job easier, I could just push a button then :)
<Laney> patch piloting != uploading
<Laney> if I drew a venn diagram there would be an overlap but one wouldn't be contained in the other
<xnox> Laney: venn diagram for above: https://fbcdn-sphotos-d-a.akamaihd.net/hphotos-ak-prn2/t1/1920184_10153960264685727_501779264_n.jpg
<mterry> :)
<Laney> :D
<mlankhorst> o.O
<bdmurray> pitti: so then if a retracer config has -updates available the package version from -updates will be chosen regardless of whether or not the crashing system was using it, correct?
<mlankhorst> @pilout out
<udevbot> Error: "pilout" is not a valid command.
<mlankhorst> ugh, have to run!
<mlankhorst> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Trusty Tahr Alpha 2 released! | Archive: open | 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: arges, mterry
<pitti> bdmurray: right
<bdmurray> pitti: do you think it would be much work to change that?
<pitti> bdmurray: a few hours probably
 * mterry works on makecoredump merge
<mterry> makedumpfile that is
 * mterry works on sshfs-fuse
<ari-tczew> o/
<ari-tczew> mterry: the change is forwarded to Debian
<mterry> ari-tczew, oh good, I was about to look
<mterry> ah, they accepted already
<mterry> sync in the future, yay!  :)
<ari-tczew> ;)
 * mterry looks at zabbix, another Artur production
<Laney> cjwatson: could you please moderate my u-d-a mail?
<Laney> mterry: ari-tczew can now upload himself ;-)
<caribou> mterry: thanks for makedumpfile; I got a bunch of uploads on duplicity if you fell like it ;-)
<mterry> caribou, oh right!
<mterry> caribou, yeah I should probably do those for ya
<mterry> Laney, oh?  good news!
<cjwatson> Laney: done
<Laney> cheers
<ari-tczew> Laney: not for main, unfortunately
<Laney> ah
<Laney> yeah, keep on getting sponsored there
<mterry> ari-tczew, well, you can bug 1277268 off my hands then!  :)
<ubottu> bug 1277268 in zabbix (Ubuntu) "Merge zabbix 1:2.2.1+dfsg-1 (universe) from Debian unstable" [Undecided,Confirmed] https://launchpad.net/bugs/1277268
<mterry> *take
<ari-tczew> mterry: sure
<mterry> ari-tczew, congrats and welcome btw!  :)
 * ari-tczew is out of battery
<mterry> humph
<xnox> Laney: lol, i should be elected straight out of the bat then ;-)
 * arges looks at sudo merge
<ogra_> arges, again ?!?
<ogra_> feels like there are weekly merges now :)
<arges> ogra_: i just looked at the grab-merge page and it was there
<arges> but yea i see your point
<ClientAlive> I would like to apply the patch given for bug 1161594 : https://bugs.launchpad.net/ubuntu/+source/gdevilspie/+bug/1161594?comments=all   but I am not comfortable enough with the process and don't feel the instruction given in post #9 : https://bugs.launchpad.net/ubuntu/+source/gdevilspie/+bug/1161594/comments/9   is adequate for me. Would someone be so kind as to clarify the instructions given in post #9, make sure nothing is missing,
<ubottu> Launchpad bug 1161594 in gdevilspie (Ubuntu) "Gdevilspie fails to start with no attribute 'xdg_config_home'" [High,Triaged]
<ClientAlive> and walk me through the process for me, my first time doing something like this ?
<arges> ClientAlive: so this is a bug in trusty?
<ClientAlive> arges: I'm running Saucy
<ClientAlive> It is a bug for me
<arges> ClientAlive: ok so you know its a bug in saucy. So generally we first need to see if its a bug in the development release before we do whats called an SRU to stable releases
<arges> from the look of it both trusty/saucy are the same version
<ClientAlive> arges: I kinda need this app ( in fact, I was hoping to use it today ). Is there anything I can do?
<ClientAlive> ok
<arges> ClientAlive: so to get the package properly fixed it takes time. The SRU process can't happen immediately since it needs to go through testing and verification
<arges> ClientAlive: it looks like somebody posted a test package that you could try to verify on your own system, and in the meantime we work on getting it fixed properly
<arges> ClientAlive: are you the author of this fix?
<ClientAlive> arges: No I am not. While I am studying to be a web developer/sortware developer, I'm far from knowing how to do something like that.
<arges> ClientAlive: ok let me take a look
<ClientAlive> arges: When you say test package, are you referring to post #10 ? Is that what that .deb is?
<ClientAlive> ok
<ClientAlive> thank you
<arges> ClientAlive: yea a .deb is a debian package. This is what ubuntu/debian use to package and install software
<arges> ClientAlive: so you could download that package and type 'dpkg -i <name of package>' in a terminal, or double click on the .deb file. You should be careful to ensure you trust the package you are installed
<arges> installing
<ClientAlive> arges: Ok, cool. May I ask, should I first remove the gdevilspie I installed through software center? And, if so, what is the best way to do that? My concern is mainly to do with whether I need to remove both devilspie and gdevilspie or if just removing gdevilspie would be sufficiant. Also, Would it be better to do a apt-get purge --autoremove   or something other?
<ClientAlive> Thanks
<arges> ClientAlive: should be able to just install it without removing since it should be built against the same version
<ClientAlive> arges: Thanks
 * mterry looks at dropbear merge
<ClientAlive> arges: Appeas to be working just fine now. Your a life saver  :)
<jtaylor> doko: so how would be bootstrap pandas/statsmodels on arm64?
<ClientAlive> Guess I spoke too soon. Yes, gdevilspie does launch with that .deb installed, and yes the setting to autolaunch the daemon does stay set. However, after closing and restarting the application, it claims the daemon is not running ( even though the option remains ticked ). I don't know if the massage is accurate or not ( that the daemon is not running ) but that's a pretty crucial patrt of gdevilspie.
<ClientAlive> Just thought I'd share. fwiw anyhow.
<arges> ClientAlive: please add that feedback to the bug. Thanks!
<ClientAlive> arges: Will do
<mterry> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Trusty Tahr Alpha 2 released! | Archive: open | 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: arges
<doko> jtaylor, I can have a look. but honestly I don't care that much if the few tests are disabled
<jtaylor> doko: k I'll upload pandas witohout the cycle
<jtaylor> just test built it
<jtaylor> fun 3MB large debian.tar.gz ._.
<jtaylor> btw does someone want to get me a backtrace of the numpy segfault on ppc64?
<sarnold> pitti: hello, I think the trusty retracers are unhappy again: https://bugs.launchpad.net/bugs/1278071 needs to be retraced still
<ubottu> Error: malone bug 1278071 not found
<sarnold> what's this 'malone' that the goofy bot keeps referring to? :)
<slangasek> malone is the bugs component of launchpad; largely obsolete nomenclature
<sarnold> ah :) thanks
<g0twig> hey there
<g0twig> I did read this
<g0twig> https://lists.ubuntu.com/archives/ubuntu-devel-announce/2014-February/001079.html
<g0twig> did anyone of you take this offer?
<g0twig> I dont know if I am allowed to accept this offer, well I am Ubuntu Member
<g0twig> does this mean I am an "Ubuntu Developer"?
<g0twig> I made code contributions to Ubuntu, to gain this status
<slangasek> g0twig: that would be a question for Neil (on behalf of Valve); it states "Ubuntu Developers", which would mean members of the ~ubuntu-dev team in Launchpad
<slangasek> but I don't know if that's the intent
<g0twig> well, than I am not allowed :X
<g0twig> I was into Unity stuff
<dobey> slangasek, g0twig: you must have upload rights to some package in the archive to get the offer
<slangasek> dobey: ok, so the wording is deliberate and it's tied to Ubuntu Developer rights, not Ubuntu Membership - thanks for confirming
<dobey> slangasek: right. also, see http://apebox.org/wordpress/linux/595/
<dobey> some people were confused about DD vs. contributor and such there
<xnox> barry: if you are around, what's the progress on bilingual emulators? are those in the archive yet? or can i somehow test them with my phablet-test-run branch?
<barry> xnox: not in the archive yet.  i'm working with the autopilot guys to get on the train, but i think it's more like america and less like germany in that there are delays along the line ;)
<xnox> barry: lol =) well there are 10 merge proposals inflight to land, and i guess autopilot re-exec will make the next round of landing.
<barry> xnox: that's what we're working toward ;)
<xnox> barry: i think i'll ask sergiusens to land phablet-tools branch, after testing it doesn't regress current test-results. Such that when autopilot lands it all just works together =)
<xnox> barry: or we will just have impedance mis-match fixes to get everything onto python3.
<barry> xnox: that sounds like a plan
<xnox> barry: cool =)
<spineau> mterry: Hello, I have a new package in the checkbox dependency collection requiring a mir review: checkbox-ng. If you have time today could you please have a look at bug 1277408?
<ubottu> bug 1277408 in checkbox-ng (Ubuntu) "[MIR] checkbox-ng" [Undecided,New] https://launchpad.net/bugs/1277408
<mterry> spineau, literally looking at it now!  :)
<spineau> mterry: fantastic, thanks
<g0twig> dobey: I am so sad
<dobey> g0twig: go get to work and become a dev then
<g0twig> dobey: I am not into packaging
<g0twig> I am not a fan of those package principles
<g0twig> I am a coder
<g0twig> I think deb and rpm are outdated concepts
<arges> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Trusty Tahr Alpha 2 released! | Archive: open | 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:
<sergiusens> xnox, barry we can put autopilot and phablet-tools in the same atomic train push
<thomi> sergiusens: we're in the mniddle of landing a new AP today
<sergiusens> thomi, that's a different landing though
<thomi> different to what?
<sergiusens> read backlog ;-)
<xnox> thomi: next one =) autopilot re-exec branch.
<thomi> right, but that branch isn't ready yet, AFAIK
<xnox> sergiusens: well, phablet-tools can go ahead, as it does a dynamic check if /usr/bin/autopilot on device is new one or old one.
<xnox> sergiusens: so, my changes shouldn't regress any existing tests with current autopilot & python2. And it should stay compatible, when autopilot-reexec lands.
<sergiusens> xnox, want it in now then?
<sergiusens> xnox, I want to wait for balloons to give me the list of ap py3 ready click tests though
<xnox> sergiusens: well, having it in the ppa would be nice.
<xnox> sergiusens: i don't think there are any py3 ap tests, since no emulators are python3 compatible in the archive.
<xnox> sergiusens: so no clicks should declare autopilot_dir and last time I've checked none of them do.
<xnox> sergiusens: did you already revert that? or did i not find those that declare that in the archive already / on the images?
<RAOF> shadeslayer: Oh, sorry. I don't have any ability to enable deb-src on the buildds. I was just trying to extract reasoning so that someone who *does* could determine whether or not it's compelling.
<sergiusens> xnox, I need to revert two
<sergiusens> xnox, oh sweet, none have been actually released :-)
<ari-tczew> who are the admins of 'Ubuntu Members' ?
<ari-tczew> I'd like to set @ubuntu.com alias etc.
<StevenK> ari-tczew: https://launchpad.net/~ubuntumembers
<xnox> sergiusens: excellent, if they haven't been released they'd need to adapt if phablet-tools lands first.
<xnox> sergiusens: can i get new phablet tools into a silo, such that i can do final testing and push it into the archive?
<shadeslayer> RAOF: know anyone who could help me with that?
<RAOF> shadeslayer: I'd probably poke the almighty cjwatson. That said, there's seems to be a roughly equally easy solution for you that doesn't require deb-src on the buildd - generating debian/control before upload.
<RAOF> As far as I can tell the only thing that wouldn't get you is on-LP binary rebuilds. But we don't have them either :)
<sergiusens> xnox, sure; but give me a chance to review as well
<tkamppeter> jasoncwarner, hi
<cjwatson> shadeslayer,RAOF: I think I would prefer not having to make a change to Launchpad to add deb-src to every build for the sake of a single package where there's a reasonable alternative ...
<shadeslayer> cjwatson: ack
<cjwatson> It *probably* wouldn't be harmful, but it would slow every build down a bit, don't know whether it's worth it
<cjwatson> Is deb-src enabled in Debian buildds?
<cjwatson> Hmm, https://buildd.debian.org/status/fetch.php?pkg=grub2&arch=amd64&ver=2.02~beta2-6&stamp=1390961236 suggests it is
<cjwatson> Maybe it's worth doing just for the sake of alignment then?
<cjwatson> shadeslayer: Basically I'm vacillating. :-)  I suggest filing a Launchpad bug, as Launchpad's what feeds the sources.list to each build
<shadeslayer> cjwatson: haha, okay :)
<cjwatson> I'm surprised this is the first time (AFAIK) in the eight years or so since we switched to LP for builds that it's come up
<xnox> cjwatson: i used chdist in android build, to get deb-src lines. But i wouldn't want to slow down _all_ builders because of that.
<xnox> (and thus apt-get source)
<cjwatson> I was going to mention a performance penalty, but I suspect it's negligible
<cjwatson> chdist would work, or other similar approaches with user-level apt configurations, though it's a bit roundabout
<xnox> cjwatson: if it does incur in performance penalty, we have quite networking problems =) given that src are smaller than binary packages indexes.
<cjwatson> Quite
<shadeslayer> cjwatson: I'll file one tomorrow morning
<cjwatson> OK, ta
 * shadeslayer heads to bed, night \o
<xnox> shadeslayer: what's the package in question? and are you sure you must use deb-src on the buildds?
<cjwatson> Alignment with Debian's buildds carries a lot of weight with me.  Generally we win a few more things we don't have to mess about with to get them to build every time we fix some aspect of our builds to be more in line with Debian.
<cjwatson> And at the very least it means people have fewer things to think about.
<xnox> cjwatson: i wonder if deb-src lines enabled, is a pre-requisite for a proper build-using: * stanzas support.
<xnox> unless i understand build-using:* wrong.
<cjwatson> xnox: I don't think so; you can get enough information for that from binary control fields
<cjwatson> The usual Source: if present, else Package: dance
#ubuntu-devel 2014-02-11
<ClientAlive> Is there anywhere on my local computer or the internet to get information about window properties? Properties is probably not the right word, but what I need to find out is what the global identifiers are for things like an active window, an inactive window, a maximised window, a minimised window, and so on. Any info can give would be appreciated.
<sarnold> ClientAlive: investigate xwininfo
<ClientAlive> sarnold: thx. will do
<sarnold> ClientAlive: oh! also xprop
<ClientAlive> sarnold: Oh, that's coool...  :>
<sbeattie> there's also xlsclients
<sbeattie> (but xprop's attempt at ansi-text'fying an app's icon is pretty cute)
<ClientAlive> sbeattie: no kidding
<ClientAlive> Hey, I'm screwing around with devilspie and all/every window is opaque so it is hard to work/read. I want this, but I also need to make the active window ( whichever one happens to be active at the time ) to be solid/not opaque. To solve the immediate problem, what condition could Itest agains in order to select the active window?
<ClientAlive> I sure sure would appreciate it.
<ClientAlive> Then I can move along on my own
<ClientAlive> sbeattie: ? sarnold: ?
<ClientAlive> Problem is, I don't see that particular information with xwininfo or xprop
<sarnold> ClientAlive: no idea, sorry
<ClientAlive> k
<sarnold> ClientAlive: if devilspie lets you find e.g. _NET_WM_STATE_FOCUSED in _NET_WM_STATE you might be able to match on that
<sarnold> but I've never tried devilspie before
<ClientAlive> sarnold: It's a start. thx
<ClientAlive> It's test conditions seem to correspond to things like : class; xid; role; property; name; workspace   not sure what category _NET_WM_STATE would fall under ( ir any ).
<pitti> Good morning
<pitti> l
<pitti> sarnold: right, the amd64 one crashed; restarted
<mmazing> i'm looking to learn more about how the dbus system works, can anyone recommend a book/website that can help out? there doesn't seem to be much out there, im trying to break down the datetime-indicator-service but it's a bit complicated and i'm just recently jumping back into C development
<pitti> stgraber: can I somehow convince lxc to put ephemeral overlays on /tmp/ (or another tmpfs)? putting them on the real HD makes things rather slow (aside from the HD wearout/fragmentation)
<mmazing> answered my own question i think : package libdbusmenu-gtk-doc
<mmazing> maybe not :\
<pitti> mmazing: if you want to learn about the general D-BUS concepts, http://dbus.freedesktop.org/doc/dbus-tutorial.html is the place to start
<mmazing> thanks pitti
<sarnold> pitti: good morning :) thanks!
<RAOF> pitti: How would you feel about having umockdev_load_from_file/string/etc return an array of udev sysfs paths rather than a boolean?
<pitti> RAOF: well, it's not a "rather than", as the array of paths needs to become a new (out) argument; so the success flag should still stay
<pitti> RAOF: feels API-breaky to me, but if it's particularly helpful for some use case we can certainly do it
<pitti> it's not yet that widely used
<RAOF> I'm not entirely sure if that's what I want, either.
<pitti> RAOF: thanks for your pull requests, looking at them now
<pitti> RAOF: btw, if you add NEWS entries they can be merged fully automatically
<RAOF> pitti: Ah, let me do so then.
<pitti> RAOF: I can add them during the merge this time, no worries (although github supports push -f just fine)
<RAOF> I should probably make testbed_remove send "remove" uevents, too, for symmetry.
<pitti> RAOF: I merged the DEVNAME one, and put a qestion on the uevent one
<RAOF> Sure, I can add a test.
<pitti> or, probably, change an existing one to ensure that the uevent is received
<pitti> RAOF: so, for the "return sysfs paths" thing, what's your use case for that?
<pitti> RAOF: usually you know which devices in your dump you want to work with, and if you load an unknown dump my feeling is that you usually want to use the libudev enumeration/filtering functions to find what you are looking for?
<RAOF> I think what I want to do is ship foo.umockdev and foo.ioctl, and have a load_stuff("foo") call that loads them in, etc.
<RAOF> I was thinking of the return sysfspath thing so that I could trigger uevents, but it's better to just get umockdev to trigger those events.
<pitti> ah
<pitti> yes, that's much easier then
<pitti> mlankhorst: hey, how are you?
<pitti> mlankhorst: can you please upload the various xserver-*-lts-{quantal,raring,saucy,trusty} metapackages to trusty soon which move people back to the normal trusty stack?
<pitti> mlankhorst: upgrades are still broken (e. g. https://jenkins.qa.ubuntu.com/view/Trusty/view/All/job/upgrade-ubuntu-precise-trusty-desktop-lts-quantal-i386/11/artifact/results/bootstrap.log)
<pitti> mlankhorst: I filed bug 1278737 about that and tentatively assigned it to you, IIRC you work on the enablement stacks? If not, please re-assign to someone more appropriate
<ubottu> bug 1278737 in xorg (Ubuntu Trusty) "Upgrade to trusty fails from precise backported enablement stacks" [High,New] https://launchpad.net/bugs/1278737
<pitti> jibel: ^ FYI (for tracking)
<spineau> Good morning, I need someone to process a sync request for checkbox please: bug 1278747
<ubottu> bug 1278747 in Ubuntu "Sync plainbox-provider-checkbox 0.3-2 (universe) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/1278747
<dholbach> good morning
<spineau> dholbach: Good morning, may I ask you to process a sync request (for checkbox)?
<spineau> it's bug 1278747
<ubottu> bug 1278747 in Ubuntu "Sync plainbox-provider-checkbox 0.3-2 (universe) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/1278747
<dholbach> hi spineau
<dholbach> spineau, I'll take a look at it in a bit
<spineau> dholbach: thanks a lot
<mlankhorst> pitti: yeah ok :P
<pitti> mlankhorst: good morning; thanks!
<Laney> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Trusty Tahr Alpha 2 released! | Archive: open | 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: Laney
<mlankhorst> pitti: if you want to test, just a second
<darkxst> Laney, Hi
<Laney> hiya
<darkxst> since you piloting can you take a look at gcc vanilla MP?
<Laney> where?
<darkxst> Laney, ubuntu-desktop branch
<darkxst> lp:~darkxst/gnome-control-center/vanilla
<Laney> dude
<Laney> using gcc like that is confusing
<Laney> but if it is what it sounds like then I might punt to robert_ancell :-)
<mlankhorst> pitti: can you add a ppa for testing?
<pitti> mlankhorst: yes, when doing it manually
<mlankhorst> hold on a sec, I should be able to upload oldxorg shortly
<infinity> Laney: On man, I absolutely thought he meant GNU Compiler Collection.
<infinity> darkxst: g-c-c, not GCC, if you want to avoid heart attacks.
<Laney> infinity: No need to worry, I'd have blindly sponsored it anyway. :)
<infinity> Laney: You desktop people scare me.
<Laney> "YOU AREN'T A CORE-DEV?" DEBSIGN DPUT
<pitti> "it starts with g*, must be desktop"
<mlankhorst> pitti: I copied the oldxorg pkg to ppa:canonical-x/x-staging
<seb128> pitti, it's why the kernel is a kubuntu thing, right? ;-)
<pitti> seb128: yeah; and you already lost one of your pets when glibc got renamed to eglibc..
<infinity> seb128: No, we cleverly made the source package start with 'l' to avoid that.
<Laney> edubuntu claimed that one
<pitti> seb128: besides, lubuntu (it's linux, not kernel)
<infinity> Also, we have too many flavours.  Somene seems to be able to claim every letter.
<seb128> pitti, infinity: oh, right ;-)
<rbasak> Time to invent more letters. Unicode FTW.
 * infinity renames glibc to â­libg.
<Laney> Î¼buntu
 * pitti registers ÆÉ¹oËnÊunqn
<seb128> å¯uè¬ä½ ä»å»
<pitti> mlankhorst: thanks! I'll wait until it's built and published and then test
<mlankhorst> it almost finished building empty files. :P
<infinity> I really wanted to that be code-of-conduct violating.  Google Translate let me down.
<mlankhorst> oops.. needs multi-arch: same..
<infinity> Also, Google's "did you mean?" sugestions for Chinese are hilariously awful.
<pitti> mlankhorst: err, does it? they are arch:all, aren't they?
<infinity> "Did you mean: å¯uçä½ ä»å»"
<infinity> "U disk you can go to him"
<pitti> looks exactly the same to me
<infinity> Thanks, Google.  That's exactly what I meant.
<mlankhorst> pitti: hm no it should be arch: amd64 i386
<mlankhorst> because we don't want to break upgrading libgl-mesa etc
<mlankhorst> or end up with a 32-bits xserver on amd64! :D
<tvoss> pitti, https://code.launchpad.net/~thomas-voss/process-cpp/add_death_observer_for_child_processes/+merge/204629
<mlankhorst> pitti: ok pushed, can you check if it works? also can you check if /usr/lib/xorg/protocol.txt exists after upgrading?
<pitti> mlankhorst: yes, as soon as it gets published
<pitti> mlankhorst: are the other packages in that PPA "safe" for an upgrade test?
<mlankhorst> they won't explode or anything
<mlankhorst> they were from the original xorg 1.15 test rebuild, left in because version is still newer, so someone can ppa-purge them :p
<pitti> mlankhorst: will still take a bit; I killed the test machine during the test dist-upgrade :/
<pitti> on heavy I/O with containers wazn sometimes just dies
<mlankhorst> !!
<pitti> mlankhorst: (not your fault at all, just keeping you posted why you don't get a response from me)
<apachelogger> pitti: bug 1278820 might be intersting, or at the very least it seems a bit odd ^^
<ubottu> bug 1278820 in ubuntu-drivers-common (Ubuntu) "system not detected as needing nvidia" [Undecided,New] https://launchpad.net/bugs/1278820
<pitti> DEBUG:root:X.org log reports loaded intel driver, disabling driver nvidia-173 for hybrid system
<pitti> apachelogger: that's deliberate ATM, I'm afraid
<apachelogger> ok
<pitti> at least when we wrote that check, we couldn't use the intel and nvidia drivers in parallel
<pitti> so you'd have to disable the intel card in the bios if you want to use the nvidia one
<apachelogger> pitti: seems to work right now though
<apachelogger> or at least the nvidia module is loaded and GL lists nvidia as vendor
<pitti> apachelogger: you manually installed the nvidia driver?
<pitti> apachelogger: yes, that'll kill the intel driver as well, and shoudl then display it
<apachelogger> pitti: maybe, the system was upgraded from saucy, so I might have manually installed it back then
<apachelogger> oh
<apachelogger> pitti: jockey lists the drivers, so since we used jockey in saucy still I guess I used that to install it
<pitti> apachelogger: hm, we had a similar check in jockey
<apachelogger> pitti: http://i.imgur.com/1S7h2oh.png
<pitti> apachelogger: apparently that's when you already have one installed, so your X.org isn't using intel any more, right?
<apachelogger> pitti: yeah, xorg.0.log is attached to the bug
<tseliot> apachelogger, pitti: that will be fixed in trusty soon
<pitti> tseliot: oh, nice! how will that work, does the nvidia driver use the mesa libGL now?
<tseliot> pitti: I'm working on a program that will deal with the different GPUs and take care of the required changes (in this specific case, it will tell X to use the nvidia card if nvidia is installed). This program will run on boot and also detect any hardware changes, for example when users add a new card or swap an nvidia card with an amd card, etc.
<tseliot> this will replace the hybrid-detect program in ubuntu-drivers-common
<tseliot> the new program is still written in C
<apachelogger> neat
<pitti> mlankhorst: hm, it seems that our trusty linux-meta already builds metapackages for linux*-lts-saucy, but not for quantal/raring/trusty, and not for xorg*
<mlankhorst> pitti: yeah linux does their own thing :)
<pitti> mlankhorst: so should linux-meta also build those for quantal, raring, and trusty?
<mlankhorst> ask the kernel team
<mlankhorst> I can't predict the future so I don't handle lts-trusty yet in my packaging
<pitti> apw: so linux-meta builds transitional packages for -lts-saucy; it should also build them for lts-{quantal,raring}, and presumably for lts-trusty as well (as we already know we are going to do it, right?)
<pitti> apw: want a bug for that?
<pitti> apw: err, wait; they are built, but apt-cache search lts-raring spectacularly fails to find them
<pitti> apw: so nevermind, sorry for the noise
<pitti> apt-cache search lts-saucy works just fine, curiously
<apw> pitti, yeah i am pretty sure we have about 100 transitional packages :)  perhaps they are in different sections from each other or something
<pitti> mlankhorst: followed up to bug 1278737
<ubottu> bug 1278737 in xorg (Ubuntu Trusty) "Upgrade to trusty fails from precise backported enablement stacks" [High,In progress] https://launchpad.net/bugs/1278737
<mlankhorst> yeah
<mlankhorst> pitti: oh right, libxatracker1 -> libxatracker2
<mardy> cjwatson: hi! When you have some time, can you tell me if the approach is right? https://code.launchpad.net/~mardy/click/lp1245826/+merge/204674
<mardy> cjwatson: once you confirm it's OK, I'll fix the documentation
<cjwatson> mardy: I think it's OK, yes, although FWIW I find it easier to decide whether I like the approach given the documentation :-)
<cjwatson> mardy: (I usually write documentation for this kind of thing before I write the code)
<cjwatson> mardy: Sorry, I've been buried in 12.04.4 and then a complex series of customer bugs for the last couple of weeks
<mlankhorst> I could swear you said you wouldn't do another release after 12.04.2 iirc ;)
<mardy> cjwatson: OK, then I will :-)
<cjwatson> mlankhorst: Yeah, I think I got voluntold
<cjwatson> 12.04.2 was awful
<mlankhorst> 12.04.5 is going to be bad too, need to backport dri3 support ;)
<mlankhorst> I think you should practice saying '123 NOT ME' faster this time.
<xnox> mlankhorst: cjwatson: should things generally depend directly on libgl1-mesa-dri or should it be expected to be handled as a hardware specific thing and something should pull the right one in (either seed or ubuntu-drivers-common)?
<xnox> mlankhorst: cjwatson: i see that qtdeclarative5-qtquick2-plugin and libgbm1 depend on libgl1-mesa-dri and thus end up pulling nvidia & radion dri onto ubuntu-touch seeds which seems pointless, as hybris is used.
<mlankhorst> depend on libgl1-mesa-dri  | libgl1
<mlankhorst> and include libhybris first so libgl1-mesa-dri doesn't end up being installed
<xnox> mlankhorst: excellent! let me see if i can make this work.
<pitti> mlankhorst: oh, you mean libxatracker1-lts-saucy actually ought to move people to libxatracker2, not to libxatracker1?
<mlankhorst> yeah or do nothing, but i moved it to 2
<tseliot> davmor2: mlankhorst fixed your problem in xorg-server (2:1.15.0-1ubuntu4). Let us know if you're still able to reproduce the problem with the new update
<tseliot> davmor2: you shouldn't be ;)
<davmor2> tseliot: thanks I'll grab the update and do a few reboot tests latter then
<tseliot> thanks
<mlankhorst> should be impossible really
<tseliot> too bad, using intel as a source and a sink at the same time was fun :P
<cjwatson> mlankhorst: I should be able to at least avoid doing two in a row
<mlankhorst> or should you?!
<Laney> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Trusty Tahr Alpha 2 released! | Archive: open | 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:
<mlankhorst> pitti: ah right, libglamor-ltss0 conflicts with libglamor0
<mlankhorst> incorrectly, but still, I guess I'll need to transition that too
<diwic> hmm, what happened to the right mouse button in trusty? Button positions seem to have recently switched
<tjaalton> clickpad?
<diwic> tjaalton, no, a five button USB mouse
<tjaalton> i have a 10+ button mouse and it seems to work like before :)
<soren> tjaalton: 10+ button mouse?
<tjaalton> ok, 11
<diwic> tjaalton, okay...I wonder what happened to this one then?
<soren> tjaalton: pics or it didn't happen.
<tjaalton> soren: if you count the scroll wheel as three
<tjaalton> logitech mx revolution
<diwic> tjaalton, ok, mine is seven buttons if you count the scroll wheel as three
<soren> tjaalton: That's crazy.
<tjaalton> mine has a "wheel" for thumb too
<soren> I don't even have a mouse.
<tjaalton> hehe
<diwic> tjaalton, so what used to be the "popup menu" button now seems to do "open in new tab" in nautilus
<diwic> tjaalton, and the popup menu button is now what used to be back button in firefox
<tjaalton> diwic: what does xev show
<diwic> hmm, and the forward button in firefox is now the back button
<tjaalton> or xinput test-xi2
<tjaalton> diwic: maybe try an earlier kernel to be sure
<tjaalton> the mappings/quirks are there
<diwic> tjaalton, hmm, both the scroll wheel button and the second button is now numbered 2
<diwic> tjaalton, I bet that's not the case on 12.04
<tjaalton> what isn't?
<diwic> tjaalton, booting a 3.12 kernel has the same results, so I think it's somewhere else in the stack
<tjaalton> you don't have any special xorg.conf then?
<diwic> tjaalton, if I press the buttons in order, I end up with: 1, 2, 2, 3, 8.
<diwic> tjaalton, whereas in 12.04 I end up with: 1, 2, 3, 8, 9
<diwic> tjaalton, not that I'm aware of, where should I look for one?
<diwic> there's no /etc/X11/xorg.conf
<tjaalton> ok
<tjaalton> so you haven't used any release in between?
<tjaalton> try the guest session too
<diwic> xmodmap -pp shows "13 buttons" and a straight mapping.
<diwic> I booted my laptop with saucy, it works fine there.
<tjaalton> k
<diwic> tjaalton, guest session on trusty desktop = buggy
<tjaalton> what mouse is it btw?
<doko> jamespage, https://bugs.launchpad.net/ubuntu/+source/dovecot/+bug/1278897
<ubottu> Launchpad bug 1278897 in dovecot (Ubuntu) "dovecot warns about moved ssl certs on upgrade" [Undecided,New]
<diwic> tjaalton, Evoluent Verticalmouse 3
<jamespage> doko, ta
<tjaalton> diwic: ah, well a quick google shows it has needed special mappings..
<tjaalton> so dunno
<diwic> tjaalton, !! it is in 10-quirks.conf
<diwic> tjaalton, that is just...stupid. I liked it the way it was. Can I override it?
<diwic> tjaalton, without changing a system file that will be overwritten on upgrade?
<spineau> mterry: hello, I promise this is the last mir bug for checkbox, this one is very similar to the other plainbox provider package, just code relocation: bug 1278822
<ubottu> bug 1278822 in plainbox-provider-checkbox (Ubuntu) "[MIR] plainbox-provider-checkbox" [Undecided,New] https://launchpad.net/bugs/1278822
<tjaalton> diwic: yes, put something in /etc/X11/xorg.conf or .d
<mterry> spineau, OK
<diwic> tjaalton, it works, thanks for saving my day! :-) And my fingers
<tjaalton> yw
<tjaalton> didn't know that got added upstream
<jamespage> doko, is that 12.04 ->14.04?
<doko> jamespage, no, that had 11.04 or 11.10
<stgraber> pitti: what are you using? lxc-start-ephemeral or lxc-clone -B overlayfs?
<pitti> stgraber: start-ephemeral
<stgraber> pitti: start-ephemeral should be tmpfs by default
<pitti> stgraber: ah, does the  clone -B one allow that?
<stgraber> pitti: unless you manually pass -k (keep data) or set the storage type to dir instead of tmpfs
<pitti> stgraber: this morning I had a temporary (trusty-jf923blabla) one laying around from a few days ago, and I reboot every day
<pitti> stgraber: and I could still start it, so it was there still
<stgraber> pitti: did it actually contain any data in /var/lib/lxc/<container>/delta0?
<stgraber> pitti: the container definition itself is on disk but the overlay is location (delta0) is a tmpfs by default
<stgraber> (unless you pass -k or --storage-type dir)
<pitti> stgraber: hm, not sure, I removed it already; I'll re-create that situation and investigate
<pitti> stgraber: so /delta0 is the tmpfs mount point?
<pitti> stgraber: i. e. the container started alright, but it was like its pristine template, without the delta?
<stgraber> right
<stgraber> pitti: I just tried here with a new ephemeral container, did some changes and confirmed that none of that is committed to /var/lib/lxc/<container name>/delta0 (which remains empty at all time)
<stgraber> it's just a bit tricky to see as the tmpfs is mounted by an lxc hook and is therefore not visible from either the host nor the container
<pitti> right
<pitti> stgraber: ok, so that was probably it; thanks!
<stgraber> np
<mlankhorst> pitti: I tested lts-saucy, that one should work, multiarch'd too
<jamespage> doko, afaict dovecot's never actually used the snakeoil certs...
<jamespage> bah
<doko> ohh :-/
<bdmurray> doko: I guess doxygen is still using tmake?  I was looking at bug 1196347.
<ubottu> bug 1196347 in tmake (Ubuntu) "[MIR] promote tmake (already included in main in the doxygen sources)" [Undecided,Fix released] https://launchpad.net/bugs/1196347
<bdmurray> doko: you'd mentioned they were moving to qmake
<doko> bdmurray, yes, no change yet
<jamespage> doko, yeah - looks like it generates one instead in 12.04 at least
<pitti> mlankhorst: ah, splendid; btw, could you rename "oldxorg" to perhaps "xorg-lts-transitional" or so?
<tvoss> sil2100, around?
<mlankhorst> pitti: are the other ones tested too
<pitti> mlankhorst: I can do that now
<pitti> mlankhorst: with simulation, but that should be good enough for now
<mlankhorst> simulation is fine
<pitti> mlankhorst: done, and followed up to the bug
<pitti> mlankhorst: so mostly good now, except for that weird geode thing
<seb128> doko, can you get a mp with your gnome-control-center-signon changes up? your direct landing is conflicting with a CI landing that is waiting for some days
<mlankhorst> pitti: geode is i386 only
<pitti> mlankhorst: right, it's just weird that the upgrade says that it's holding it back
<pitti> mlankhorst: those three tests were on amd64, doing i386 now
<seb128> sil2100, doko just uploaded http://launchpadlibrarian.net/165639698/gnome-control-center-signon_0.1.7~%2B14.04.20131126.2-0ubuntu1_0.1.7~%2B14.04.20131126.2-0ubuntu2.diff.gz ... can we overwrite it with the planned landing?
<pitti> mlankhorst: it's like some metapackage now wants to pull in the geode:i386 package for the upgrade
<mlankhorst> odd :/
<doko> sil2100, well, not override, but just merge the patch
<mlankhorst> pitti: well I'm not respecting m-a for all original packages, probably something like that causing it
<doko> seb128, is there any reason to hard-code the list of architectures?
<pitti> mlankhorst: i386 is fine (also just said that in the bug)
<pitti> mlankhorst: many thanks! can you perhaps just rename this, and then get it uploaded? (I can sponsor if you need)
<seb128> doko, I don't remember the details, would need to ask didrocks, the issue happened when that package got ported from qt4 to qt5
<seb128> doko, it stopped being buildable on e.g ppc since qtdeclarative is not available there
<mlankhorst> pitti: you shouldn't install a i386 geode on amd64
<pitti> mlankhorst: well, I didn't
<mlankhorst> hm :p
<pitti> mlankhorst: that's the point -- the upgrade apparenlty tried to install it (through some new dependency), and then holds it back
<mlankhorst> would need a full log
<mlankhorst> to see why it tries to install it
<doko> seb128, sure, it would show up as a dep-wait or a ftbfs, but that would be preferred to limiting the set of archs
<doko> same here: https://bugs.launchpad.net/ubuntu/+source/account-plugins/+bug/1278953
<ubottu> Launchpad bug 1278953 in gnome-control-center-signon (Ubuntu) "package should be built on any arch" [Undecided,New]
<seb128> doko, I don't remember the details, britney didn't like the fact that it built before on those archs and was depwaiting after
<seb128> doko, well, anyway, please submit a mp to the vcs with your changes
<seb128> doko, you just screwed a planned landing by not follow the process
<pitti> mlankhorst: attached (although I can't really see from it what's pulling it in)
<mlankhorst> maybe video-all:i386
<mlankhorst> I'm guessing xserver-xorg*) needs to be m-a foreign
<xnox> seb128: "doko, I don't remember the details, britney didn't like the fact that it built before on those archs and was depwaiting after" when that happens, typically one should ask archive admin to remove binaries of the removed architectures from -release pocket.
<pitti> mlankhorst: but *shrug*, good enough for the first iteration :)
<mlankhorst> pitti: without even looking at the log I'll give that a shot
<xnox> seb128: otherwise to britney it does look like: mipsel binary in -release, no mipsel binary in -proposed. *regression*
<seb128> xnox, right, but those debs had still rdepends, and Colin didn't want to go for brutal deleting
<seb128> xnox, I don't remember the details
<cjwatson> eh wut?
<seb128> that was blocking things
<cjwatson> which packages?
<seb128> cjwatson, http://launchpadlibrarian.net/143379896/gnome-control-center-signon_0.1.7~daily13.06.18-0ubuntu1_0.1.7~%2B13.10.20130625-0ubuntu1.diff.gz
<cjwatson> I'm pretty sure I tore out bits of the signon stack before, bit surprised to hear my name invoked as a blocker ...
<seb128> cjwatson, at the time it did qt4 -> qt5
<seb128> it was a bit of a mess
<seb128> but I don't remember the specifics of the situation
<cjwatson> right, I think that was a change I requested
<seb128> cjwatson, oh, you are not named as a blocker
<seb128> cjwatson, I'm trying to remember why we did that change by then
<cjwatson> doko: I'm pretty sure that limiting the set of arches was necessary there, as otherwise it built binaries that were uninstallable
<seb128> doko was asking why it was made
<cjwatson> doko: the right answer is to leave it alone for now and wait for Qt 5.2
<doko> cjwatson, hmm, ok
<cjwatson> 5.2 will (should?) give us a working qtscript everywhere and then we can stop worrying about this
<cjwatson> and I gather that's pretty close
<cjwatson> I hate explicit architecture lists as much as you do - it was a last resort
<seb128> that's my understanding as well, qt5.2 should resolve those issues
<cjwatson> basically once we have 5.2 I was going to crawl back up the stack and look for hacks that can be undone
<xnox> barry: you could nuke the .py files and only leave python3.3 bytecode =)))))
<xnox> barry: and have a custom pyupdate which uses .py files not from a public location.
<barry> xnox: heh, yeah, probably fails the "easy" test but that's a possibility ;)
<xnox> barry: i guess you can't drop invalid 3.4 bytecode? since python will invalidate it and import .py file instead?
<barry> correct.  if the .py is available but __pycache__ isn't writable, then it will just run off the .py files, and you'll pay the compilation cost everytime
<xnox> barry: why not take your patch and apply it in debian/ubuntu? or does it have side-effects?
<xnox> barry: it's not uncommon for debian/ubuntu to patch support in ahead of upstreams...
<doko> does genshi ship any binaries?
<barry> xnox: which patch do you mean?  the one that prevents import, or the fix to genshi for 3.4?  i don't have the latter (and neither does upstream, it's not trivial)
<doko> are there any rdeps?
<xnox> doko: i think it's mostly used as a library, e.g. django can be made to use genshi templates and thus call into genshi on each request to generate .html.
<xnox> doko: ditto other web-frameworks/webapps of the day.
<xnox> doko: there are no, pyhon3-genshi reverse depends at the moment.
<barry> doko: if you mean executables, no.  there is an optional .so for speedups, but it's only compatible with python2 (there's another unresolved upstream ticket for that)
<xnox> barry: why not simply ship the module into /usr/lib/python3.3 and be done with it?
<doko> xnox, no. would be /usr/lib/python3.3/dist-packages, and we don't have this one yet
<doko> I like the import error much more
<barry> doko: me too. as icky as it may be, it more or less mimics what you'd see if it wasn't installed for 3.4, so probably "good enough"
<xnox> doko: =/ i see, and it doesn't make sense to create one just because of genshi.
<xnox> just like with 2.5, will 3.5 be the release that will act like a barrier?! =)
<mlankhorst> pitti: ok uploading ppa6, can you give it a shot when it finshed?
<mlankhorst> I killed off the m-a same for everything except a few packages
<barry> xnox: huh?
<xnox> barry: a lot of projects struggled to move to 2.5, or choose not to. and later 2.5 projects didn't move to 2.7, at times getting 2.7 support together with 3.0 one.
<xnox> maybe it's just my impression.
<xnox> as in maybe around 3.5 time, genshi like problems will be widespread enough, to warrant /usr/lib/python3.x/dist-packages
<cjwatson> I think chose not to was more common; 2.4 support seemed quite sticky
<xnox> as in maybe around 3.5 time, genshi like problems will be widespread enough, to warrant /usr/lib/python3.x/dist-packages
 * xnox -Efocus-follow-eye-sight
<barry> xnox: genshi's failure is rather unique actually because it depends on the AST, which doesn't have a guaranteed stable API.
<barry> so it probably breaks with every release (that's what you get for depending on a library documented to not be stable ;)
<barry> one of the topics for the language summit in montreal pycon2014 will be the 3.5 release.  a strong possibility is a shorter dev cycle specifically focused on improving porting from python 2, with very limited feature set otherwise
<barry> (something i actually favor, in the abstract ;)
<barry> tedg: hi.  i was wondering if you could comment on LP: #1278582 and LP: #1278511.  they (and especially the former for me) are causing lots of pain for emacs users.  they seem to be recent regressions
<ubottu> Launchpad bug 1278582 in hud (Ubuntu) "Regression: cannot set HUD key binding" [Undecided,New] https://launchpad.net/bugs/1278582
<ubottu> Launchpad bug 1278511 in unity (Ubuntu) "CTRL-Space no longer works under Unity" [Undecided,Confirmed] https://launchpad.net/bugs/1278511
<tedg> barry, Hmm, seems seb128 just set it to fix committed :-)
<seb128> tedg, barry: yeah, commenting on both
<tedg> barry, In general that's probably a bregma thing though.
<seb128> it's a "we need unity trunk to land in trusty, one day"
<bregma> one day soon
<seb128> tedg, barry: you can access it by running gnome-control-center.real
<seb128> or http://bazaar.launchpad.net/~unity-team/unity/trunk/revision/3643
<barry> seb128: oh wow.  why doesn't .real run when you hit the gear->System Settings? :)
<seb128> barry, you get unity-control-center (our new default UI)
<barry> seb128: ah, and this setting hasn't been added to u-c-c yet?
<seb128> barry, the Unity xml is missing because unity didn't get a landing for ages
<seb128> cf the commit I just pointed
<seb128> it's fixed in trunk
<seb128> but bregma's ass has been kicked by unity autopilot tests recently it seems
<seb128> those guys didn't manage to do a landing for ages
<barry> seb128: awesome, thanks.  i will try .real and wait for the fix-released there
<seb128> yw!
<seb128> barry, the other one should be an ibus issue, please try if unsetting in ibus-setup fixes it
<barry> seb128: yeah, i actually uninstalled ibus ;)
<bregma> we're spending more time fixing bugs in autopilot itself than in unity
<seb128> bregma, :-(
<seb128> bregma, are those regressions in autopilot? can't we just back out the buggy version?
<barry> seb128: however, on LP: #1278582 i don't actually think it's fixed.  .real shows me "Key to show the HUD" as disabled, and yet both Alts still bring up the search dialog.  if in the settings panel, i hit alt-right or super, the key settings just reverts to "diabled".  but i don't think it's actually disabled!  maybe the search dialog is different than "Key to show the HUD"?
<ubottu> Launchpad bug 1271710 in unity (Ubuntu) "duplicate for #1278582 doesn't list compiz/unity keybindings" [Low,Triaged] https://launchpad.net/bugs/1271710
<bregma> 40 new regressions due to #1278917
<barry> bregma: yeah, i am struggling with autopilot failures all over the place :/
<seb128> barry, well, the issue that bug describes "don't list keybindings" is fixed, not sure about the hud key not working as it should...
<barry> seb128: fair enough.  i suppose i should open a new bug on that issue.  would that be on unity then?
<seb128> yes and yes
<barry> seb128: cool, thanks!
<seb128> yw!
<barry> seb128: LP: #1278985  - please let me know if my explanation was unclear or
<ubottu> Launchpad bug 1278985 in Unity "Regression: Alt invocation of search cannot be remapped, causing pain to Emacs users" [Undecided,New] https://launchpad.net/bugs/1278985
<barry> *unclear (no or :)
<seb128> barry, seems clear, I can't confirm/reproduce though
<brendand> barry, is that Alt+ something, or Alt, then something?
<seb128> changing the keybinding works fine for me
<samertm> barry: does that bug only appear in trusty?
<rbasak> doko: for bug 1243076, the conclusion is to drop the package, unless you object? It seems that nobody has ported the code itself to Apache 2.4's new API.
<ubottu> bug 1243076 in mod-auth-mysql (Ubuntu Trusty) "libapache2-mod-auth-mysql is missing in 13.10 amd64" [High,Confirmed] https://launchpad.net/bugs/1243076
<rbasak> (and upstream and Debian are inactive)
 * rbasak doesn't see any rdepends
<barry> brendand: it's all muscle memory, but it seems to be roughly "press alt then quickly press f next' (of course, not just f - any key will do)
<barry> brendand: although if i'm *really* careful i can press them both at the same time, and the same behavior is exhibited
<barry> samertm: a very recent dist-upgrade of trusty, i.e. as of yesterday.  last week it all worked fine
<barry> seb128: you're changing the keybinding via g-c-c.real?
<seb128> barry, yes
<samertm> barry: kk, thanks for the info
<brendand> barry, but it doesn't work if held down?
<brendand> barry, i.e. hold alt and press 'f' with other finger
<barry> seb128: so, to be clear, if you open Keyboard->Shortcuts, click on "Key to show the HUD" and tap Super, you see it set to Super?  for me it just reverts to Disabled
<seb128> barry, let me try with super, I tried "backspace" which set it to "disabled" which works
<seb128> barry, super is the key used by the dash
<seb128> that doesn't work
<barry> brendand: correct.  hit and hold Alt for a few seconds, then tap 'f'.  the app with focus will *not* see the event
<barry> seb128: what about right-alt?
<seb128> that's the default key
<seb128> oh, right alt
<brendand> barry, but that works for me in e.g. chromium
<barry> seb128: yes, it wouldn't be so disruptive if it was right-alt only (i personally use left-alt all the time for "alt")
<seb128> barry, that doesn't work, right ctrl works, win key works
<seb128> the menu key works
<barry> seb128: i don't have any of those keys on this keyboard ;)  (no right control, menu, or win)
<barry> i have right alt and right super though
<seb128> barry, is disabled with backspace working?
<barry> brendand: like, what key combination exactly?
<barry> seb128: that's hard to tell, because Key to show the HUD is already "Disabled".  but hitting backspace/delete does still leave it disabled
<brendand> barry, hold down left-alt and press f
<seb128> barry, what is you pick any random key, e.g f8
<barry> seb128: but i can set it to Super+Right and that does "work" in the sense that the shotcut is displayed that way.  and indeed, with show hud set to Super+Right, alt is not captured
<seb128> ok
<seb128> so dunno why right-alt doesn't work, likely an xkeyboard-config issue
<seb128> you just need to find a key that exists on your keyboard and suits you
<barry> brendand, seb128 so, setting it to Super+Right and *then* setting it back explicitly to Disabled (via backspace) defeats the capture too it seems
<mlankhorst> pitti: if you feel like testing, I uploaded xorg-lts-transitional now
<mlankhorst> should fix your geode issue
<pitti> mlankhorst: oh, sweet, thanks
<pitti> mlankhorst: I need to wrap up for today, will do it tomorrow morning
<barry> seb128, brendand thanks.  i will update the bug, but now the pain is gone :)
<seb128> barry, yw
<rbasak> doko: I've filed bug 1278995
<ubottu> bug 1278995 in mod-auth-mysql (Ubuntu) "Please remove mod-auth-mysql from Trusty" [Undecided,New] https://launchpad.net/bugs/1278995
<mdeslaur> xnox: if you do make a separate package for the two codecs, could you not name it with "bad" in the name? :)
<mdeslaur> shipping a package called "bad" or "ugly" by default on devices doesn't sound too appealing :)
<xnox> mdeslaur: it was going to be either inside the hybris package, or hybris-extra, or bad-subset.
<mdeslaur> xnox: those two don't pull libav in, right?
<xnox> mdeslaur: i think we are barred from shipping bad/ugly on default media, anyway... but i'm not going to get into that discussion.
<xnox> mdeslaur: correct, they do not pull in libav, opecv / colorprint and a few other pieces however do.
<xnox> mdeslaur: hence i want to drop them.
<mdeslaur> ok, good
<xnox> mdeslaur: i think we will still be linking to libstreamerparsersbad though, and that's library name....
<xnox> so bad strings are here to stay =)
<mdeslaur> meh, was just a suggestion :)
<mdeslaur> bad-dog-bad-bad-no
 * xnox "but, i just met you, and i already like you....." gosh, "Up" was a good movie!
<Laney> umm
<Laney> xnox: I'd prefer doing genuine splits rather than stuffing things into weird packages
<Laney> please talk to Debian about it ...
<Laney> but if they don't go for it, the normal split still feels right to me
<vp7> is Ubuntu community participating in GSOC this year.
<ScottK> Mirv: Do you know when Qt 5.2 is finally going to land?
<hallyn> stgraber: thouhts on bug 1248283  (last few comments)?
<ubottu> bug 1248283 in juju-core (Ubuntu Trusty) "Juju deploy of Charm in MAAS fails because dbus fails" [High,Triaged] https://launchpad.net/bugs/1248283
<hallyn> i should retitle that bug...  it's purely a dbus bug, not juju
<xnox> ScottK: i spoke with Mirv about it last week, and there were still a few savere regressions on touch (e.g. screen doesn't unlock, unless one disables powerd before screen autolocks for the first time)
<hallyn> there that's better
<hallyn> bug 1248283
<ubottu> bug 1248283 in juju-core (Ubuntu Trusty) "dbus does not restart when 'restart networking' command is issued." [High,Triaged] https://launchpad.net/bugs/1248283
<xnox> ScottK: =/
<ScottK> xnox: I think our process is now fundamentally broken when it's apparently impossible to update libraries in the development release.
<stgraber> hallyn: it's not really a bug because "restart networking" isn't supported, we just don't have a good way to prevent it. The supported way to bounce the network is "ifdown -a && do config changes && ifup -a" or the same but just for the interfaces you are changing.
<xnox> ScottK: i agree. in the mean time i'm writting Qt patches against 5.3... which i'll then have to backport to 5.2, 5.0 and 4.8 by the looks of things.
<stgraber> hallyn: we had a chat about this during the Core Sprint and the CTS folks said they'd make sure our documentation covers this properly (I sent a bunch of patches a while back to get rid of the worst cases)
<hallyn> stgraber: oh that again :)
<ScottK> Please not 4.8.
<xnox> stgraber: if we make networking an instance job (with a default instance whatever, it will be a single one) then "restart networking" will do nothing.
<stgraber> hallyn: "deconfiguring-network" is usually meant as "the system is going down, services should now die, please all exit because the fs is about to go away"
<xnox> stgraber: or better, make it a task =) such that "restart networking" does no harm, or at least doesn't emit deconfiguring-network. What do you think?
<stgraber> xnox: well, we need a started and stopped state because things unfortunately depend on this...
<stgraber> xnox: and it needs to match name with the sysvinit job so services vaguely does the right thing
<hallyn> stgraber: ok, so you would claim the bug is in juju or juju charms for using restart networking?
<stgraber> hallyn: absolutely, nobody should even do restart networking
<stgraber> *ever
<hallyn> stgraber: I wonder if we did a poll, how many ppl would knwo that :)
<stgraber> because it'll almost certainly always do everything but what you want it to do :)
<hallyn> stgraber: thanks, i'll follow up in the bug
<stgraber> well, eveyrone who used it at some point probably had problems and either filed a bug which I'd have closed as invalid/won't fix or they'd have found one of the hundred of places where I tried to explain this :)
<stgraber> hallyn: most people using restart networking also forget that ifupdown isn't stateful, so if your interface was DHCP and you change it to static, then restart networking, this won't kill dhclient so 30min later your IP gets overriden by dhclient
<sarnold> "oh I know I'll just restart networking, that'll do everything" --> "hunh, why is my system suddenly useless?"
<stgraber> hallyn: hence which you're supposed to ifdown => change config => ifup
<hallyn> i still have issues with that, but won't argue them now :)
<stgraber> *why
<hallyn> hm, but i can't figure out where it's being done.  maas and juju dont' seem to do it
<stgraber> hallyn: from instance userdata apparently
<stgraber> at least that's what they show in the bug description
<stgraber> oh and indeed that's just completely wrong because they move eth0 into a bridge without first deconfiguring eth0, therefore leaving it with an IP and a running dhclient
<stgraber> so even if the restart didn't blow things up to pieces, they'd end up with the network config being applied to both eth0 and br0 and two dhclient process running (one on eth0 and one on br0)
<sarnold> what does it mean to run dhclient on a bridge device?
<stgraber> oh and their config also doesn't need to mention eth0 at all, ifupdown is clever enough to figure it out from the br0 config
<stgraber> sarnold: works fine, broadcasts to all devices on the bridge, attempts to get an IP and sets it on the bridge interface
<sarnold> stgraber: crazy, I thought the point of the bridge interfaces was that they were 'below' IP, as it were.
<hallyn> stgraber: i see it in the bug description, but the juju package doesn' tseem to include those.
<stgraber> hallyn: so tl;dr, they should use ifdown eth0 => 'cat > /etc/network/eth0.conf << EOF\niface br0 inet dhcp\n bridge_ports eth0\nEOF\n" => ifup br0, that'll DTRT
<xnox> ScottK: what's wrong with 4.8? there are plenty of apps still using that...
<hallyn> /etc/network/eth0.conf?  that's new to me
<ScottK> xnox: Are you fixing bugs or adding features?  If the former, then nothing.
<xnox> ScottK: so we do still need to maintain it.
<ScottK> Sure.
<stgraber> sarnold: yeah, it's slightly trickier than that, because it both acts like a switch and a member of that switch. So it doesn't have its own MAC address (steals the lowest one in the bridge) but can have IP configuration on it and you can use it like a regular interface (so long as it has at least one member, otherwise it doesn't have a MAC and everything blows up)
<xnox> ScottK: working on the gtk theming plugin.
<xnox> (qgtkstyle)
<sarnold> stgraber: thanks, I think that explains a lot about what I'd been misunderstanding about bridges :)
<stgraber> hallyn: they're using the "source statement" to include an external file. Though they really should be using include-dir and /etc/network/interfaces.d/ since that's what's done by default on new installs now.
<hallyn> stgraber: no no, include-dir isn't yet supported by augeas :)
<stgraber> hallyn: well, clearly they're not using augeas at the moment, so who cares ;)
<hallyn> they'll want to use libvirt using netcf and thatll fail
<hallyn> anyone answer is noone seems to care so i'll probably ahve to update the lens :(
<stgraber> so augeas supports source but not include-dir? that seems odd since the latter is basically a wildcard source (ish, there's a regexp in the interfaces manpage)
<hallyn> stgraber: the source support is actually not yet committed iiuc.
#ubuntu-devel 2014-02-12
<Mirv> ScottK: my best estimate would be in 2.5 weeks from now, with the new 5.2.1 fixing some remaining issues and QA team coming up to speed in testing with 5.2.1 appearing in PPA soon. there'll be a bit of new extra work also because mkspecs location changed in Debian recently and that wasn't reflected in our packaging before now.
<Noskcaj> Can someone please upload lp:~noskcaj/+junk/gnome-weather to trusty? debian won't upload it in time and ubuntu-gnome needs it
<Noskcaj> oops, lp:~noskcaj/+junk/gnome-photos actually
<RAOF> pitti: Yo!
<pitti> Good morning
<pitti> RAOF: hey
<RAOF> pitti: Good morning!
<RAOF> I've got two questions - how soon will those umockdev commits land in trusty, and how would you like the load_ioctl(testbed, NULL, "foo.ioctl") thing implemented?
<RAOF> Hm. But first I apparently need to get some mushrooms, so I'll ping you again later :)
<pitti> RAOF: if you want those commits, I'll do a microrelease/upload today
<pitti> RAOF: ioctl_record_open() needs to write $UMOCKDEV_IOCTL_RECORD_DEV (major/minor) as the first line into the .ioctl file; or if that's impractical/ugly, umockdev-record needs to pass the original device name in addition (perhaps UMOCKDEV_IOCTL_RECORD_DEVNAME)
<pitti> RAOF: then ioctl_tree_new_from_text() needs to be able to load that
<pitti> RAOF: perhaps "@DEV /dev/...." (@ to make it an invalid ioctl name)
<pitti> RAOF: hm, actually evaluating it in ioctl_tree_new_from_text() is a bit impractical, as you'd need to pass it upwards and back in time
<pitti> RAOF: so I guess ioctl_tree_new_from_text() should just ignore it, and load_ioctl() itself needs to open it once, read the first lines, and evaluate the @ commands
<pitti> RAOF: you need to make "string dev" to "string? dev", check it for null, and if it is, open the file, read the devname, and use that instead of "dev"
<RAOF> pitti: Ah, good. That was roughly what I was thinking, except using # instead of @.
<pitti> RAOF: # is an usual comment character, though
<pitti> RAOF: we support # in .script files; not sure that it already does in .ioctl files, but it should
<pitti> (particularly when you hand-edit them)
<RAOF> Right; I was going to have ioctl_record_open write something like "# originally recorded from: /dev/baz"; â@ DEV /dev/...â seems better, though.
<RAOF> pitti: So, I notice that ioctl_record_open supports appending to existing .ioctl files. How would you want that handled?
<pitti> RAOF: right, if the file already has non-zero length you shouldn't write it again
<pitti> syntactically it should be ok (ioctl_tree_* should just ignore @DEV entirely), but it would look confusing
<RAOF> Or we could support loading for multiple things, with a little bit of extra effort in umockdev.vala
<RAOF> If you don't think loading for multiple things is likely to be valuable (it's not something I want at the moment), just suppressing it for non-zero file lengths is fine.
<pitti> hm, I wouldn't want to stuff traces from multiple different devices into one .ioctl file TBH
<pitti> the format and its traversing is complicated enough as it is
<RAOF> Sweet.
<RAOF> So, should umockdev-record error out if it tries to append something from a different device node?
<pitti> there should be an assertion
<pitti> it Should Not Happenâ¢, so it doesn't need to be a fancy error message
<pitti> oh wait
<pitti> if one umockdev-record sessio opens the device multiple times, it can't happen
<pitti> but you can record into the same file multiple times, indeed
<pitti> RAOF: so yes, then umockdev-record should error out
<RAOF> Good.
<pitti> if we want to support that at some point, we can do that without breaking compatibility
<RAOF> Indeed. It wouldn't be _super_ hard to do (read in the file in umockdev.vala, split it out into the apropriate ioctl files), but I don't know if it's _useful_ :)
<pitti> *nod*
<pitti> RAOF: yeah, I'm more concerned about user confusion than implementation
<pitti> mlankhorst: tested ppa7, I followed up to bug 1278737
<ubottu> bug 1278737 in xorg (Ubuntu Trusty) "Upgrade to trusty fails from precise backported enablement stacks" [High,In progress] https://launchpad.net/bugs/1278737
<mlankhorst> pitti: well it seems that multi-arch: no is required on newer ubuntu, but precise used multi-arch: none..
<mlankhorst> I'll just skip that field altogether
<pitti> if it's not there, it should be similar to M-A: same, right?
<mlankhorst> no it skips to multi-arch: none I guess
<mlankhorst> which is what's needed
<dholbach> good morning
<mlankhorst> pitti: yeah I fixed m-a none, can you still hit the geode issue?
 * pitti boots the precise live system
<pitti> mlankhorst: confirmed, no held back packages any more; great!
<mlankhorst> good
<pitti> mlankhorst: want to upload? I can do the NEWing, and then re-run the full upgrade tests
<mlankhorst> I can't upload, tjaalton? :P
<tjaalton> push it to git
<pitti> mlankhorst: I can sponsor it, if you want
<pitti> mlankhorst: (with dropping the ~ppa suffix)
<tjaalton> hm can't use git since it had the merge from debian already staged
<pitti> it's a new source package
<tjaalton> ah
<tjaalton> ok then :)
<pitti> and it'll get removed in trusty+1 again
<mlankhorst> https://mblankhorst.nl/etc/ xorg-lts-transitional*
<pitti> so probably not worth the trouble
<tjaalton> I thought it was xorg source modified
<tjaalton> sure
<mlankhorst> tjaalton: no way I want to have this hit version control
<mlankhorst> :P
<tjaalton> hehehe
<tjaalton> no complaints there
<mlankhorst> pitti: at one point you need to upgrade and confirm whether /usr/lib/xorg/protocol.txt still exists
<pitti> mlankhorst: *nod*; is its existance enough, or should we assert some contents?
<pitti> mlankhorst: I can add that as a post-upgrade test
<mlankhorst> no, existence is enough
<pitti> mlankhorst: and protocol-{precise,*}.txt should not exist any more?
<mlankhorst> I'm also curious about "update-alternatives --config x86_64-linux-gnu_gl_conf" after upgrade
<mlankhorst> pitti: just protocol-precise.txt that exists
<mlankhorst> it's overridden by xserver-common
<pitti> mlankhorst: I mean after the upgrade
<mlankhorst> yeah protocol-precise.txt should be gone
<pitti> in trusty we certainly don't expect protocol-precise.txt any more, or do you?
<mlankhorst> it was a diversion added by xserver-common-lts-w/e
<pitti> *nod*
<pitti> mlankhorst: hm, no copyright file, I'll add a simple one
<mlankhorst> 'not eligible for copyright' really!
<mlankhorst> there are no contents either! :-)
<seb128> slangasek, infinity, cjwatson: does any of you have a strong objection to restrict the list of archs for firefox to amd64/armhf/i386? (same as chromium) It fails to build on arm64/ppc/ppc64 and noboby seems to have available slots to work on those issues, meanwhile that blocks migration to trusty and means we are 3 versions behind (we never had a version built on the trusty toolchain yet)
<seb128> chrisccoulson, ^
<doko> seb128, there are patches for arm64, which were once overwritten by chrisccoulson
<seb128> doko, those patches were not upstreamed and we don't have the resources to distro maintain them and rebase on new versions by ourself
<doko> jamespage, 1268915 is still incomplete. could you subscribe?
<chrisccoulson> indeed, and they only make it build. without a jit compiler for arm64, it would be even more unusable than the current arm build
<chrisccoulson> which is already terrible
<jamespage> doko: done
<chrisccoulson> it looks like ppc actually builds, but then crashes when creating the startup cache. that needs someone with real hardware to debug that really
<seb128> not having a porting box for ppc doesn't help there
<pitti> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Trusty Tahr Alpha 2 released! | Archive: open | 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: pitti
<seb128> ups, pitti went offroad
<seb128> pitti, easy on the piloting ;-)
 * seb128 hugs pitti (just saw the ibus-pinyin sync)
<pitti> seb128: yeah, sorry about taht; already undid my damage
<seb128> no worry
<seb128> happyaron filed the libpyzy MIR and mterry already did a first review, good
<Guest3895> seb128: hey
<happyaron> seb128: hey
<seb128> happyaron, hey
<seb128> lol, I was looking for you, I even looking in the calendar to see if you were off
<happyaron> seb128: shall I subscribe desktop team for libpyzy?
<happyaron> :)
<seb128> happyaron, "desktop-bugs" is our bugs team
<seb128> so yes
<seb128> or let me know if you don't the rights to do that
<happyaron> seb128: I can't subscribe it on LP, :(
<darkxst> pitti, pilot, can you take a look at the gnome-ey stuff in the queue
<seb128> darkxst, from #ubuntu-desktop backlog, seems he's already doing
<darkxst> seb128, boom :( gdm still restarting ;(
<seb128> darkxst, did you try twice?
<seb128> darkxst, it's the prerm from the installed version that stops it
<pitti> darkxst: I'm at gnome-menus ATM
<seb128> darkxst, so when installing the new fixed deb it's going to restart, because of the prerm of the installed version, then it should work
<darkxst> seb128, yes, right, it worked second time
<Laney> you should sed the prerm of the old one ;-)
 * Laney RUNS
<darkxst> pitti, there is also lp:~noskcaj/+junk/gnome-photos, I told Noskcaj to file a bug but he didnt ;(
<Laney> oh actually I don't think you can
<Laney> https://wiki.debian.org/MaintainerScripts?action=AttachFile&do=get&target=upgrade.png
<pitti> darkxst: bug 1279201
<ubottu> bug 1279201 in Ubuntu "[needs-packaging] gnome-photos" [Wishlist,Fix committed] https://launchpad.net/bugs/1279201
<darkxst> pitti, ah, ok
<pitti> darkxst: ah, gnome-photos landed in the NEW queue 23 mins ago
<darkxst> yes, I see that now
<tjaalton> hum, trusty doesn't seem to recognize win 8.1 at all.. the partitioner says the disk is empty
<RAOF> tjaalton: And yet grub finds it just fine!
<tjaalton> RAOF: didn't go that far yet, this is still the installer
<tjaalton> and I'd like to keep win8.1 there, if only just for civV which just crashes here on wine :)
<RAOF> Oh, indeed.
<RAOF> You should probably also want to keep XCOM:EW :P
<tjaalton> don't have that one, yet anyway :)
<cjwatson> seb128: there are a *lot* of rdepends on firefox - for instance packagekit's arch-specific build-depends would need to be tweaked if we were removing firefox/powerpc.  I can see your point but it needs actual thought and hard work following the rdepends stack and thinking about it rather than just restricting the arch set
<cjwatson> it's probably tractable, but please make sure that that work is done rather than just left to +1 maint or something
<seb128> cjwatson, thanks for pointing that out. What would be the right place to have that discussion? ubuntu-devel@?
<cjwatson> Seems reasonable, yeah
<seb128> thanks
<spineau> doko: hello, could it be possible to move to main the following checkbox dependencies? bug 1277408 and bug 1278822. So that our next upload of checkbox can have all its dep in main
<ubottu> bug 1277408 in checkbox-ng (Ubuntu) "[MIR] checkbox-ng" [Undecided,Fix committed] https://launchpad.net/bugs/1277408
<ubottu> bug 1278822 in plainbox-provider-checkbox (Ubuntu) "[MIR] plainbox-provider-checkbox" [Undecided,Fix committed] https://launchpad.net/bugs/1278822
<pitti> RAOF: oh, to clarify: (1) do you want to work on the load_ioctl(NULL) thingy, and (2) do you want a release now or wait on (1)?
<RAOF> pitti: (1) yes, and (2) yes, please wait.
<tseliot> cjwatson: QA caught an issue with Jockey in 12.04.3 (hybrid graphics won't work with the new X stack). I've filed bug #1279229 and uploaded a fix in precise-proposed
<ubottu> bug 1279229 in jockey (Ubuntu) "Jockey is unable to check Saucy's xserver ABI" [High,In progress] https://launchpad.net/bugs/1279229
<pitti> RAOF: ack, thanks
<RAOF> pitti: Also - do we get DEP-8 tests run on syncs from Debian? I added some to fsharp, but they don't seem to have been run.
<pitti> RAOF: we generally do, yes
<Laney> They get missed on the first upload AFAIK
<pitti> that was fixed
<pitti> RAOF: trÃ¨s interessant, I'll have a look at that later
<Laney> Well then, :)
<RAOF> Just to check - they should show up on https://jenkins.qa.ubuntu.com/view/Trusty/view/AutoPkgTest/ if they get run, right?
<pitti> correct
<pitti> Testsuite: autopkgtest
<pitti> that looks fine to me, too
<pitti> cjwatson: is https://code.launchpad.net/~dannf/ubuntu/trusty/base-installer/arm64/+merge/199972 something you'd rather handle yourself, or should I sponsor this?
<cjwatson> I'll take care of it, I did most of the rest of that stuff at the core sprint
<pitti> cjwatson: ack
<cjwatson> just ran out of time there
<pitti> https://code.launchpad.net/~dannf/ubuntu/trusty/base-installer/arm64+calxeda-subarches/+merge/199977 as well then, I assume
<pitti> (which includes the previous MP)
<cjwatson> yeah
<seb128> happyaron, desktop-bugs subscribed to libpyzy now
<happyaron> seb128: great
<tjaalton> my partman bug was already reported https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=731736
<ubottu> Debian bug 731736 in debian-installer "partman doesn't detect GPT partitions installed Windows 8.1" [Important,Open]
<tjaalton> huh, why are we still on parted 2.3?
<tjaalton> found debian #646130
<ubottu> Debian bug 646130 in parted "parted versions lags behind" [Normal,Open] http://bugs.debian.org/646130
<tseliot> cjwatson: did you get my message?
<cjwatson> tseliot: probably best not to rely on just me for all things precise since I need a break from it after 12.04.4, but I'll have a look at this SRU I guess
<pitti> mlankhorst: oh, http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
<pitti> mlankhorst: xserver-xorg-video-geode-lts-* mustn't be built on amd64
<Laney> bdrung: Is there a way to use ubuntu-distro-info to get the full name (-r) of the current release?
<cjwatson> tseliot: ok, looks reasonable
<bdrung_work> Laney, current release = the latest stable release?
<Laney> bdrung_work: the one you're running it on
<pitti> mlankhorst: fixing..
<Laney> or maybe going from codename to release would be okay
<Laney> trusty â 14.04 LTS for example
<cjwatson> tseliot: (accepted)
<bdrung_work> Laney, no. distro-info has no info what release you are running on
<bdrung_work> currently it does not support a codename -> fullname/release mapping
<tseliot> cjwatson: ok, thanks a lot
<seb128> bdrung_work, hey, did you get my email about Sweetshark's libroffice's ppu application?
<Laney> xnox: ^
<Laney> I read that as 'patches welcome'
<bdrung_work> seb128, probably. i'll hope to find time to process my mail backlog at the weekend
<seb128> bdrung_work, good ... is that application still blocked on anything?
<pitti> mlankhorst: http://paste.ubuntu.com/6919521/
<xnox> bdrung_work: Laney: thanks.
<bdrung_work> seb128, i have to look into the mail and look at the progress of the last month
<bdrung_work> xnox, yes, patches are welcome
<seb128> bdrung_work, do you think you are going to have slots to do that soon? if not can you delegate to other ppu members?
<seb128> bdrung_work, that application is ongoing for ages and we feel like we addressed all the initial concerns, it would be nice to see things moving or have an update on what more should be done
<bdrung_work> seb128, i'll try to do it on the weekend. otherwise i have to delegate it.
<seb128> thanks
<bdrung_work> since i have a job, my free time is heavily reduced
<xnox> bdrung_work: may i upload https://bugs.launchpad.net/ubuntu/+source/debootstrap/+bug/1012439 ?
<ubottu> Launchpad bug 1012439 in debootstrap (Ubuntu) "carve out distro information to distro-info package" [Undecided,Confirmed]
<Laney> that's a long week :P
<bdrung_work> xnox, you may :)
<bdrung_work> i think there was an objection against this patch
<denisw> hi
<xnox> Laney: like my accidental 6 month holliday?! =)
<Laney> accidents happen right
<Laney> anyway I heard we know one of the debootstrap maintainers ;-)
<denisw> was it a deliberate decision to have the desktop web apps integration use the touch-optimized webbrowser-app in trusty? will that app be made more desktop friendly before the trusty relase?
<bdrung_work> xnox, bonus: get the patch into debian
<xnox> Laney: debootstrap maintainers? who is that? =)
<bdrung_work> http://packages.qa.debian.org/d/debootstrap.html
<cjwatson> xnox: please don't diverge debootstrap in Ubuntu, it's hassle
<xnox> cjwatson: ok.
<cjwatson> xnox: that latest version of the debootstrap patch is probably ok, but if we use it it should be in Debian
<cjwatson> (case in point, I just synced debootstrap)
<cjwatson> xnox: but hey, you're in the d-i team these days
<mardy> cjwatson: hi! I updated https://code.launchpad.net/~mardy/click/lp1245826/+merge/204674
<cjwatson> mardy: ack, will look later today, trying to finish something else off
<doko> bdmurray, did you find out anything about the php issues?
<shadeslayer> so if I run : grep-dctrl -P kde4libs -F Build-Depends /var/lib/apt/lists/es.archive.ubuntu.com_ubuntu_dists_trusty_main_source_Sources   : it seems to give me the entire kde4libs source information, but I explicitly told it to give me the Build Depends field, any ideas what I'm doing wrong?
<cjwatson> -F is "search by this field"; if you want "show this field" you need -s instead
<shadeslayer> ahh
<mlankhorst> pitti: can you make xserver-common* architecture: all ? and I want to point out that you matched with *geode** :P
<apachelogger> pitti: any objections to modifying the apport cleanup cronjob to also clean the drkonqi files we create through kdelibs?
<pitti> apachelogger: fine for me
<doko> jamespage, why did you drop the juju gccgo binaries for x86? are these builds still being tested?
<jamespage> doko, not any longer
<doko> jamespage, are any gccgo binaries being tested?
<jamespage> doko, on ppc64el and arm64 yes
<doko> ok
<jamespage> doko, oh - and upstream will be checking with gccgo still so we don't regress those platforms
<doko> upstream?
<jamespage> doko, juju team
<doko> ahh
<apachelogger> hm
<apachelogger> pitti: apport's cron actually excepts whoopsie's .upload*, do you simply leave them around since they are 0byte anyway?
<pitti> apachelogger: they are cleaned up after 7 days
<pitti> apachelogger: I guess ev did it that way to avoid cleaning up crahses which have an .upload but not an .uploaded yet, or so (but I'm not sure, it woudln't work that way)
<apachelogger> mh
<apachelogger> pitti: ok, going hold on to that then since the drkonqi stuff is related ^^
<pitti> mlankhorst: WDYT? http://paste.ubuntu.com/6919792/
<mlankhorst> pitti: looks good!
<pitti> uploaded
<mlankhorst> maybe that will fix the weird issue
<rbasak> tjaalton: just looking at bug 1278898. The server team aren't actively looking after cobbler now, since the MAAS team stopped depending on it. I also note that there's no Debian package for this now. Are you happy to continue caring for the package in universe, or should we drop it?
<ubottu> bug 1278898 in cobbler (Ubuntu) "cobbler-web: import error with django 1.6.x (trusty)" [Undecided,New] https://launchpad.net/bugs/1278898
<tjaalton> rbasak: there's a new upstream bugfix release to address that, I'll push that to trusty soon
<tjaalton> packaging has been in collab-maint git, but guess there's no itp for it yet
<rbasak> Ah, OK. Thanks!
<apachelogger> pitti: https://code.launchpad.net/~apachelogger/apport/cleanup-drkonqi-files/+merge/205955
<pitti> apachelogger: bah, this is rather hard to read :)
<pitti> apachelogger: i. e. this cron job does *not* remove drkonqui files after 7 days, while current apport does?
<apachelogger> pitti: what, for me the find returned the drkonqi files with mtime >7days
<apachelogger> alas, the find syntax is nigh unparsable to my puny mind
<pitti> apachelogger: oh of course, I missed the -o
<apachelogger> pitti: ^^
<pitti> apachelogger: merged, danke; how soon do you want/need this in trusty?
<pitti> (probably not that urgent, right?)
<apachelogger> pitti: not urgent
<apachelogger> thanks for merging :)
<seb128> hum, what's the best way to run checkrdepends nowadays?
 * seb128 is reading https://wiki.ubuntu.com/ArchiveAdministration#NBS
<pitti> seb128: reverse-depends from ubuntu-dev-tools AFAIK
<pitti> it's fast, and reasonably correct
<seb128> that needs a local mirror right? do we have an archive admin available box recommended for that?
<pitti> no, it reads from LP or UDD or something like that
<rbasak> Ah, handy. Thanks!
<seb128> pitti, I was speaking about checkrdepends
<pitti> a local mirror is an incredibly heavy beast, I doubt that many people have one
<pitti> seb128: so was I
<seb128>  reverse-depends gnome-control-center-signon-autopilot
<seb128> No reverse dependencies found
<seb128> pitti, it errors out out on
<seb128> IOError: [Errno 2] No such file or directory: '/home/ubuntu-archive/mirror/ubuntu/dists/trusty/main/source/Sources.gz'
<seb128> for me
<seb128>   -B ARCHIVE_BASE, --archive-base=ARCHIVE_BASE
<seb128>                         archive base directory (default: /home/ubuntu-
<seb128>                         archive/mirror/ubuntu)
<seb128> or is archive base dir /var/lib/apt/lists?
 * seb128 tries
<pitti> reverse-depends src:gnome-control-center-signon
<pitti> you might want that?
<pitti> reverse-depends -b src:gnome-control-center-signon
<pitti> and that for reverse build deps
<pitti> (account-plugins and empathy in that case)
<seb128> pitti, seems fine to delete the gnome-control-center-signon and gnome-control-center-signon-autopilot binaries then, right?
<seb128> or am I overlooking something
<pitti> seb128: gnome-control-center-signon has reverse depends
<seb128> pitti, which one?
<pitti> seb128: http://paste.ubuntu.com/6920308/
<pitti> does that look any different for you?
<seb128> pitti, those all have a "unity-control-center-signon | gnome-control-center-signon"
<pitti> aah
<seb128> if I didn't overlook things
<pitti> fine then
<seb128> pitti, should we change https://wiki.ubuntu.com/ArchiveAdministration#NBS to recommends using reverse-depends over  "checkrdepends -b"?
<pitti> seb128: yes, sounds good; shell login is generally disabled now
<seb128> cjwatson, infinity: ^
<seb128> pitti, danke
<geser> pitti, seb128: reverse-depends queries a webservice on qa.ubuntuwire.org
<cjwatson> ok
<cjwatson> Let's still keep checkrdepends around though; for those with access to it it has stronger guarantees of being current
<seb128> on what box can that be run? pepo?
<seb128> (seems I don't have ssh to that one)
<cjwatson> ubuntu-archive@snakefruit
<seb128> cjwatson, thanks
<bdmurray> doko: no, not yet
<doko> pitti, does dbus in trusty diverge that much from unstable? https://launchpadlibrarian.net/164705202/buildlog_ubuntu-trusty-i386.python-notify2_0.3-2_FAILEDTOBUILD.txt.gz
<seb128> doko, ** (notification-daemon:2593): WARNING **: Error retrieving accessibility bus address: org.freedesktop.DBus.Error.ServiceUnknown: The name org.a11y.Bus was not provided by any .service files
<seb128> doko, seems like you are missing a depends on at-spi or something
<seb128> or at-spi2-core rather to be exact
<doko> seb128, it did build before ...
<pitti> doko: it's not dbus itself, something in gtk/whatever now requires at-spi2-core
<mitya57> I think rather notification-daemon should depend on that
<pitti> mitya57: agreed
<seb128> speaking of notification-daemon, if anyone still uses it/cares about it, it needs to be fixed for incorrect g_source_remove use
<seb128> that's an issue with new glib and is ranked high enough on the trusty reports
<seb128> on e.u.c
<mitya57> Hm, no, neither notification-daemon nor python-notify2 reference a11y in the code
<pitti> I've seen this quite often recently
<pitti> my suspicion is that it's something in GTK, and that gtk itself should depend on it
<seb128> pitti, libgail-3-0 depends on at-spi2-core
 * seb128 doesn't understand the a11y stack enough to figure what's the right thing to do there
<seb128> I though libgail was needed for a11y?
<pitti> that build log doesn't install gail, though
<seb128> pitti, https://launchpad.net/ubuntu/+source/gtk+3.0/3.5.8-0ubuntu1
<seb128> that's where it got added
<seb128> I think GTK upstream has been working on dropping gail and moving a11y directly in gtk
<seb128> so yeah, maybe having libgtk-3-0 depending on it would make sense
<seb128> would be useful to get a bt of those warnings
<seb128> to see what is the caller
<pitti> G_DEBUG=fatal-warnings?
<mitya57> G_DEBUG=fatal_warnings (with underscore)
<mitya57> or maybe dbus-monitor
<seb128> thanks guys, I know how to get one
<seb128> I'm just dealing with 5 stuff already so I was hinting in case somebody has the setup to trigger the warning
<seb128> I can try in a bit otherwise
<seb128> ;-)
 * seb128 usually do "b g_log" instead
<seb128> so you can go pass the first warning
 * mitya57 is in battle with mathjax packaging, so not now
<dobey> cjwatson: can we install a hook or something from the click scope, that gets run whenever a click package is installed (like a dpkg trigger but for click)?
<cjwatson> click packages can attach to hooks; there's no way to write a hook that will run for *any* click package installation right now
<cjwatson> that's possible, would need to be specced with some thought
<dobey> cjwatson: oh ok. i was just thinking that it would be nice for the click scope to be refreshed when i adb shell and install a click package that way (or do it from qtcreator or whatever)
<cjwatson> I suppose the simplest way would be to make the Pattern field (https://click.readthedocs.org/en/latest/hooks.html) optional, in which case no symlink would be created and we'd just run whatever Exec says
<cjwatson> would that work for you?
<cjwatson> (if so, please file a bug, I'm not going to get to it this week)
<dobey> i'm not sure, but probably.
<dobey> right, we're in a bit of rush on scope development right now as well. so if we can't do it right now, it'll have to wait a bit anyway
<dobey> but i'll read the hooks doc and let you know
<cjwatson> well.  I could maybe do it on Thu/Fri if it's a simple enough approach, but it'd be my first proper release under the ci train stuff so I can't guarantee it
<dobey> cjwatson: yeah, no worries. i don't want to block the scope work on it so we're going to have to do the results invalidation call a different way for now. but i'll see if your suggestion makes sense (or if i think of something better while reading the docs), and file a bug
<caribou> pitti: I see that you have merged my clamav MP, though I thought it was still waiting for a fix
<caribou> pitti: I just updated the MP with a potential modification
<pitti> caribou: I posted the modification I did to the MP and to the bug
<caribou> pitti: yeah, just seeing the emails
<caribou> pitti: my suggestion was to replace the [[:space:]] with \b as the reasoning behind that is to be able to discriminate on word boundary
<pitti> caribou: \b looks fine as well, but [[:space:]] should work equally well
<caribou> pitti: I do think so. So let keep it as it is then
<pitti> after all, you could potentially have a variable Logfile-Destination /dev/null
<pitti> and \b would match after LogFile
<pitti> (perhaps)
<caribou> pitti: I'll fix the debdiffs in the bug
<pitti> I mean, I don't know whether clamav allows that
<pitti> but [[:space:]] seems fine
<caribou> pitti: dunno. I'll open a bug on this on Debian
<pitti> caribou: thanks, appreciated
<caribou> pitti: thanks for the merge, I'll get the SRU fixed
<pitti> caribou: I already fixed the precise SRU
<caribou> pitti: ah, ok then I won't bother
<caribou> pitti: such a small fix
<psusi> how can I get an rdepends on udebs?  possibly using the package cache within a d-i build tree?
<caribou> pitti: btw, I had the same issue with UDD and the time it took to check it out
<roadmr> Hello! My source package stopped building some now-deprecated binaries, so the new upload is in -proposed with a series of "out-of-date" on the deprecated binaries. How can I fix this? do the old binaries need to be removed?
<seb128> roadmr, you need an archive admin to delete the NBS binaries I think
<stgraber> roadmr: what source package is that and what binaries did you drop?
<psusi> ahh, figured it out...
<roadmr> stgraber: source: checkbox, dropped binaries: checkbox-gtk, checkbox-urwid
<stgraber> roadmr: ok, taking a look now
<cjwatson> FWIW this only happens if the binaries were dropped in a subsequent upload when there was already an unmigrated upload in -proposed
<cjwatson> it's a corner case due to -proposed being a partial suite
<roadmr> stgraber: also, my source package was building python3-checkbox-support which exists only in -proposed, but that overlaps the same package (version 0.1 I think) from debian. I fixed this but I guess the stale binary stayed in proposed and is also considered out-of-date
<psusi> wait... maybe not... those are non udeb rdepends somehow...
<stgraber> roadmr: you actually have a bigger problem, you regressed architecture support
<pitti> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Trusty Tahr Alpha 2 released! | Archive: open | 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:
<stgraber> roadmr: checkbox used to build on all architectures, now it fails on arm64, powerpc and ppc64el
<roadmr> stgraber: I saw it failing due to lack of some qt5-sensors dependency, but it's not actually needed, my latest upload should have fixed that. I can double-check that too
<stgraber> roadmr: I'm looking at https://launchpad.net/ubuntu/+source/checkbox/0.17.4ubuntu3
<roadmr> stgraber: oh, I removed the qtsensors5-dev dep but now it's stuck on qtmultimedia5-dev
<stgraber> roadmr: so I resolved the pytohn3-checkbox-support bit for now, I'll let you upload something which fixes those 3 arches then we can see what britney thinks about migrating those
<stgraber> cjwatson: right, python3-checkbox-support was in that case (introduced in ubuntu2, dropped in ubuntu3, never migrated)
<roadmr> stgraber: cool, thanks so much! I'll fix that asap
<alow> infinity: Would like to chat about PPC64el and libv8
<infinity> alow: Perhaps when I'm out of this current meeting/call.
<infinity> alow: I meant to follow up to your email, but I've been headless chickening the last day or two.
<alow> infinity: no problem. I've been hacking away to create minimal diffs between the v8 levels. I've created a unique branch for libv8 https://github.com/andrewlow/v8ppc/tree/libv8-3.14
<infinity> alow: Awesome.  And, as an added bonus (not a requirement, but a bonus), I understand this works on big-endian as well?
<alow> infinity: It should - I haven't tested that specifically. I'd be happy to hit both BE / LE
<alow> infinity: I'm off on vacation soon for a bit, so it'd be good to get this working for others soon
<infinity> alow: Righto.  I will probably end up testing on ppc32be by accident, since that's my primary development workstation in my house. :P
<infinity> alow: I'll try to find some time to poke at it today, after I throw some time at glibc stuff this morning.
<alow> so my repo https://github.com/andrewlow/v8ppc/tree/libv8-3.14 doesn't include the debian/ directory in it (yet) - would that be preferred?
<infinity> alow: No, no.  A simple branch of upstream is much easier to work with, importing debian directories and spec files tends to end in tears when they diverge from the distros anyway.
<alow> infinity: oh good. so.. from here http://packages.ubuntu.com/source/trusty/libv8-3.14 I took the repository git://anonscm.debian.org/collab-maint/libv8.git and used that as a comparison base for  https://github.com/andrewlow/v8ppc/tree/libv8-3.14
<alow> when I mix in a slightly hacked debian directory to support ppc64el -- I get .deb files out the other side
<infinity> A positive result. ;)
<infinity> Does it run a testsuite at build time?  I haven't looked at v8 packaging.
<alow> infinity: one caveat - I don't understand how the debian/patches directory gets applied. So I run the makefile / gyp patch manually
<alow> infinity: yes - testsuite gets run
<alow> infinity: >>> Running tests for ppc64.release
<alow> Converting status file.
<alow> Converting status file.
<alow> Converting status file.
<alow> No connection to distribution server; running tests locally.
<alow> [01:28|% 100|+ 6093|-   0]: Done
<infinity> alow: Kay, cool.  As for patches, that depends on the source format, but if it's 3.0(quilt), the patches are applied at source unpack by dpkg.
<infinity> alow: Based on the debian/patches/series file.
<alow> infinity: Ok - I'm not sure I've setup things correctly in my builds then. I'll poke at that. I start with the source tree in place and use 'fakeroot debian/rules binary' to build
<alow> infinity: but I'm fairly confident my code in the repo is suitable for the build at this point
<alow> infinity: patches may not all apply clean - I'll try to validate that
<infinity> alow: Kay.  Will you be around in ~30m, when I'm not multitasking too much here? :)
<pitti> mlankhorst: success!
<alow> infinity: yes
<pitti> mlankhorst: I'll add the protocol.txt post-upgrade test tomorrow; we don't keep around the container after upgrade, so I can't check right now
<pitti> mlankhorst: I filed bug 1279411 as a reminder, does that sound right?
<ubottu> bug 1279411 in Auto Upgrade Testing "check for /usr/lib/xorg/protocol.txt after upgrade" [Undecided,New] https://launchpad.net/bugs/1279411
<mlankhorst> pitti: thanks
<infinity> alow: Alright, grabbing the Debian source and cloning your git repo and having a morning smoke.  I'll be with you shortly. :P
<alow> infinity: cool - I'm around
<pitti> mlankhorst: http://bazaar.launchpad.net/~auto-upgrade-testing-dev/auto-upgrade-testing/trunk/revision/90 (tested locally)
<infinity> Gah, only 250KB/s from github?  Internets, why do you hate me this morning?
<pitti> mlankhorst: rolled out, I'll check the results tomorrow
<pitti> mlankhorst: you are right: http://d-jenkins.ubuntu-ci:8080/job/upgrade-ubuntu-precise-trusty-desktop-lts-raring-i386/13/artifact/results/bootstrap.log
<pitti> - ['/usr/lib/xorg/protocol-precise.txt', '/usr/lib/xorg/protocol.txt']
<pitti> mlankhorst: that's what's left after the lts-raring â trusty upgrade
<pitti> mlankhorst: so the diversions should be cleaned up
<pitti> mlankhorst: I filed bug 1279424
<ubottu> bug 1279424 in xorg-lts-transitional (Ubuntu) "Needs to clean up /usr/lib/xorg/protocol-precise.txt" [Undecided,New] https://launchpad.net/bugs/1279424
<pitti> jibel: ^ FYI (in case you wonder why green tests go back to yellow)
<jibel> pitti, thanks for adding new tests. I'm pretty sure you can find tests that will make it red :)
<pitti> at most yellow, I hope
<tester56> will vlc 2.2 land in trusty?
<Logan_> tester56: does it even have an ETA?
<tester56> Logan: oh damn ... I do not know, sorry for that. As I have it running here, I supposed it was released already, my mistake sorry for the inconvenience. It has been in development for quite some time now if I am not mistaken
<Logan_> haha, no need to apologize
<Logan_> if it lands before Feature Freeze, we can likely maneuver it into trusty, but I'd rather go with Debian's releases
<Logan_> and Feature Freeze is in eight days, so it doesn't look like that'll be happening :P
<Logan_> unless there's a good reason to merge it in
<cjwatson> Coo, ci.debian.net exists
<cjwatson> Just noticed it from my qa.debian.org/developer.php page
<roadmr> stgraber: We introduced a few new build-deps (and dependencies) for checkbox, and some aren't available for those archs (arm64 and ppc). That's where my arch support regression comes from.
<stgraber> roadmr: does checkbox absolutely need those or could you have ti build on those arches without those build-deps?
<stgraber> roadmr: (making those arch-specific build-deps and deps and have checkbox do the right thing at build time)
<mpt> bdmurray, I see the new color for 14.04 is on <https://errors.ubuntu.com/>, but the milestone lines arenât. Does that mean thereâs something wrong with the milestone line code, or is it just that the rollout included the former but not the latter?
<roadmr> stgraber: they're actually for a new checkbox-gui binary, maybe we could do what you say and then checkbox-gui would just be unavailable for those archs
<mpt> bdmurray, or a simpler way of asking the question: What revision is the current rollout? :)
<stgraber> roadmr: I guess that'd be reasonable, yes, make checkbox-gui arch:any and only building on the arches that have those bits, changed your build depends to also be arch-specific and change your build process so that it only attempts to build the GUI bits if those build-deps are present.
<bdmurray> mpt: rhe rollout included the milestone colors, so it may be something with the graph code
<mpt> ok, thanks
<roadmr> stgraber: ok, sounds good, I'll get working on this. Thanks so much for your help and guidance!
<stgraber> np
<Logan_> does anyone else run trusty in a VirtualBox VM? I'm having screen resize issues with the latest update
<Logan_> debfx: ^
<seb128> do we have arm64 porter boxes?
<seb128> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt has
<seb128> skipped: gnome-control-center-signon (52 <- 1)
<seb128>     * arm64: unity-control-center-signon
<seb128> not sure how to debug that
<infinity> seb128: It means unity-control-center-signon is uninstallable on arm64...
<seb128> infinity, yeah, which would be easier to figure out why if I had access to an arm64 chroot/porter box ;-)
<infinity> So, there isn't a porter box right now due to lack of hardware to go around.
<seb128> how would you recommend trying to debug that?
<infinity> seb128: Check your channel invites. :P
<seb128> infinity, and why is unity-control-center-signon being uninstallable blocks migration when it's a new binary and has never been installable?
<alow> BenC: infinity pointed me your way in regards to e500 v2 hardware. Today my v8 port doesn't work on e500 https://github.com/andrewlow/v8ppc/issues/100 - I'd like to fix, but need ready access to hardware
<BenC> alow: I can get you access to e500mc, but I don't have anything for e500v2 (which, you probably shouldn't care about anyway)
<BenC> alow: I can try a build on e500mc and let you know if that works or not...
<alow> BenC: I know it won't work - check the data in the github issue I linked
<BenC> alow: That data shows e500v2, which is not entirely the same as e500mc, so let me check
<alow> BenC: if the basic floating point hasn't changed between e500mc and e500v2 - then either should work
<BenC> alow: But it has...e500mc has hardware floating point and e500v2 uses softfloat (or mathemu in the kernel)
<alow> BenC: the reason the code doesn't work is that we are generating FPU instructions - and the encoding is entirely different on e500 (mc / v2)
<BenC> alow: I've cloned and started a build. In the meantime can you email me: ben.c@servergy.com and I'll get you ssh access to our RPLE server, which is e500mc/P4080 based.
<BenC> ACTION tools_gyp_v8_gyp_v8_snapshot_target_run_mksnapshot /home/svy/v8ppc/out/ppc.release/obj.target/v8_snapshot/geni/snapshot.cc
<BenC> Illegal instruction
<alow> BenC: yes - expected
<alow> BenC: if you build with "make ppc snapshot=off" it will complete the build.. but crash on startup when it tries to generate FPU instructions into memory and run them (V8 is a JIT)
<BenC> alow: I can give you access to the hardware if you email me an SSH pub key and username
<alow> BenC: drat.. just hit send -- will follow up now with key & name
<BenC> Ah, thanks
<BenC> alow: So the system has chroots. Probably makes no difference which one you use, but we want people to create a schroot env for their builds so we can easily isolate having to install build-deps if needed
<BenC> alow: Instructions on how to use the setup is in the motd when you login
<alow> k - will be a good citizen in that regard
<dobey> kenvandine, robru: is there a way to make friends-service update from twitter more often? also, it seems to never actually pop up notifications on my workstation, but every time i boot my laptop, i get a bunch of notifications from it. :-/
<kenvandine> dobey, you can change the interval in gsettings
<kenvandine> and there is also a setting for notifications
<dobey> kenvandine: yes, notifications is set to "mentions-only"
<dobey> kenvandine: which is what i want, but i don't seem to be getting them.
<dobey> i do on my laptop though of course
<slangasek> seb128: firefox ppc> I have no opinion on this, other than to reiterate that if there are issues with packages on the ports, this needs to be brought to the attention of the porters prior to give them a chance to respond /before/ it becomes a blocking issue for the desktop
<seb128> slangasek, hey, how do I brought attention to the porters? trusty has a firefox which is outdated by 3 versions (and outdated compared to security pockets from other series by almost as much)
<slangasek> seb128: for powerpc, I would say the first stop is to ping infinity about it :)
<seb128> slangasek, it's not like the issue was not visible, it's just that nobody is stepping up to do anything about it, we are past mid-cycle and we got 0 firefox build with the trusty toolchain reaching the release pocket
<seb128> infinity, ping :p
<seb128> slangasek, done ;-)
<seb128> infinity, slangasek: note that firefox "builds", the build fails on a cache generation error after the actual build is done, seeing that the same version works on other series it looks like a toolchain issue (due to the toolchain or to firefox doing wrong thing)
<slangasek> seb128: it's visible /to you/ because you're paying attention to the package; build failure reports from launchpad go to the uploader, not to the porters
<slangasek> so no, it's not fair to assume that a package build failure is "visible" to the porters unless someone lets them know it's blocking them
<seb128> slangasek, right, I'm not especially paying attention, out of the fact that my firefox is outdated by 3 versions
<seb128> slangasek, I wish we had a better way to flag such issues :/
<infinity> seb128: Right, the toolchain pointer is an interesting hint.  It might be a workable workaround to build with an older GCC on ppc for now, though the actual problem should be hunted down.
<infinity> seb128: It might also be an acceptable workaround to drop ffox and its rdeps from PPC for now, but I want to look into the impact of that before I go on a deletion spree.
<seb128> infinity, I've said that before, and thanks for stepping up to provide us solution when that happened, but not having a porter box available doesn't help there
<seb128> how the heck can we support an arch without having access to one box to debug issues?
<infinity> seb128: A porter box is on my Very Soon TODO.  It got pushed back by an externally-imposed ABI break on ppc64el that I have to deal with this week.
<seb128> infinity, that's good news ;-)
<seb128> infinity, anyway, help on the firefox issue is welcome, we don't have a firefox maintainer anymore atm
<seb128> chrisccoulson does what he can on his extra-work-hours time to keep it going
<seb128> but he said several times that he doesn't have the free slots/motivations to deal with "exotic" archs (that includes ppc)
<infinity> Pretty sure, to most people, "exotic" is everything that their home computer isn't. :P
<seb128> lol
<infinity> (It just so happens that my home contains a lot of computers...)
<chrisccoulson> my home computer isn't i386 or arm, but i'm happy to deal with those ;)
<seb128> infinity, it's rather than we have to be given proof that anyone uses firefox on ppc and it's usable there
<infinity> seb128: To be fair, I don't use a desktop on PPC either, mine are all servers.  So, yeah, I'm happy to examine the "just drop the binaries" option, but I want to poke the "why is it broken?" bit first.
<seb128> infinity, thanks
<seb128> infinity, I got that you are busy this week, do you think you can have a look before the end of the month?
<seb128> infinity, I would like to see us publishing a firefox update in trusty before beta time
<infinity> seb128: Yeah, I can commit to having a fix, one way or the other, before beta.
<psusi> cjwatson: quick question... partman-ufs is broken on linux so I got the monolithic image to build once after removing it from pkg-lists/standard-udebs... but this file seems to be auto generated somehow so it keeps getting put back.  how is this?
<infinity> seb128: Although, I'm not seeing the toolchain change argument here, with rmadison output.  Looks like powerpc is missing for precise-updates too.
<infinity> The last version that built on ppc on any series was 25.
<seb128> shrug
<infinity> So, 25->26 deltas and looking for stupid would be my first pass.
<seb128> infinity, sorry, I saw the security/updates going through on other series, I assumed that's because they didn't regresses on archs
<infinity> seb128: Nah, the security team will happily regress unsupported arches if they can't immediately sort out the breakage.
<seb128> I didn't think we pushed through updates that don't build on all supported arches
<seb128> k
<seb128> I learnt something there
<seb128> infinity, anyway, if you can help getting that resolved one way or another that would be appreciated ;-)
 * infinity nods.
<seb128> I'm just chrisccoulson would join in buying you drinks at the next event
<infinity> This whole work-for-drinks thing needs to stop before my liver falls out.
<infinity> I'm staring at a bottle of gin from Carlos, and wondering if it's going to kill me.
<seb128> infinity, can buy you some vegetables if you prefer!
<sarnold> chrisccoulson also runs on steak, would that work? hehe
<infinity> seb128: Steak? :)
<seb128> oh, you said you want french cheese if I remember
<infinity> Steak!
<seb128> that works too ;-)
<infinity> A few kilos of d'Affinois cheese wouldn't go amiss either.
<seb128> hehe
<infinity> In fact, it's nice melted on top of a filet mignon.  Two for one.
<seb128> lol, I see where you a going ;-)
 * seb128 starts wanting some steak
<seb128> infinity, ok, gnome-control-center-signon built, I just deleted the arm64 debs from trusty/trusy-proposed since he can't work there (lack of qt5) and is depwaiting in the current upload
<seb128> infinity, if there is still work needed, after the next run, please do your magic if you can ;-)
<infinity> seb128: Alrighty.
<seb128> thanks
<infinity> seb128: That should have been all the magic required.  Hopefully your deletes didn't misfire and take out anything else this time. :P
 * seb128 hides
<seb128> let's see, I'm confident I'm not going to screw twice in a day ;-)
<infinity> That sentence really needs another word to be significantly less embarassing.
<seb128> screw -> screw up an Ubuntu upload? ;-)
<seb128> see why french should be default, it would be easier!
<stgraber> it'd be a lot less fun ;)
<infinity> seb128: "up" was indeed the missing word. :)
<infinity> seb128: Entirely different meaning without it. :P
<seb128> ;-)
<seb128> I was going for fun, stgraber got it :p
<seb128> anyway, let's see if britney is happy once the arm64 binaries are gone
<infinity> Should be.
<seb128> great
<infinity> Unless something depends on the now-missing binaries.
<infinity> But if so, we should sort that anyway, not ignore it.
<seb128> things depends on those yes
<seb128> but those have never been installable
<infinity> I'm going to go pizza hunting.
<seb128> since they depended on qtdeclarative
<seb128> infinity, if you have internet, or a phone, you can get pizza delivered ... rather than having to hunt for it. Just saying...
<seb128> infinity, enjoy ;-)
<ogra_> seb128, he probably likes the guns ;)
<seb128> ogra_, did he move to Texas? ;-)
<ogra_> maple syrup guns ;)
<jdstrand> seb128: powerpc isn't 'supported' by us in that sense. amd64, i386 and armhf get security support. the other archs are along for the ride (https://wiki.ubuntu.com/SecurityTeam/FAQ#Architectures)
<seb128> jdstrand, yeah, sorry I use "supported" for "existing"
<infinity> jdstrand: Time to update the table for a new release and a new arch. :)
<jdstrand> infinity: yes, a couple of them :)
<jdstrand> oh no, arm64 is already there
<jdstrand> infinity: and thank you for looking into ff/powerpc
<seb128> infinity, \o/ that worked, g-c-c-signon migrated to trusty
<dobey> is it impossible to disable ctrl+super+left/right keybindings?
<seb128> dobey, you tried ccsm?
<dobey> seb128: no, but tried dconf-editor, and don't see them in there. and setting them to a different action didn't help
<seb128> dobey, I'm not sure, I think that's the grid plugin but you might want to ask Townsend when he's online, I think he cleaned that code previous cycle
<infinity> jdstrand: You might want to split that table in two, for historical and current, too.  Then the current one would have fewer arches, and fewer still next year.
<jdstrand> yeah
<jdstrand> I was thinking about that
<miseria> "la verdadera felicidad de un ser humano, se logra cuando deja de ser esclavo, de la avaricia y la codicia" bienvenidos: http://castroruben.com *temo_a_un_ser_sin_rival*
#ubuntu-devel 2014-02-13
<pitti> Good morning
<RAOF> pitti: Yo yo!
<RAOF> pitti: Hey, what does error() do in vala?
<pitti> RAOF: that's g_error() in C (from glib), i. e. print that message to stderr and abort()
<RAOF> Ah, right. Yeah, that's what I though.
<RAOF> Ok, valac just fails at code flow analysis.
<pitti> RAOF: Vala pretty much uses the GLib API without those prefixes, and with proper class.method() notation instead of g_class_method() in C
<pitti> heh, it might not consider error() as a definitive "ends here"
<infinity> "proper".
<RAOF> Indeed it does not consider error() to abort the function.
<pitti> RAOF: I'm not sure whether you can make error() not abort, but I don't think you can
<pitti> RAOF: warning() and critical() can abort() if one wants, but don't by default
<RAOF> Anyway, initialising the string to "" silences the âYou might use this unassigned!â error.
<pitti> that's just a warning, no?
<pitti> (but fixing warnings is appreciated)
<RAOF> It's apparently a fatal error.
<RAOF> Oh, and it's not control-flow failure! It's failure to understand scanf("%ms", &str)
<RAOF> pitti: Enjoy your new pull request.
<Mirv> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Trusty Tahr Alpha 2 released! | Archive: open | 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: Mirv
<Mirv> \o/
<pitti> RAOF: hah, thanks
<pitti> cjwatson: I'd like to seed xorg-lts-transitional as we need it in trusty (only) for upgrading from 12.04.[1-9]
<pitti> cjwatson: is there a clever trick to say "seed all binaries from this source except for these three (the geode driver is in universe), or do we need to manually seed all 253 binary packages?
<pitti> cjwatson: I'd put them into platform/desktop-common, and comment that they should be removed again in trusty+1; does that place sound ok?
<infinity> pitti: A combination of %source and !binary might work, but I'm not sure if germinate is smart enough to reconcile that conflict.
<pitti> infinity: *nod*
<infinity> pitti: Not like it's hard to add the 253 binaries.  Just looks a bit messy.  We'll delete it in 14.10 anyway.
<pitti> cjwatson: ah no, desktop-common gets installed; perhaps supported-hardware-desktop?
<infinity> pitti: supported-hardware-desktop sounds sane.
<pitti> infinity: no, it'd be easy, I was just curious whether %xorg-lts-transitional and !xserver-xorg-video-geode-lts-quantal (and -raring/-saucy) would work
<infinity> pitti: Or just supported, where I already have a 'Transitional packages:' section.
<pitti> infinity: but I guess I could just add it there and see what http://people.canonical.com/~ubuntu-archive/component-mismatches.txt has to say about it
<pitti> infinity: ah, even better
<pitti> infinity: that's not in platform.trusty then, but in ubuntu.trusty?
<infinity> That section is likely incomplete, I only add things when I notice the oops.
<infinity> pitti: ubuntu.trusty, yeah.
<pitti> infinity: ok, committed; I'll check c-m in a bit
<pitti> thanks
<infinity> pitti: I suspect that won't work, but I guess you'll find out.
<pitti> infinity: oh, I think it actually worked
<pitti> it seems I need to ! three more packages which were in main in precise but went to universe in trusty
<pitti> oh, that looks like bad NEWing
<pitti> their original versions were in precise/universe, but the LTS backports went to precise/main
<pitti> RAOF: oha, look what we've got: https://jenkins.qa.ubuntu.com/job/trusty-adt-fsharp/1/?
<pitti> here's to uninstallability
<dholbach> good morning
<spineau> Good morning
<mlankhorst> Hello, world!
<pitti> hey mlankhorst, good morning
<pitti> mlankhorst: so which package in precise sets up that protocol-precise.txt diversion?
<mlankhorst> the lts-* packages
<pitti> I mean, a particular one? xorg-common or something?
<mlankhorst> I guess the preinst for the dummy lts packages need to remove the diversions
<mlankhorst> xserver-common
<pitti> right, xo xserver-common-lts-{q,r,s}?
<pitti> s/xo/so/
<mlankhorst> yeah so I'll make the dummy package remove it. I'm still interested in whether opengl will work afterwards though
<pitti> mlankhorst: would a glxinfo be enough?
<pitti> (even though it's just using the dummy driver, i. e. software rendering?)
<pitti> mlankhorst: i. e. glxinfo | grep <somethign you expect>
<mlankhorst> ldd glxinfo would be enough
<pitti> and ensure that it doesn't contain "not found"?
<pitti> mlankhorst: btw, we do ensure that lightdm and X start up after the upgrade already
<mlankhorst> yeah I guess if glxinfo runs that's fine
<mlankhorst> exit code should b e0
<mlankhorst> and maybe dump the glxinfo.txt for future inspection
<pitti> *nod*
<pitti> mlankhorst: ah bummer, mesa-utils is in universe; so we can't test it on the "main only" upgrade tests (i. e. most of them)
<mlankhorst> as long as it happens at some point :-)
<mlankhorst> or stuff it in a ppa
<pitti> do we have anything in main which tests that?
<mlankhorst> erm probably
<pitti> the unity-check-if-i-am-ok-something thingy?
<mlankhorst> yeah that would be a good way to test opengl
<mlankhorst>  /usr/lib/gnome-session/gnome-session-check-accelerated-helper maybe?
<pitti> there's something similar for unity, if only I could remember its name
<mlankhorst> pitti: yeah can't find if it still exists
<pitti> the thing that creates /tmp/unity_support_test.0
<pitti> /usr/lib/nux/unity_support_test
<mlankhorst> ah right :p
<mlankhorst> but I think gnome-session uses that check anyway
<mlankhorst> oh and please unset LIBGL_ALWAYS_SOFTWARE LIBGL_ALWAYS_INDIRECT before testing
<mlankhorst> hm I guess we are in software mode, just unset LIBGL_ALWAYS_INDIRECT
<pitti> $ DISPLAY=:0 /usr/lib/nux/unity_support_test -p
<pitti> No protocol specified
<pitti> Error: unable to open display
<pitti> hmm
<pitti> that's with the dummy driver
<mlankhorst> shrug
<mlankhorst> making sure something find sthe correct libgl is enough I guess
<pitti> well, I'll keep that in mind, I'm currently looking at other bugs
<mlankhorst> so ldd someGLthing should return /usr/libs/*/mesa/libGL.so.1
<Mirv> hi, my first patch pilot day. could some co-pilot with me a bit, and suggest what's the best way to go forward when I can't upload myself? I tested bug #907640 now and I think it would be ready for an upload.
<ubottu> bug 907640 in unity-2d (Ubuntu Precise) "alt-backtick doesn't work properly" [Medium,Triaged] https://launchpad.net/bugs/907640
<seb128> can somebody britney override the libreoffice autopkgtest failure?
<infinity> seb128: Looking.
<seb128> infinity, thanks
<infinity> seb128: Done.
<seb128> infinity, thanks
 * infinity decides to get some sleep.
<seb128> night!
<pitti> RAOF: reviewed
<OdyX> tkamppeter_: Hi. It'd be nice to have a new release of cups-filters with the upstart fix so that we could fix the PATH_MAX issue.
<pitti> mlankhorst: are you working on the diversion cleanup, or shall I look into that?
<mlankhorst> pitti: sure I'll do it
<pitti> dpkg-divert --remove --package xserver-common-lts-raring --rename --divert /usr/lib/xorg/protocol-precise.txt /usr/lib/xorg/protocol.txt
<pitti> mlankhorst: so something like ^ in the postinst should do
<pitti> mlankhorst: preinst is too early I think, as at that point the diverted protocol.txt still exists
<pitti> i. e. the precise lts-raring package is still installed
<mlankhorst> yeah
<mitya57> slangasek: Can you please remove force-badtest dh-python/1.20131021-1ubuntu2 from your hints? It has been fixed with my last merge.
<mlankhorst> pitti: http://paste.debian.net/81836/ seems to work
<mlankhorst> oops :P
<mlankhorst> nm i need to fix that
<pitti> mlankhorst: lt-nl for robustness?
<mlankhorst> yeah
<pitti> mlankhorst: sh -e is redundant with set -e
<pitti> mlankhorst: why the postrm?
<mlankhorst> yeah that's the bug
<pitti> and please add a bug ref (LP: #1279424)
<ubottu> Launchpad bug 1279424 in xorg-lts-transitional (Ubuntu) "Needs to clean up /usr/lib/xorg/protocol-precise.txt" [Undecided,Triaged] https://launchpad.net/bugs/1279424
<mlankhorst> hm seems to break :P
<rbasak_> Mirv: hi! I'm looking at bug 1264674 for teward (to avoid any duplicate work).
<ubottu> bug 1264674 in nginx (Ubuntu Saucy) "[SRU] nginx segfault when adding add_header in configuration" [Undecided,Triaged] https://launchpad.net/bugs/1264674
<rbasak_> Mirv: to answer your question: I usually wait for another pilot to appear, then jump in :)
<cjwatson> pitti: No such clever trick; the best I can offer is that maybe you can express it more briefly as a regex seed
<pitti> cjwatson: hey
<pitti> cjwatson: it's actually all good now, % and ! work fine
<cjwatson> (You may have got there already, I'm buried in scrollback)
<Mirv> rbasak_: thanks, I had that tab open but I found myself more likely to be able to review xubuntu-docs next, on my first patch pilot turn :)
<cjwatson> pitti: Hmm, ! is a scarily big hammer, I don't promise that that won't result in weirdness in the future
<cjwatson> But OK, I guess we can leave well alone for now ...
<pitti> cjwatson: well, both that seed and the entire xorg-lts-transitional package will be killed at the first day of opening u
<pitti> cjwatson: yeah, if it causes trouble I'm fine with expanding it all out, it'll just be ginormous
 * cjwatson nods
<tkamppeter> OdyX, I am adding features for on-demand starting of cups-browsed (for mobile), after that, today or tomorrow, I will release 1.0.45 which contains the PATH_MAX fix.
<tkamppeter> OdyX, what do you mean with the "upstart fix"?
<mlankhorst> pitti: hm even more fun is if xserver-common-* is installed previously and you upgraded to a different one, then try to install the old xserver-common-lts* after transitioning
<mlankhorst> still finds the old version :P
<pitti> the old version of what?
<pitti> (and yes, downgrades in these scenarios are very likely to blow up)
<OdyX> tkamppeter: http://anonscm.debian.org/gitweb/?p=pkg-cups/cups-filters.git;a=commitdiff;h=54a2ef368311a1f56e0b6cc17d52c8244ceb8cb7 <- that should be in upstream; you requested that I'd include that in the debian packaging.
<mlankhorst> if i install xserver-common-lts-raring before upgrading to xserver-common-lts-saucy, and then switch to lts-saucy and install xserver-common-lts-raring after 'upgrading' to trusty
<mlankhorst> bleh I'll skip the version check and query dpkg-divert directly
<mlankhorst> pkg=$(dpkg-divert --listpackage /usr/lib/xorg/protocol.txt)
<mlankhorst> if [ -n "${pkg}" ]; then
<mlankhorst>     dpkg-divert --remove --package ${pkg} --rename \
<mlankhorst>         --divert /usr/lib/xorg/protocol-precise.txt \
<mlankhorst>         /usr/lib/xorg/protocol.txt
<mlankhorst> fi
<mlankhorst> pitti: http://mblankhorst.nl/etc/xorg-lts-transitional_4.tar.gz -- done
<pitti> mlankhorst: ah, thanks! but shouldn't that still be wrapped in [ "$1" = "configure" ] ?
<Riddell> jdstrand: would the security team object to this patch being in pinentry? http://git.gnupg.org/cgi-bin/gitweb.cgi?p=pinentry.git;a=commit;h=0b3a8568e14b994a8d1f4c1cb42aed4959dfc811
<mlankhorst> pitti: naw
<mlankhorst> doesn't realy matter
<pitti> mlankhorst: ah, I guess so; in postinst there's no way back anyway
<pitti> mlankhorst: thanks! uploaded
<Mirv> I'd have two patch pilot uploads ready for someone who has upload rights https://code.launchpad.net/~timo-jyrinki/metacity/ubuntu_fix_lp907640/+merge/206124 + https://code.launchpad.net/~timo-jyrinki/ubuntu/trusty/xubuntu-docs/14.04.0/+merge/206156
<Mirv> dholbach: ^ if you (or anyone else) has time.
<Mirv> also, any tips on how to handle patch piloting better welcome for the newbie
<Mirv> barry: ^ or you, a co-pilot according to calendar, if you'd have time to help regardless of whether you're doing your turn otherwise today or not :)
<dholbach> Mirv, I need to rush out for a bit now - let me know if they're still unresolved when I get back
<Mirv> sure
<seb128> hum
<seb128> update_excuses still has
<seb128> libreoffice (1:4.2.0~rc4-0ubuntu1 to 1:4.2.0-0ubuntu1)
<seb128> autopkgtest for libreoffice 1:4.2.0-0ubuntu1: FAIL (Jenkins: public, private)
<seb128> Not considered
<seb128> infinity, your override didn't work I guess? (and you are probably sleeping now)
<seb128>  
<seb128> could anyone hint over that issue?
<Laney> the version needs updating
 * Laney does it
<seb128> Laney, thanks
<Laney> why don't we delete this test?
<seb128> Sweetshark, is the issue with those tests in libreoffice/the tests or in the setup running those?
<seb128> Laney, ^
<seb128> Laney, my understanding was that the tests are ok but they keep eating setup limits on disk space and such
<pitti> it seems they time out on copying
<seb128> jibel bumped that timeout but not enough it seems
<cjwatson> I still don't understand why a filesystem copy needs a timeout at all
<cjwatson> mlankhorst: I can reproduce the xorg-server/ppc64el build failure, if you need to test a fix
<mlankhorst>             for (j = i; j < (kdNumInputFds - 1); j++)
<mlankhorst>                 kdInputFds[j] = kdInputFds[j + 1];
<mlankhorst>     for (i = 0; i < kdNumInputFds; i++) {
<mlankhorst> kdInputFds[j < kdNumInputFds - 1] = kdInputFds[j <= kdNumInputFds - 1]; -- which seems correct to me:P
<cjwatson> Maybe assert(kdNumInputFds <= KD_MAX_INPUT_FDS) would help?
<cjwatson> Oh, it's probably only happening on ppc64el because ppc64el just switched to -O3
<cjwatson> So I bet you can reproduce this with -O3 on x86
<mlankhorst> hm I don't see the error though :P
<cjwatson> With -O3?
<mlankhorst> I mean from static analysis
<cjwatson> I'm guessing it can't prove that kdNumInputFds is within bounds?
<cjwatson> That's why I'm suggesting an assert
<cjwatson> I'm guessing though
<mlankhorst> yeah but that should already break on the initial check then
<cjwatson> Which initial check?
<cjwatson> Oh ISWYM
<cjwatson> Oh, but kdNumInputFds is decremented just above the j loop
<cjwatson> ... but that should make it even more sure to be in bounds
<cjwatson> Confusing because http://comments.gmane.org/gmane.comp.freedesktop.xorg.devel/36021 was supposed to fix this but we have that
<cjwatson> I dunno, I definitely suggest trying with -O3 on x86 to see if that shows it as well
<tvoss> doko, around
<tvoss> ?
<mlankhorst> cjwatson: yeah :/
<mlankhorst> cjwatson: seems like a compiler error though? O3 on x86 works
<jdstrand> Riddell: I'm not sure about prior art-- let me ask mdeslaur
<jdstrand> mdeslaur: Riddell asked if we would object to http://git.gnupg.org/cgi-bin/gitweb.cgi?p=pinentry.git;a=commit;h=0b3a8568e14b994a8d1f4c1cb42aed4959dfc811
 * mdeslaur looks
<jdstrand> mdeslaur: this seems like what the gtk pinentry already does based on the description alone
<mdeslaur> jdstrand, Riddell: I wouldn't object at all...the user is choosing to paste a password
<pitti> mlankhorst: :( https://jenkins.qa.ubuntu.com/job/upgrade-ubuntu-precise-trusty-desktop-lts-raring-i386/15/artifact/results/bootstrap.log
<pitti> mlankhorst: at the very bottom
<pitti> mlankhorst: it does get upgraded after xserver-common
<cjwatson> mlankhorst: I don't know then, sorry
<jdstrand> mdeslaur: cool, thanks. seemed like what we have in the gtk version, but I've not looked at it before
<cjwatson> mlankhorst: Do you need access to a porter box to experiment?
<mlankhorst> pitti: huh? weird?
<mlankhorst> cjwatson: is the same compiler used for x86 as ppc64el?
<cjwatson> mlankhorst: The same base, but I think there are IBM patches applied conditionally for ppc64el.  doko would know more
<pitti> mlankhorst: well, the new xorg-common already installs a protocol.txt, maybe that somehow conflicts with that one?
<mlankhorst> pitti: it gets diverted to protocol-precise.txt
<Riddell> thanks mdeslaur, jdstrand
<mlankhorst> pitti: no, that's what dpkg-divert is for
<mlankhorst> besides, the package manager would complain if protocol.txt was overwritten, that's the whole point of the  diversion. :P
<mlankhorst> Hmm...  trying to overwrite '/var/lib/xkb/README.compiled', which is also in package xserver-common-lts-raring 2:1.13.3-0ubuntu6~precise3
<pitti> mlankhorst: right, I just got the same
<mlankhorst> pitti: why did you add --force then?
<pitti> mlankhorst: update-manager does that
<mlankhorst> ok, well that's a bug at least
<pitti> and it tries several times
<pitti> well, we've got a lot of these, so I guess that's update-manager's way to get you out of the swap instead of giving up
<doko> mlankhorst, yes, same compiler
<mlankhorst> xserver-common should have a replaces on xserver-common-lts-*
<mlankhorst> or Conflicts, more likely
<pitti> mlankhorst: Breaks:/Replaces: on (<< 3), yes
<pitti> err, << 3:
<mlankhorst> nah Conflicts is enough, I think
<pitti> no, please not
<mlankhorst> ok
<pitti> that'll only make apt hold back packages
<pitti> Breaks:/Replaces: is the standard declaration for replacing files
<cjwatson> Indeed, Conflicts is wrong and policy explicitly advises against it for moving files between packages
<cjwatson> (with a rationale)
<mlankhorst> well I guess it can only be done 1 way here, original lts-stack had conflicts/replaces/provides because you had to switch both ways
<dholbach> Mirv, I uploaded xubuntu-docs - maybe somebody from the desktop team can upload metacity?
<cjwatson> conflicts/replaces/provides has different semantics, that's for whole packages
<mlankhorst> pitti: I give up and I'll add it as postinst job for xserver-common as well. :P
<mlankhorst> should work with breaks/replaces
<mlankhorst> it doesn't get configured until the broken xserver-commons are gone
<pitti> mlankhorst: why would xserver-common need to clean up the -lts-* diversion?
<mlankhorst> I don't see why the current way would break, unless the --force broke stuff
<Mirv> dholbach: thanks!
<Mirv> didrocks: ^ I see you've done a metacity upload as recently as two years ago, I wonder if you could upload https://code.launchpad.net/~timo-jyrinki/metacity/ubuntu_fix_lp907640/+merge/206124
<Mirv> I can also just mark it as 'ready for upload' in my report
<didrocks> Mirv: you did test the patch, you just need sponsoring?
<Mirv> didrocks: yes, tested in gnome fallback and seems to fix the issue without any regressions I could find
<didrocks> Mirv: ok, sponsoring then :)
<Mirv> thanks! :)
<pitti> yay, I beat wine1.4 to build at last, after only 10 attempts
<didrocks> Mirv: yw (and done!)
<doko> bah, ABI incompatible untested libssh upload
<doko> Riddell, http://launchpadlibrarian.net/166034580/libssh_0.6.1-0ubuntu1_0.6.1-0ubuntu2.diff.gz   is this the right thing to do, and not changing the soname/package name?
<Riddell> doko: is was never compiled with gssapi so those symbols were next in the package, I just happaned to have gssapi installed on my local system when I updated the package
<doko> Riddell, ahh, thanks for the explanation
<Riddell> s/next/never/
<kgunn> mlankhorst: have enough people bothered  you about xorg ppc64el build blocking mir ? :) if so...i'll leave you alone
<Unit193> Bump on https://bugs.launchpad.net/bugs/1060543 attached an example file a while ago.
<ubottu> Launchpad bug 1060543 in software-properties (Ubuntu) "Additional Drivers is not discoverable in Quantal" [Critical,In progress]
<barry> Mirv: i'll try, but i am also working on some critical bugs today :(
<Mirv> barry: thanks, but I now already got d_holbach for the xubuntu-docs and d_idrocks for the metacity
<barry> Mirv: excellent.
<cjwatson> mlankhorst: I think it might be worth just appending -O2 to CFLAGS if you can't track down the root cause of this quickly
<mlankhorst> cjwatson: yeah I'll just try this fix, lets see if it works
<doko> mlankhorst, please open an issue in any case, for 4.8 and the package in question
<seb128> hum
<seb128> xorg builds failed with  libmirclient-dev : Depends: libmirclient7 (= 0.1.5+14.04.20140212-0ubuntu1) but it is not installable
<seb128> I guess the binaries got copied to universe?
 * seb128 promotes
<seb128> same for libmirserver15
<seb128> mlankhorst, ^
<mlankhorst> should I retry? :P
<seb128> need to be retried once the promotion is reflected on the archive
<seb128> no, check with rmadison to see when they are promoted
<seb128> I guess next publish run, so ~45 min
<cjwatson> That would be pretty near the worst case
<cjwatson> Though you did *just* miss the start of a publisher run so I suppose that's possible
<seb128> yeah, I don't know the publisher run times nowadays, I sticked to "run every half an hour and take less than half an hour"
<cjwatson> It tries to run every five minutes and typically takes either ~5min or ~20min depending on whether it needs to publish the devel release pocket or not
<seb128> nice ;-)
<cjwatson> With occasional spikes when it needs to publish something enormous like libreoffice
<cjwatson> (Since the writes to the pool are still in-band)
<seb128> cjwatson, mlankhorst: on the good news, ppc64el built
<seb128> https://launchpad.net/ubuntu/trusty/+source/xorg-server/2:1.15.0-1ubuntu6
<cjwatson> cool
<Mirv> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Trusty Tahr Alpha 2 released! | Archive: open | 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:
<Mirv> almost forgot
<alow> infinity: Any problems with the libv8 stuff when you built all platforms? (including PPC)
<shadeslayer> seb128: in addition to apturl not working, flash install seems to be broken too?
<seb128> shadeslayer, I've no idea about that, ask chrisccoulson maybe
<shadeslayer> chrisccoulson: ^^
<shadeslayer> seb128: any news on the apturl front?
<seb128> shadeslayer, chrisccoulson doesn't like using the other directory, he said that's wrong and that we should fix firefox mimetype handling instead
<chrisccoulson> yeah, it needs somebody to fix the external protocol handling in firefox
<seb128> I've the feeling nobody is going to have slots for that though
<shadeslayer> *nod* I saw that part
<seb128> so I might end up abusing the wrong dir
<seb128> then start hiding from chrisccoulson :p
<shadeslayer> ^^
<shadeslayer> I'd have taken a shot at it, but I have no clue how the external plugin thing works
<cjwatson> mlankhorst: looks like libgcrypt20 is going to need to go to main for xorg-server, which will involve duplication because a bunch of stuff currently uses libgcrypt11; are you looking at upgrading other things to match?
<cjwatson> mlankhorst: and/or whether this all syncs with Debian I guess
<seb128> cjwatson, is it?
<chrisccoulson> i know how it works, but my available time is < 0 at the moment ;)
<cjwatson> is it what?
<seb128> cjwatson, the manual upload should pick back 11
<cjwatson> huh, really?  http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.txt thinks it's 20
<seb128> cjwatson, the CI builds pick happily in universe
<seb128> so I guess the copied version picked 20
<seb128> and the manual upload is going to go back at resolving the main provides
<seb128> which is 11
<seb128> we had the issue last week already :/
<cjwatson> oh, maybe it's just lagged because some arches were blocked on libmirclient or whatever
<seb128> btw builds can me retried it seem
<seb128> s
<cjwatson> 2:1.15.0-1ubuntu5_i386 has libgcrypt20
<seb128> right
<seb128> 5 is the pocket copied version?
<shadeslayer> chrisccoulson: what are the chances that it'll be fixed post Feature Freeze
<cjwatson> er dunno, check the publishinghistory
<seb128> $ dpkg -I xserver-xorg-core_1.15.0-1ubuntu6_i386.deb | grep libgcry
<seb128> ...
<seb128>  libgcrypt11 (>= 1.5.1),
<chrisccoulson> shadeslayer, by me, slim. but maybe somebody will step up who knows how the code works. or maybe upstream will fix it
<shadeslayer> mhmm
<cjwatson> right, ubuntu5 was copied from CI
<seb128> cjwatson, so yeah, xorg Build-Depends on libgcrypt-dev
<Laney> yeah, the CI builds get the universe provider
<seb128> and 11 and 20 provides that
<seb128> and the CI has universe enabled and that leads to pick the wrong one
<cjwatson> if it matters somebody should fix the B-D then
<seb128> archive upload pick the only available one in main and end up on 11
<seb128> right
<seb128> mlankhorst, ^
 * shadeslayer goes back to figuring how to make plugin installation work for Kubuntu
<Laney> I guess it only matters as far as components ...
<rbasak> If a Unix program handles SIGINT and exits, should it return a code of just non-zero (eg. 1), or SIGINT + 2^7?
<rbasak> (so that WIFSIGNALED etc work)
<seb128> chrisccoulson, what's the side effect off installing the apturl config where you don't want it to be?
<chrisccoulson> seb128, it only fixes apturl. it's broken for all external protocols
<chrisccoulson> and hardcoding apt: URI's to apturl is wrong anyway
<chrisccoulson> the default handler is software-centre
<seb128> chrisccoulson, do you have an example of other external protocols? clicking on an email: seems to work?
<chrisccoulson> it's likely that's stored somewhere in your profile from a previous use
<chrisccoulson> i've been told itms: and mms: are broken
<chrisccoulson> and all the weird protocols that totem is meant to handle too
<slangasek> mitya57: dh-python hint dropped, thanks
<mitya57> Thanks!
<mlankhorst> pitti: hey can you recheck with after the latest xorg-server goes into -proposed?
<psusi> cjwatson: ok, that wasn't too bad... I cut out the fs create/check/copy commands from parted_server, linked it against the new libparted, removed the copy operation from the menu, fixed swap formatting to always use mkswap isntead of only as a fallback if parted_server fails... what's the next step?  file bugs with patches to the partman components?  get parted3 uploaded to experimental?
<cjwatson> file bugs with patches in Debian, and let's see how it looks
<psusi> ok
<psusi> testing it though will require parted3, so should that be in experimental?
<cjwatson> honestly I'd rather get the patches into partman and then put parted 3 in unstable
<cjwatson> the partman patches should surely still work against parted 2
<psusi> the one snag with that is that I had to change the linker flags for parted_server and that won't be backwards compatible with the current libparted
<cjwatson> well, let's see the patches for that
<alow> BenC: yesterday you mentioned using schroot's - I've been reading up on this as I haven't used them before. Two things. If I do schroot, I end up in an environment without 'git'. However, my real question is: can I do 'development' in a non schroot environment? (provided I don't need to install packages)
<psusi> ok... it was pretty simple... just had to add a -lparted-fs-resize.. and that apparently required -luuid
<cjwatson> why isn't that done with pkg-config?
<cjwatson> and we could conditionalise that I'm sure
<psusi> there doesn't seem to be a .pc file for the fs resize library
<cjwatson> I mean, I get that we'd need to reupload partman-base against parted 3 eventually
<cjwatson> but I wasn't talking about that bit - I was talking about landing the removal of fs-creation-dependent code first
<psusi> yea... you could do that... just the linker flag would need switched
<cjwatson> sure, that's easily done later :)
<psusi> yea
<psusi> I didn't test hfs, but fat resize seemed to work fine
<cjwatson> but let's start landing what we can do noninvasively now; it always helps to prune down the problem
<chiluk> hey stgraber what are the limits to the number of LXC containers that can reliably operate on a single host?
<stgraber> chiluk: depends on the host, 700-800 system containers (running wordpress as that's apparently the usual test) seem to be the usual limit for a reasonably powerful server these days
<stgraber> chiluk: well, with our default config, that'd be 254 because we only have a /24 for the default network, but that can be changed :)
<chiluk> stgraber, thanks.
<BenC> alow: If you don't need packages installed, you're good. If you do an schroot, though, you can ask me to install git in it :)
<alow> BenC: What's your preference. It doesn't look like I need any packages.
<BenC> alow: It's functionally no different. The schroot just provides us a way of installing packages specific to each user
<alow> BenC: k - got it.
<seb128> cjwatson, mlankhorst: good, mir migrated
<cjwatson> excellent
<cjwatson> kgunn: ^-
<kgunn> cjwatson: thanks guys
<infinity> alow: Nope, all looked good, and for bonus points, it does work on POWER5 as well.
<mlankhorst> huzzah
<alow> infinity: Great. I'm about to head off on vacation, nice to know it's sorted out
<infinity> alow: Ahh, and got your response to my followup.  Lovely.  I'll bounce that to the archive right now, then.
<infinity> alow: And guessing from backscroll that BenC's give you shell on an e500 machine that doesn't suck?
<BenC> infinity: Indeed
<infinity> BenC: Awesome, thanks.
<infinity> BenC: Can I talk you into an SRU kernel rebase while you're being helpful? :)
<BenC> infinity: Sure, why not.
 * BenC needs first coffee though
<infinity> BenC: https://bugs.launchpad.net/ubuntu/+source/linux-ppc/+bug/1276013
<ubottu> Launchpad bug 1276013 in Kernel SRU Workflow "linux-ppc: <version to be filled> -proposed tracker" [Medium,In progress]
<BenC> infinity: How long to EOL on saucy kernel?
<infinity> 13.10 + 9mo.  So, 13.19!
<infinity> (Or 14.07)
<infinity> BenC: So, basically, a couple of SRU cadences after trusty releases, which seems like a sane buffer time to let customers upgrade anyway.
<BenC> infinity: Excellent
<alow> infinity: BenC - yes, that shell account on the e500 is nice. Going to be a bit for me to get the code working, it's non-trivial set of changes - but it's something I'd like to get working.
<BenC> alow: Good to hear. Let me know if I can do anything wrt documentation
<BenC> alow: Next step, I'll give you shell access to my t4240 (Freescale e6500 64-bit SoC, 12 cores, 24 threads) and see if that works :)
<BenC> alow: The only thing I forsee there is it doesn't have an fsqrt function. We fudge it with mathemu in the kernel, but it's not as useful as it sounds
<alow> BenC: the issue I ran into with the e500 machine I was looking at previously was the lack of FPU regs. (it has FPU instructions which re-use the GPRs)
<alow> BenC: I wrote up details in the GitHub issue I've used to track things https://github.com/andrewlow/v8ppc/issues/100
<BenC> alow: That's likely only in the e500v2 system...I'm pretty certain e500mc has fpu regs
<infinity> alow: If you were following along at home, the libv8 upload is here: https://launchpad.net/ubuntu/+source/libv8-3.14/3.14.5.8-5ubuntu1
<alow> BenC: guess I'm off to read some processor manuals
<infinity> alow: And if you were curious about the packaging changes, to see if you did it "right" locally, the diff is http://launchpadlibrarian.net/166207132/libv8-3.14_3.14.5.8-5_3.14.5.8-5ubuntu1.diff.gz
<alow> infinity: sweet. Thanks for your work here.
<infinity> Now to convince ARM to give us an aarch64 port that isn't bleeding_edge...
<alow> infinity: merging backwards in time is in theory the same work as dragging code forward. Mentally less satisfying however.
<infinity> alow: I got a response from a guy at ARM that stated (regarding 3.14): "Most notably at that time V8 used to have hand crafted "slow" code path, today they are generated by the optimising compiler. So to backport, one would have to write all those slow path by hand ..."
<infinity> alow: Is that something you ran into as being a problem?  Did you have some magic to work around that?  Is he full of it? :P
<alow> infinity: yup. We started in 3.14 with the 'slow code' and have been removing some of it as we crawl upstream. However, re-working the upstream code that is 'new' is also work that he is ignoring.
<alow> infinity: I think the motivation to move backwards in time is poor. MongoDb / Node 0.10 are the best motivators.
<infinity> From a distro perspective, Mongo/Node are pretty much the only things we care about.  The only other place V8 is used heavily is embedded in Chrome, and I imagine there's a lot of porting needed to make Chrome happy on a new platform (plus, well, for people targetting server markets initially, who cares?)
<alow> infinity: took about 2.5months effort to go from 3.14 to 3.22. So probably 3 months of work to push bleeding edge back to 3.14.
<infinity> alow: Anyhow, thanks for all your work on this.  We'll see what we can do for that other platform you don't care about. ;)
<alow> infinity: someone just needs to convince IBM to build an ARM server.. then I'm set
<infinity> alow: Hah.  I had some hopes for that when I started seeing Rusty at Linaro Connect, but I'm definitely still not sure what IBM's interest is there, and I'm not sure anyone else knows either.
<alow> BenC: hmm.. looking like that e500mc machine is different enough from the e500v2 that work on one won't help the other. Plus side is that e500mc might be 'easy' to get working
<BenC> alow: I would susect the e500mc work to benefit e500v2 in some way, but I suspected as much.
<alow> infinity: I think the hold-up is waiting for someone else to succeed in the space (arm servers)
<infinity> alow: I think that's what everyone is waiting for.  A whole lot of eggs with no chickens.
<psusi> cjwatson: I noticed there is check_basicfilesystems and check_swap that appear to still be trying to use libparted to check swap, fat16, fat32, and ext2 filesystems... but I don't see an option to actually use this checking on the menu in d-i... was this removed already and that code is just unused cruft?
<alow> BenC: ick - problem #1 was data cache flush - we assume size of 128, when this CPU has 64. I really need to re-write that logic to test the actual hardware and make the size non-static
<alow> BenC: but I've run into at least 1 more instruction not supported: fcfid - and I see a list of unsupported instructions in table 3-1 of http://cache.freescale.com/files/32bit/doc/ref_manual/E500MCRM.pdf
<BenC> alow: We've seen similar problems getting JVM working well on this system
<arges> bdmurray: hola
<bdmurray> arges: hey
<cjwatson> psusi: No, it's not cruft.  All the check.d scripts are run between partman's main display and the point where it asks to confirm changes
<cjwatson> see the partman script in partman-base
<psusi> cjwatson: hrm... it doesn't seem to be... otherwise I should be getting failures since there's no more FILESYSTEM_CHECK method in parted_server...
<psusi> and why would it check all filesystems there?
<cjwatson> Sure is.  You could try sticking set -x in scripts and watching it show up in syslog.
<cjwatson> I'm sorry but I don't have time to explain it further now (childcare)
<cjwatson> Please use set -x and such and trace things through for yourself :)
<cjwatson> Also of course it'll only be checking things under certain conditions
<cjwatson> Like for instance if the fs is being mounted somewhere and not formatted
<psusi> ahhh
<psusi> hrm....
<psusi> well, I think we can do without check_swap, since there's really no such thing as fscking swap ;)
<cjwatson> psusi: sure, I think we generally just reformat swap anyway
<psusi> shouldn't... that would change the uuid
<cjwatson> we handle that
<cjwatson> look at the code
<cjwatson> we dd the uuid out beforehand and then back in
<cjwatson> it's by far the quickest way to get known-good swap
<psusi> hah... not much else in there to be rewriting ;)
<JanC> I suppose it might be necessary for encrypted swap?
<psusi> no?
<cjwatson> no, it's fine
<cjwatson> encrypted swap => ordinary swap on top of encrypted lvm, in practice
<psusi> cjwatson: there are log calls all over the partman code, but I don't see any of it in syslog... is there something you have to do to switch that on?
<cjwatson> log () goes to /var/log/partman
<cjwatson> see partman-base/lib/base.sh
<cjwatson> right, really gone before children disassemble downstairs
<psusi> hehe...
<stgraber> xnox: didn't I bug you about libnih-dbus-dev not depending on libdbus-dev before?
<xnox> stgraber: yeah, and i believe i have fixed it....
<xnox> stgraber: maybe it's not in the archive...
<stgraber> it sure isn't in the archive ;)
<xnox> yeah, unreleased.
<xnox> let me upload it.
<stgraber> thanks
<ogra_> stgraber, oh, so lennart just swallowed lxc into  systemd
<stgraber> ogra_: nah, nspawn has been around for a while, it's just mostly useless :)
<ogra_> ah, heh
<stgraber> it's sort of ok as a thin application container, but Lennart comparing it with LXC is just ridiculous ;)
 * ogra_ still waits for the day he announces that bash is now a systemd part :)
<ogra_> well, just wait til he gets the right ideas ...
<tkamppeter> OdyX, cups-filters 1.0.45 released.
<infinity> stgraber: It doesn't matter if it's comparable to lxc, it'll become the new standard, and you'll like it or else.
<bdmurray> hallyn: there are two uploads of libvirt to the saucy -proposed queue are they the same?
<hallyn> bdmurray: no, the first one has the wrong pocket listed :)
<bdmurray> hallyn: I'm pretty sure it doesn't matter as they'll go to -proposed anyway
<hallyn> bdmurray: oh.  i thought -updates might break something
#ubuntu-devel 2014-02-14
<psusi> xnox, doko, since you guys have touched it recently, I thought I would ask you... libboost seems to have a file, /usr/bin/quickbook... it moved from liboost-tools-dev to libboost-dev between liboost 1.53 and 1.54, which makes libboost1.54-dev have an undeclared conflicts with libboost1.53-tools-dev... why did this file move between binary packages?
<nvrpunk> quick question, is tahr fairly usable?
<xnox> psusi: due to multiarch.
<xnox> psusi: in trusty, we have boost 54 (default) and 55 (available in universe) and they should be all fine.
<xnox> psusi: ditto conflicts / replaces. Where are you spotting 1.53 / 1.54 conflict?
<xnox> psusi: also boost-dev packages are not co-installable per se....
<sarnold> if boost-dev packages aren't co-installable, why offer both 54 and 55?
<psusi> xnox, yea...  I see they are set to conflict with each other but due to the change of package, 1.54 needs a Conflicts: libboost1.53-tools-dev... I saw someone asking about it on askubuntu, and there are a few upgrade failure bugs in launchpad
<psusi> sarnold, in case you need the old one to build something.. it's there... you just have to remove the new one
<jrwren> i've no idea why you would need an older version though. AFAIK boost is great at backward source compat
<ScottK> It is better than it used to be.
<nvrpunk> so my gnome-terminal's transparency is not working, what should I check?
<semiosis> nvrpunk: use kde
 * semiosis ducks
<Unit193> Use #ubuntu ?
<semiosis> nvrpunk: but seriously, as much as i love kde, this is probably teh wrong channel for that kind of question.
<semiosis> as Unit193 points out :)
<sarnold> it might be alright if it is busted in trusty...
<semiosis> truth
<Unit193> *Generally*, trusty would be in #ubuntu+1 though.
<sarnold> heh never seen that one before..
<nvrpunk> im using Ubuntu Gnome Trusty Tahr
<nvrpunk> so how is this the wrong channel?
<xnox> sarnold: why offer both -> because that's easier then black-listing from debian.
<xnox> sarnold: and actualy libboost runtime library packages are co-installable.
<sarnold> xnox: that's a good answer :) hehe
<sarnold> I haven't looked enough at boost but I'm surprised there's much 'runtime library'
<xnox> sarnold: a good chunk of boost are templates, but a whole-load of it are shared libraries that one links against.
<TheMuso> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Trusty Tahr Alpha 2 released! | Archive: open | 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: TheMuso
<TheMuso> Unit193: Where can I find a tarball for https://code.launchpad.net/~unit193/xfce4-panel/snapshot/+merge/206173?
<Unit193> TheMuso: Right, sorry about that.  https://launchpad.net/~unit193/+archive/staging/+sourcepub/3912036/+listing-archive-extra
<TheMuso> Unit193: Thanks, please put a pointer to the tarball if its a snapshot in the merge proposal in future.
<Unit193> Sure, not used to bzr merges so wasn't really sure what to do there.
<TheMuso> Understandable.
<Unit193> (FWIW, xfce4-indicator-plugin is there too.)
<TheMuso> Unit193: Yeah, I saw it, I'm doing them together.
<Unit193> TheMuso: Just to be clear, that's preferred over dsc files?
<TheMuso> Unit193: Yeah, thanks.
<Devastator> can I ping a maintainer or is it considered disrespect?
<Devastator> I would like to discuss an idea on IRC before going any further, so I thought discussing here would be better than e-mails etc as it is all informal for now
<RAOF> Devastator: Pinging is generally fine.
<Devastator> RAOF do you know which approach StÃ©phane Graber likes?
<RAOF> If he's here I'm sure he'd be fine with a ping. stgraber?
<Devastator> his idle says almost 4:30 hours, so probably not :)
<Unit193> Devastator: Already been a couple pings, may as well ask now (in a highlight, and he may well see it.
<Devastator> Unit193 alright, thanks, I'm assuming pasting links which may be from debian is ok also?!
<sarnold> yes
<Devastator> thanks!
<Devastator> stgraber hi, I've seen that you are ubuntu's ifupdown maintainer and I want to add something that can be perhaps useful. Currently ifupdown exports IF_ environment variables to be used in if-pre-up.d, if-up.d, if-down.d and if-post-down.d, but it doesn't distinguish each parameter per interface, example: everytime one interface goes up it exports IF_ADDRESS, IF_NETMASK and others, what
<Devastator> I'm proposing is adding interface logical name to it, like IF_eth0_ADDRESS, IF_eth1_ADDRESS, IF_eth0_NETMASK, IF_eth1_NETMASK and so on as this could be useful for using in shellscripts for advanced configurations. I must say I'm not currently using ubuntu but I'm willing to try it if you think this can be added
<sarnold> Devastator: you were cut off at "others, what" in your first message
<Devastator> thanks
<Devastator> stgraber what I'm proposing is adding interface logical name to it, like IF_eth0_ADDRESS, IF_eth1_ADDRESS, IF_eth0_NETMASK, IF_eth1_NETMASK and so on as this could be useful for using in shellscripts for advanced configurations. I must say I'm not currently using ubuntu but I'm willing to try it if you think this can be added
<Devastator> stgraber I give you a pastebin of what ifupdown exports currently: http://codepad.org/pksia5AW and here is the wishlist bug I posted in debian's BTS which contains the piece of code I tried to edit and failed miserably: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=737749
<ubottu> Debian bug 737749 in ifupdown "Add interface name to IF_ environment variable" [Wishlist,Open]
<psusi> Devastator, that would make it _less_ usable... if you want to know what iface you are being run for that is what the IFACE variable is for
<Devastator> psusi yes, but how to check if IF_ADDRESS=1.2.3.4 is from IFACE=eth0 for example?
<Unit193> TheMuso: Thanks muchly!
<TheMuso> Unit193: You're welcome, please keep in mind the pointers I made both on IRC, and in the comments for the indicator plugin.
<Unit193> Indeed.
<Devastator> also, if you guys don't mind me asking, are there plans to replace ifupdown altogether?
<Devastator> psusi also, could you please explain why you think it would make less usable?
<psusi> Devastator, with an if statement of course
<psusi> Devastator, it would make it less usable because you couldn't write a script without knowing the name of the iface
<Devastator> psusi I'm not trying to replace IFACE with IF_<iface name>_ADDRESS etc, I want to keep IFACE
<Devastator> psusi did you take a look at the pastebin also?
<Devastator> psusi also, I'm not saying you are wrong, just trying to understand
<Devastator> if you possible, give me an example of the if
<psusi> Devastator, if [ $IFACE = eth0]
<Devastator> psusi does it matter if $IFACE is exported after $IF_ADDRESS?
<psusi> no
<Devastator> will do some tests
<psusi> Devastator, generally speaking, the script shouldn't *care* what interface it is being used with
<Devastator> psusi I'm trying to come up with a multiwan failover solution without having to hardcode things, the if works, now I have to make some kind of array to store $IFACE from each interface, then get each $IF_ADDRESS, but I think it will work
<psusi> Devastator, I think you're going about it all the wrong way.. I'm pretty sure those scripts aren't called when an interface fails... only when you manually ifdown
<Devastator> psusi I don't think I follow you, are you saying it's not a good idea to use if-up.d scripts?
<Devastator> psusi I really have to get some rest, can we continue this talk at perhaps.. 11:00 UTC?! my TZ is UTC-2 by the way
<psusi> Devastator, yes, that is not a use case for if-up.d scripts
<TheMuso> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Trusty Tahr Alpha 2 released! | Archive: open | 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:
<pitti> Good morning
<pitti> mlankhorst: they auto-ran; yay, they all succeed now! https://jenkins.qa.ubuntu.com/view/Upgrade/?
<pitti> mlankhorst: that is, ubuntu-precise-trusty-*-lts-*
<dholbach> good morning
<YokoZar> pitti: Not to poo-poo you for fixing wine1.4, but I'd rather you just delete it
<pitti> YokoZar: ah, I wanted to ask you yesterday, but you weren't online
<YokoZar> https://bugs.launchpad.net/ubuntu/+source/wine1.4/+bug/1218645
<ubottu> Launchpad bug 1218645 in wine1.4 (Ubuntu) "Migrate to wine1.6 and remove old wine things from archive" [Wishlist,Triaged]
<pitti> YokoZar: I actually already uploaded it yesterday, but the upload somehow wasn't accepted
<pitti> YokoZar: right, Debian has 1.6, I wondered whether we want to upgrade
<YokoZar> We have 1.6 too
<YokoZar> now
<YokoZar> I wanted to upgrade 2 releases ago
<pitti> YokoZar: I just got the FTBFS when I did the libgphoto transition, and then felt obliged to spend the two hours to fixing the build and finishing the transition
<YokoZar> It never got into saucy due to being uploaded like 2 minutes after feature freeze
<pitti> hm, I cant' see wine 1.6 in trusty
<YokoZar> wait, what
<pitti> not in https://launchpad.net/ubuntu/trusty/+queue?queue_state=0 either
<pitti> wine1.6 | 1:1.6.1-0ubuntu4 | trusty-proposed/universe | source, amd64, i386
<pitti> ooh
<pitti> they just didn't propagate yet
<pitti> wine1.6/amd64 unsatisfiable Depends: wine1.6-i386 (= 1:1.6.1-0ubuntu4)
<pitti> yeah, that looks wrong
<YokoZar> oh right
<pitti> I thought in the times of multi-arch we wouldn't need those -i386/-amd64 packages at all any more
<YokoZar> didn't we have to do something manual for wine1.4
<pitti> you can just apt-get install wine and would get wine:i386
<YokoZar> The issue is that wine on amd64 needs BOTH the i386 and amd64 guys
<YokoZar> and there's no way to do arch-specific depends
<YokoZar> so instead you have to make a package that's only satisfiable as a foreign depends
<pitti> ah, so wine: is arch: all, depends: wine-bin
<pitti> and wine-bin is M-A: foreign?
<YokoZar> Yeah
<YokoZar> To be more specific, wine is a metapackage depending on wine1.6, which in turn depends on wine1.6-i386 or (both wine1.6-i386 and wine1.6-amd64)
<YokoZar> and wine1.6 isn't arch-all but is defined for specific arches (cause the dependencies change based on the arch)
<YokoZar> I seem to remember there being some sort of "ignore wine's unsatisfiable cross-arch depends" thing in the proposed migration for wine1.4.  Or maybe it was just manually approved each time.
<pitti> YokoZar: ah, indeed skype is similar; skype is amd64, depending on skype-bin which is i386 only and M-A: foreign
<pitti> IIRC slangasek set that up, so I take that as "official reference to do it right" :)
<YokoZar> Yup.  I'm somewhat proud of it being so coherent (and Wine using just about every edge case of apt there is)
<pitti> YokoZar: oh, and now the wine1.4 builds got rejected because they are older than the transitional ones in -proposed
<pitti> so I guess that was in vain
<YokoZar> hah, so I suppose you would have discovered wine1.6 that way :p
<pitti> so, TBH I don't know why britney complains about it
<pitti> infinity: do you have an idea about "wine1.6/amd64 unsatisfiable Depends: wine1.6-i386 (= 1:1.6.1-0ubuntu4)" in britney?
<pitti> wine1.6-i386 is already M-A: foreign
<infinity> pitti: Yeah, we need a fauxpkg setup for it.  britney doesn't do cross-arch deps.
<infinity> pitti: I'll sort it in the morning when I'm more awake.  Or ask cjwatson, he knows what's up.
 * pitti tries to make an halfway intelligent face about "fauxpkg"
<infinity> pitti: See fauxpkg/FauxPackages in britney1 source.
<infinity> YokoZar: Bug me about it in the morning if no one's fixed it before.  I'm sleeping in about 3 minutes.
<pitti> infinity: I just got a bug report against langpack-locales; do we actually build locales from eglibc now? eglibc has it in it's Binary: list, but our locales still comes from langpack-locales
<pitti> infinity: (feel free to answer after you wake up again, not urgent at all)
<YokoZar> pitti: infinity: thank you both
<OdyX> tkamppeter_: yay, thanks.
<mlankhorst> pitti: not yet, xrandr needs a tes ttoo
<mlankhorst> test that ls /usr/bin/xrandr* == /usr/bin/xrandr
<mlankhorst> I forgot about that diversion
<pitti> mlankhorst: would you mind describing that in https://bugs.launchpad.net/auto-upgrade-testing/+filebug ?
<pitti> (hunting down two other failures ATM, brain stack is full)
<mlankhorst> pitti: upload https://mblankhorst.nl/etc/xorg-lts-transitional_5.tar.gz and then https://bugs.launchpad.net/ubuntu/+source/x11-xserver-utils/+bug/1280155 should be fixed for the packages in ubuntu
<ubottu> Launchpad bug 1280155 in xorg-lts-transitional (Ubuntu) "test for /usr/bin/xrandr when upgrading from lts" [Undecided,New]
<pitti> mlankhorst: uploaded, thanks!
<zyga> hey, daily update left my system with this:
<zyga> apt-get: error while loading shared libraries: libgcc_s.so.1: cannot open shared object file: No such file or directory
<zyga> I didn't reboot but I cannot launch most things
<zyga> doko: ^^
<zyga> help please :-)
<zyga> ara: what a day ;)
<ara> zyga, what happened?
<pitti> urhg, indeed
<doko> zyga, I see
<zyga> ara: libgcc_s.so.1: cannot open shared object file
<pitti> this just caused a gazillion autopkgtset failures, too
<zyga> ara: don't upgrade for a moment
<doko> arghh, and it did migrate already ...
<pitti> jibel: hm, given that this broke pretty much every autopkgtest, any idea why this wasn't held back?
<zyga> ara: (earlier I had lots of kernel fc*ups, wired networking didn't work and other funny things)
<seb128> an we delete the binaries before they get downloaded?
<seb128> can*
<pitti> oh, I guess they only started failing after the promotion of whatever caused that
<doko> zyga, quick fix: install the old libgcc1
<doko> if you have it in the cache
<seb128> doko, can you get #is to block the download of the buggy binaries?
<zyga> I only have libgcc1_1%3a4.9-20140213-0ubuntu1_amd64.deb
<pitti> hmm, gcc-4.8 was uploaded two days ago already
<doko> trying ...
 * zyga checks if apt-cacher-ng has it
<pitti> zyga: you can get older ones from https://launchpad.net/ubuntu/+source/gcc-4.8/<version>
<Laney> why did that only just happen?
<pitti> is that really libgcc1?
<pitti> it must have been something which just propagated an hour or so ago
<zyga> pitti: I may have it in apt-cacher-ng
<Laney> yeah
<doko> pitti: now built from gccgo-4.9
<pitti> ah
<doko> but empty package. messed up the testing
<pitti> and gccgo-4.9 doesn't trigger any autopkgtests, so it wasn't caught by those until after it promoted
<pitti> ok, that at least explains the mysteries
<pitti> doko: i. e. is it meant to build from gccgo-4.9, or was that an oversight? In the latter case, we'd need a version downgrade, i. e. update gcc-4.8 to 4.9+really4.8.. or so?
<doko> pitti, it is meant to
<pitti> doko: ok, that at least simplifies the versioning problem
<doko> but the quick fix is to download the previous version and just dpkg -i it
<pitti> wget http://archive.ubuntu.com/ubuntu/pool/main/g/gcc-4.8/libgcc1_4.8.2-15ubuntu3_amd64.deb
<pitti> sudo dpkg -i libgcc1_4.8.2-15ubuntu3_amd64.deb
<pitti> zyga:  ^
<zyga> ok, thank god I had apt-cacher-ng with the older copy :)
<zyga> already fixed, I also installed the i386 version for parity
<Laney> hmmmmmmm
<pitti> the teutonic mirror is behind by half a day or so, seems that rescued me
<Laney> I ended up with /var/lib/spamassassin being root:root rather than debian-spamd:debian-spamd
<cjwatson> And of course this means all trusty builds are failing too
<Laney> which broke my upgrade due to the new sa-compile thingy
<Laney> does anybody else have it with these permissions?
<cjwatson> /usr/bin/apt-cache exit status 32512
<pitti> i. e. including the upcoming gccgo4.9 fix, yay
<cjwatson> We can probably work around that with the bootstrap archive somehow
<pitti> cjwatson: could we temporarily disable the dist-upgrade of the build chroots for that?
<pitti> I take it the chroots are usually a few days or even weeks old
<seb128> can we get the binaries blocked from download on the server?
<seb128> save users and the chroots :p
<seb128> oh, cjwatson just pinged #is a bit more, thanks
<cjwatson> pitti: it's easier to prod it in the bootstrap archive; fiddling with the build chroots will require infinity to wake up
<pitti> ack
<tvoss> doko, around?
<pitti> tvoss: not now, please : )
<pitti> tvoss: trusty is on fire, nobody disturb doko for a while
<tvoss> pitti, ack
<zyga> was I the first person affected that came here/
<cjwatson> I don't understand why autopkgtest didn't save us from this
<cjwatson> I: [Fri Feb 14 09:42:55 2014] - Requested autopkgtest for apt_0.9.15.2ubuntu1 (NEW gccgo-4.9 1:4.9-20140213-0ubuntu1)
<cjwatson> [lots of more things along the same lines]
<cjwatson> final: gccgo-4.9,ubuntu-keyboard
<pitti> cjwatson: yeah, we got a bazillion failures
<zyga> cjwatson: this is like backup, the first time we know the backup failed, the second time we check if backups can also restore
<cjwatson> zyga: please can I not have the smart commentary just now? :)
<zyga> cjwatson: sorry
 * zyga goes away
<pitti> cjwatson: gccgo4.9 doesn't have direct rdepends that have autopkgtests apparently, but it should have caught the libgcc1 binary for sure
<cjwatson> jibel: could you have a look at why adt-britney apparently said everything was just fine when we'd just triggered a load of autopkgtests for gccgo-4.9 and they hadn't come back yet?
<cjwatson> pitti: the above log entry shows that it definitely felt it necessary to trigger them
<pitti> cjwatson: ok
<pitti> yeah, I noticed that several times, britney waving through uploads before tests finished
<jibel> cjwatson, looking
<cjwatson> I'm going to disable the publisher while I figure this out; don't tell anyone but I think I might be able to manage to wind this back as an emergency measure
<cjwatson> 10:45 <cjwatson> doko: so, I'm going to remove gccgo-4.9 from trusty, copy gcc-4.8 back over it (which should be permitted, and should restore libgcc1), rerun the publisher, then hopefully we can build the new gccgo-4.9
<cjwatson> oops, echan, but never mind
<cjwatson> Downloads should be disabled where possible
<cjwatson> pitti: I think you can retry those autopkgtest failures now
<pitti> cjwatson: thanks; our internal mirror (tachash) still gives the bad deb, I asked in #ci a while ago about purging it
<cjwatson> it should be sufficient to just sync it now
<cjwatson> current indices have libgcc 4.8.mumble instead
<pitti> I'll just try
<pitti> yay, works now
 * pitti gives our machines something to chew on then
<pitti> doko, cjwatson: many thanks for your swift handling of this!
<cjwatson> I'm going to do an automated search for affected failed builds
<cjwatson> (once I write it)
<jibel> pitti, autopkgtest in the lab use ftpmaster and should have the right deb
<cjwatson> OK, walking through all recent builder history now searching for "/usr/bin/apt-cache exit status", will take a while
<cjwatson> of course chances of getting answers quickly out of wildcherry right now ...
<cjwatson> wgrant: I guess the POST rule applies with the API too?  so my first retry() -> everything after on wildcherry
<wgrant> cjwatson: All API requests go straight to the master
<cjwatson> ah ok
<wgrant> But the API is mostly performing OK at the moment.
<zbenjamin> cjwatson: i was reading in the ML and the link you gave me. But where can i find details on where i put the different binaries for the different archs? like the armhf binaries, the x86 binaries and so on
<cjwatson> zbenjamin: that's not up to click
<cjwatson> zbenjamin: it's for the SDK and tools such as upstart-app-launch to define how packages are laid out internally
<cjwatson> zbenjamin: tedg might be able to advise on current standards
<zbenjamin> cjwatson: thx i'll ask him
<jibel> cjwatson, what I found so far, gccgo triggered an autopkgtest for 54 packages, status has been set to running for these packages and collected by britney but gccgo has not been removed from upgrade_me, it passed the upgrade test and has been copied. What is unclear yet is why gccgo has not been removed while tests of dependant packages were running.
<cjwatson> jibel: hopefully that much will clear out soonish, a fixed gccgo-4.9 is building
<cjwatson> oh, but you mean for why it didn't block initially
<jibel> cjwatson, yes, for why it didn't block initially, I'm in britney.py
<pitti> jibel: beer o'clock!
<pitti> http://d-jenkins.ubuntu-ci:8080/view/Upgrade/
<pitti> ugh, at least the wrestling this week was useful :)
<jibel> pitti, 38 profiles, all green \o/ time to add more tests
<seb128> pitti, hum, are you sure you want to hand beer to jibel while he's working on britney.py? ;-)
<pitti> seb128: I'll buy him one next week
<pitti> I pestered him all week with questions about how stuff works
<seb128> oh, you guys have a team gathering coming
<seb128> enjoy it!
<pitti> yeah, Oakland, will fly out tomorrow
<pitti> seb128: merci !
<pitti> jibel: more tests> for sure, but nice to have a stable base line now
<Laney> more Oakland, lucky pitti ;-)
<cjwatson> jibel: hopefully you're about to get it again; accepted the fixed gccgo-4.9
<cjwatson> though armhf is still building so maybe it'll block anyway
<cjwatson> All libgcc-affected failed builds retried, I believe
<spineau> doko: hello, to build checkbox-gui for ubuntu we're a bit blocked by two dependencies waiting to be promoted to the main archive: bug 1277408 and bug 1278822, could you please help us?
<ubottu> bug 1277408 in checkbox-ng (Ubuntu) "[MIR] checkbox-ng" [Undecided,Fix committed] https://launchpad.net/bugs/1277408
<ubottu> bug 1278822 in plainbox-provider-checkbox (Ubuntu) "[MIR] plainbox-provider-checkbox" [Undecided,Fix committed] https://launchpad.net/bugs/1278822
<doko> spineau, not yet seen in http://people.canonical.com/~ubuntu-archive/component-mismatches.svg
<spineau> doko: I think it's because we're still in -proposed
<spineau> roadmr: ^
<doko> http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg
<roadmr> spineau, doko: I see, I fixed the stuff that was keeping checkbox in proposed (dep-wait) so it should make it out, will it appear in component-mismatches once this happens?
<doko> roadmr, yes, it should
<roadmr> spineau, doko: OK then, upload coming up in a second
<spineau> roadmr: doko: perfect, thanks
<shadeslayer> ev: ping
<shadeslayer> pitti: can Kubuntu also utilize https://jenkins.qa.ubuntu.com/view/Upgrade/ ?
<pitti> shadeslayer: yes, I don't see why not
<shadeslayer> yay :)
<shadeslayer> pitti: I'll have a look at how to write a test case and send MR's
<pitti> shadeslayer: it's primarily about defining a new scenario
<pitti> shadeslayer: i. e. something like s/ubuntu-desktop/kubuntu-desktop/ and enabling universe
<shadeslayer> I see
<jpds> stgraber: Have you seen this? https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1280050
<ubottu> Launchpad bug 1280050 in samba (Ubuntu) "libsmbd_base.so.0 missing symlink?" [Undecided,New]
<pitti> shadeslayer: the scenarios in lp:auto-upgrade-testing are outdated, we are actually using a branch from jibel, hang on
<shadeslayer> pitti: I think there are 2 upgrade paths we want to check : regular 13.10 to 14.04 and 13.10 + LTS Stack + Kubuntu backports to 14.04
<stgraber> jpds: nope, I haven't. Though to be faire, I'm not maintaining samba, I only patched the few bits I needed to get my use case covered (AD domain controller) :)
<jpds> Ah, right.
<stgraber> jpds: I believe the server team are the ones actually maintaining our delta, anything else should probably go straight to Debian
<rbasak> infinity: do you think it appropriate/could you sync cyrus-sasl2, please? Looks like a host of bugs have been fixed recently there. It's not in testing yet though.
<rbasak> (and it's a new upstream release, too, which looks minor, but the changelog suggests that it isn't)
<jibel> shadeslayer, I think I've already a profile for Kubuntu 13.10->14.04.
<jibel> shadeslayer, What is 13.10 + LTS stack?
<pitti> shadeslayer: this one: https://code.launchpad.net/~jibel/+junk/auto-upgrade-testing_profiles
<pitti> shadeslayer: I think the 12.04+LTS stack scenarios are already well-handled; is there anything Kubuntu specific in them?
<shadeslayer> jibel: whoops, I meant 12.04 + HWE
<pitti> oh yes, http://bazaar.launchpad.net/~jibel/+junk/auto-upgrade-testing_profiles/files/head:/kubuntu/
<Devastatr> stgraber good afternoon (or probably evening), did you happen to see the message I leave here?
<shadeslayer> pitti: well, we backport KDE releases to our PPA, and alot of users add that ppa
<shadeslayer> so I think it's useful to have that tested
<pitti> ah, yes
<jibel> shadeslayer, ah okay as pitti said LTS+HWE is already covered, we could do 12.04 + Kubuntu backport
<shadeslayer> sure, fine with me
<zbenjamin> tedg: ping
<tedg> zbenjamin, Howdy
<zbenjamin> hey
<zbenjamin> tedg: i got pointed to you by jdstrand i think, because i was asking about how a fat click package should look like internally and how it will work with the desktop files EXEC property
<zbenjamin> i'm working on the qtcreator ubuntu plugin and we would like to integrate fat packaging :)
<tedg> zbenjamin, Yup, so what we're doing is adding an arch dependent directory to the path.  So that way you can put an executable name in the Exec line and it'll find the arch dependent one.
<zbenjamin> tedg: ok but do i need a own desktop file per architecture in the package then?
<tedg> zbenjamin, Nope, so the desktop file can have "Exec=foo-bar" and the package would have a $(dir)/lib/$(arch)/bin/foo-bar for each arch.
<stgraber> Devastatr: I did. I'm not necessarily against extending the script environment though I'm not going to diverge from Debian either, so if Andrew (the Debian maintainer) does those changes, I'll include them in Ubuntu but I don't want Ubuntu to suddenly become incompatible with Debian for those scripts.
<zbenjamin> tedg: ok and the path will be set correctly so it will be found
<tedg> zbenjamin, Yup, for some examples there are the exec-test* file in the tests directory here: http://bazaar.launchpad.net/~indicator-applet-developers/upstart-app-launch/trunk.14.04/files/head:/tests/
<zbenjamin> tedg: and for things like : Exec=qmlscene $@ -I ./lib/arm-linux-gnueabihf/qt5/qml   share/qml/cmake1/cmake1.qml
<Devastatr> stgraber I understand that and I agree, when you have some time, can you ping me? I want to discuss if I wanted to design something to replace ifupdown, together with you and Andrew, where to start
<tedg> zbenjamin, We're also setting the QML2_IMPORT_PATH to be $(dir)/lib/$(arch)
<zbenjamin> tedg: do you have any docs on which directories have to be where?
<tedg> zbenjamin, Uhm, not really.  Not really sure where that belongs.
<zbenjamin> tedg: ok so lets recap, i put a arch into the manifest , lets say armhf, then click wants to have executables in APP_DIR/bin/armhf  and libs in APP_DIR/lib/armhf
<zbenjamin> or is it arm-linux-gnueabihf
<tedg> zbenjamin, It's the triplet, and not /bin, but /lib/$arch/bin
<zbenjamin> tedg: or maybe you could point me to the code that sets up the env
<tedg> zbenjamin, Sure, I'm not sure that's as helpful as the tests are though.  http://bazaar.launchpad.net/~indicator-applet-developers/upstart-app-launch/trunk.14.04/view/head:/exec-line-exec.c#L62
<zbenjamin> tedg: thanks , if i have more questions i'll come back to you :)
<tedg> zbenjamin, No problem, good to see this getting into the plugin!
<zbenjamin> tedg: yeah, we have a _lot_ of things to get in there ;)
<tedg> zbenjamin, BTW, are you guys also adding support for custom URLs (or is that on the TODO list)?
<zbenjamin> custom urls? that i don't know about, bzoltan is my mentor so he should know more
<hallyn> bdmurray: hi, so regarding bug 1228977.  I was waiting for sdague to post a test case so I could do the SRU justification
<ubottu> bug 1228977 in libvirt (Ubuntu Saucy) "n-cpu seems to crash when running with libvirt 1.1.1 from ubuntu cloud archive" [High,Triaged] https://launchpad.net/bugs/1228977
<hallyn> bdmurray: however, the candidate package I pushed is broader, taking the whole upstream "-stable" series for that libvirt version.  I wasn't sure if that should be handled specially
<hallyn> (it took some time to reconsile the upstream patchset with the individually-applied CVE patches in our tree)
<hallyn> normally, I would say that if the bug submitter can't be bothered to give a test reproduction s cript, let's just drop the patch and close the bug, but
<hallyn> since this is a whole -stable patchset I'd prefer to test for new regressions and call it good
<bdmurray> hallyn: I hadn't actually looked at the diff yesterday, just the bug.
<hallyn> bdmurray: if my reasoning about the -stable patchset is legitimate i can put that in teh bug comment.  otherwise, i'll ping the bug submitter oen more time for a test case, and we can drop teh set and close the bug next week if we dont' get it
<bdmurray> using the -stable patchset seems more like a micro release to me than a standard SRU
<hallyn> bdmurray: if saucy was going to be around longer i'd pursue that.  unfortunately there is an upstream libvirt -stable tree for saucy, but not (other than the one i maintain :) for precise
<ev> shadeslayer: pong
<shadeslayer> ev: Kubuntu has started reporting crashes to errors.ubuntu.com but our backtraces usually end in KCrash ( the KDE Crash handling framework ) , would daisy interpret the crashes as crashes in KCrash or will it be able to parse the stack correctly? ( see ref : https://trello.com/c/u9KpFFxF )
<ev> shadeslayer: what do you mean by "our backtraces usually end in KCrash"?
<ev> oh
<shadeslayer> ev: KDE Software :)
<ev> shadeslayer: that's pretty easy to test. Just kill -SEGV a KDE process and see what's in the executablepath and package fields
<ev> in the resulting crash report
<shadeslayer> ev: but my question is whether daisy will interpret all crashes as crashes in KCrash?
<ev> shadeslayer: right, and I'm saying the way to find out is by looking at the resulting crash report after killing a process with sigsegv
<shadeslayer> ev: and what am I looking for?
<ev> shadeslayer: the Package field and the ExecutablePath field
<shadeslayer> ev: grep doesn't say anything
<shadeslayer> Bunch of jumbled text
<ev> shadeslayer: can you pastebin the resulting .crash file?
<shadeslayer> sure
<shadeslayer> ev: http://paste.ubuntu.com/6932266/
<shadeslayer> ev: really really large file :P
<ev> shadeslayer: looks right to me: ExecutablePath: /usr/bin/kate
<Laney> shadeslayer: you do have Package and ExecutablePath in there
<ev> you wont get Package until you actually run apport-kde over it
<ev> err so you do :)
<shadeslayer> ev: Laney yeah it's weird, grep didn't return anything
 * Laney suspects PEBCAK :P
<shadeslayer> http://paste.ubuntu.com/6932302/
<shadeslayer> ev: anyway, so it'll be fine even though backtrace has KCrash in it?
<ev> shadeslayer: ja
<shadeslayer> cool :)
<u-foka> Hy, I've tryed to install trusty using the latest daily-live image dd-d over an usb key but it refuses to boot :(
<u-foka> is anyone here?
<sarnold> a few hundred :) normally IRC works best if you've got something concrete.. an error message or something similar
<u-foka> sorry I have only the fact that my bios immediatelly returns to the device selection mennu when I select the pendriver and hit enter :/
<u-foka> I've tried to dd the iso on the dirst (active) partition and also on the entire device without success
<u-foka> also I can't found the unity alpha2 iso image, there are the images for every other flavor but not for ubuntu-desktop
<dobey> main ubuntu doesn't do actual alpha releases any more
<dobey> the daily image should be what you use
<u-foka> so I should try it with an older daily image?
<dobey> maybe, i don't know
<dobey> "refuses to boot" doesn't really say anything about what's wrong
<dobey> you do have to dd to the main device, not a partition
<dobey> "dd if=foo.iso of=/dev/sdg bs=4096" for example
<u-foka> tried that way also, but got only a blank screen
<u-foka> my bios has uefi support and it can't be disabled
<dobey> i can't really help beyond that info though. sorry
<u-foka> okay, thanks anyway
<dobey> fwiw though, #ubuntu is the help channel, so you might have better luck asking in there
<u-foka> I'll try with the 11th image maybe it will work
<dobey> kenvandine, mardy: are there docs about what mechanisms/options can be used with the generic_oauth plug-in, when creating a provider file?
<u-foka> well I thought this is the right channel for asking about an alpha release :) then I'l try asking there also if it won't boot with the other image
<kenvandine> dobey, not that i've seen
<geoff-> Hi, where can I find a kernel that will work with this: cdimage.ubuntu.com/ubuntu-core/daily/current/trusty-core-arm64.tar.gz?
<dobey> kenvandine: do you know if PLAINTEXT is a valid mechanism?
<geoff-> I looked around in ports.ubuntu.com, but could'nt find anything for arm64
<dobey> ah, i guess it is
<kenvandine> dobey, sorry, don't know
<dobey> ok
<Noskcaj> Is there anything i can do to speed up bug 1272123
<ubottu> bug 1272123 in Precise Backports "Please backport gtk2-engines-xfce 3.0.0-1 (universe) from quantal" [Undecided,New] https://launchpad.net/bugs/1272123
<u-foka> well, definitely something's wrong with the uefi boot ot the daily images.. it boots into a black screen when selecting the pendrive from the boot menu, but it boots properly when selecting the pendrive as the first boot device from the bios setup
<u-foka> anyway it's installing now
<dobey>  kenvandine do you know if there is some way to debug the HTTPS requests there?
<dobey> u-foka: that sounds very much like it could be a problem with the BIOS itself
<u-foka> yeah it was my first impression also but somehow the 13.10 insaller boots without any problems in uefi mode
<kenvandine> dobey, i don't, but maybe cwayne might
<kenvandine> he's done quite a bit of hacking on that stuff lately
<dobey> oh
<dobey> and not in here, whee
<Unit193> mvo_: Well howdy.  Just a small poke again. :)
<chiluk> what tool outputs this kind of information ip-21638 [020] .... 37415.094434: lg_local_unlock <-mntput_no_expire
<chiluk> ip-21638 [020] .... 37415.094436: lg_global_lock <-do_umount
<chiluk> ip-21638 [020] .N.. 37431.042253: lg_global_unlock <-do_umount
<chiluk> ip-21638 [020] .N.. 37431.042265: lg_global_lock <-release_mounts
<roadmr> chiluk: seems to come straight from the kernel: http://lxr.free-electrons.com/ident?i=lg_global_lock
<chiluk> roadmr some tool is tracing the kernel..
<roadmr> ohh weird then
<chiluk> roadmr, I'm curious what the tool is that is producing the output.
<chiluk> maybe I'll move to ubuntu-kernel
<stgraber> chiluk: looks fairly close to ftrace
<TJ-> chiluk: local-global spinlocks
<chiluk> thanks stgraber
<Logan_> Noskcaj: hi
<Logan_> ok
#ubuntu-devel 2014-02-15
<Logan_> Noskcaj: hi
<Logan_> sponsoring time
<Noskcaj> :)
<Noskcaj> Many packages await
<Noskcaj> Also, could you sponsor a scheme compiler that debian won't sponsor in time for FF?
<infinity> FF is pretty slack for parts of universe, especially leaf packages.
<infinity> I wouldn't worry about trying to shove every last thing in by the 20th, if you can do it properly a couple of weeks later.
<Logan_> Noskcaj: you're still not a MOTU :(
<Logan_> you're missing out on every past and future Valve-produced game for free :P
<Logan_> just redeemed my code the other day
<Noskcaj> Dude, that physically hurts me.
<Noskcaj> !v1 me in dota though
<ubottu> Noskcaj: I am only a bot, please don't think I'm intelligent :)
<Noskcaj> 1v1
<Noskcaj> oops lol
<Logan_> add me on Steam, bro
<Logan_> college makes it hard to find free time, though :(
<Logan_> on a five-day break currently
<Noskcaj> What's your steam name? Mine should be "Noskcaj"
<Noskcaj> although i need food now
<Logan_> Noskcaj: VAC ban? tsk tsp
<Logan_> tsk
<Logan_> added though
<Noskcaj> I got bored a few years back when i played call of duty
<Devastatr> psusi good evening, do you happen to have a few minutes? I would like to continue the talk we had yesterday, if it's ok
<psusi> Devastatr, sure
<psusi> Devastatr, what exactly was your goal again?  you want two ethernet links to failover when the main one goes down?  the bonding module handles that
<psusi> no need for writing ifupdown scripts
<Logan_> infinity: are you working on the ruby1.9.1 merge?
<Logan_> because all packages b-d'ing on ruby are failing right now due to a Breaks relation from ruby-defaults
<Logan_> so that needs to be done ASAP
<infinity> Logan_: I'm working on much scarier things right now.  I thought I saw mention that doko might be looking at ruby, but maybe not.
<infinity> Logan_: Either way, it'll get done.
<Logan_> because I can do an MP
<Logan_> I just don't want to duplicate work
<Logan_> if doko's not working on it, I'll do an MP
<infinity> MPs for merges are generally pointless.
<Logan_> not really
<Logan_> merges often require work
<infinity> I can merge it right now, the Debian delta is tiny.
<Logan_> please do
<infinity> Logan_: Merges can require work.  And when they do, I can't audit that they work was properly done with an MP most of the time without doing it myself anyway. :P
<Logan_> because it's causing a lot of FTBFSes
<Logan_> alright, touchÃ©
<infinity> (In this case, it would be reviewable, but that's because it's so simple that there's nothing to review)
<Devastatr> psusi yes, the problem is one connection is manual static ip and the other is pppoe static via dhcp, and by down is not just the cable plugged/unplugged or connectivity with its gateway, I have to check by pinging high available ips, like google's 8.8.8.8
<infinity> Logan_: Testbuilding now, then uploading.
<Devastatr> psusi so my idea was to create a dhclient hook to get whatever dhcp server gives to my ppp0 iface, then use it as source for another script which would handle routing by metrics
<infinity> Logan_: Argh.  So, this might need manual unwinding anyway.
<infinity> Logan_: Cause ruby build-depends on ruby, which is uninstallable.
<Devastatr> psusi the ifupdown script would be also to get the iface data of the "manual static ip" iface and do the same
<Devastatr> if I could, I wanted to distribute this work for others who want something similar, so.. maybe packaging it
 * infinity sorts this out with a mild hammer.
<psusi> Devastatr, I don't see why you want to muddle with the ethernet interface.. just start a background job when the pppoe interface is brought up that pings the well known address, and when that fails, switch the default route back to the other one that is well known since it is static
<Devastatr> psusi in my case, the primary link is the static one, pppoe is backup, but I didn't want to hardcode things to be able to create a package and help others, giving something back to linux community or so
<Devastatr> psusi right now I feel like I have no option except making it work for me
<Devastatr> unfortunately I have little knowledge, but I think it's time for the distros to start thinking about an improved ifupdown package, maybe one from scratch, in my opinion a lot of things have changed in the networking world and it didn't cover most of the scenarios, I would like to offer my help if someone starts this
<Devastatr> forgive me if I sound like criticizing ifupdown, it's not my intention
<rbasak> teward: BTW, one thing to do before feature freeze might be to ensure that nginx is building against the version of lua that is in main (if that's possible). I didn't realise when I filed the MIR, but there is a version of lua in main, so if we can build against that, then we won't need to drop lua support.
<rbasak> I was going to look at it if/after the MIR was approved, but with feature freeze coming up, it probably makes sense to do that in advance.
<infinity> Logan_: ruby should be all sorted, once it finishes on arm*
<Devastatr> psusi anyway, I don't know if what I said makes sense but feel free to comment and give suggestions if you want, I like to learn new things :) also thanks for your time
<Logan_> infinity: sweet
<Logan_> thanks man
<infinity> rbasak: Feel like doing a subversion merge?
<rbasak> infinity: I don't want to commit to it right now - there are a few things I have to finish before feature freeze first.
<rbasak> Happy to do it in principle though :)
 * rbasak goes offline for a while
<Noskcaj> cyphermox_, Could you merge usb-modeswitch sometime soon?
* cjwatson changed the topic of #ubuntu-devel to: Trusty Tahr Alpha 2 released! | Archive: open | 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: | LP down for upgrades 2200-2300
* cjwatson changed the topic of #ubuntu-devel to: Trusty Tahr Alpha 2 released! | Archive: open | 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: | LP down for upgrades 2200-2300 UTC
<cjwatson> https://twitter.com/launchpadstatus/status/432754992634544128
<mati75> hello
<mati75> I wonder which idiot came up with an update 6 times initramfs during one version update kernel
<infinity> mati75: Cleaning that up is on the TODO for the kernel team and I.  Pro tip, though, if you want people to listen to your concerns, calling them idiots is usually not the best way forward.
<mati75> infinity: it's terrible think, I will update testing version ubuntu and CPU go on 100 % and temperature is 90Â°C
<mati75> I don't want to cook eggs
<dobey> remove your old kernels
<dobey> update-initramfs is probably not what's doing that, actually. more likely it's dkms rebuilds when a new kernel gets installed
<infinity> dobey: A new kernel installation does generate the initrd more than once.  It's a known bug.
<infinity> (But there are other mitigating factors that can make things much worse, as you point out)
<dobey> yeah, i know it's a bug. just saying that it getting fixed probably won't fix the "100% cpu" issue though
<dobey> as that's more likely a result of dkms
<mati75> dobey: I have only latest from repository
<mati75> I don't have dkms
<mati75> only linux-image-generic meta package
<mati75> and depends for it
<dobey> do you have nvidia drivers? fglrx? virtualbox?
<dobey> and you probably have at least 3 kernels installed after doing a dist-upgrade (the one you're running, the previous version, and the one you just installed)
<infinity> Or lots more, if you never autoremove.
<dobey> exactly
<dobey> but you'll have at least 3
<dobey> until you reboot and autoremove, then at least 2
<infinity> At least 2, somtimes 3.
<dobey> infinity: 3 immediately after an upgrade :)
<infinity> dobey: Well, okay.  3 immediately following, 2 after the autoremove.  No need to reboot.
<dobey> and if you've upgraded from older versions of ubuntu, you might have old kernel packages from there as well, before the autoremove fix happened
<infinity> dobey: The dist-upgrader actually quite violently tears out obsolete kernels.
<infinity> (But if you upgrade with straight apt, yeah, you'd be stuck with 'em)
<dobey> infinity: i recently discovered a whole bunch on my workstation
<infinity> Well, I never use do-release-upgrade on my primary workstation, because it gets upgraded from devel to devel on opening day, before we have an upgrader.
<dobey> and i always upgrade with the gui thing.
<dobey> anyway
 * dobey goes back to ps3 repair
<infinity> doko_: /usr/bin/ld: cannot find -lgcc_s <-- More libgcc1 4.9 fallout?
* cjwatson changed the topic of #ubuntu-devel to: Trusty Tahr Alpha 2 released! | Archive: open | 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:
#ubuntu-devel 2014-02-16
<nathaneltitane> hello! i would like to become a maintainer for an application that hasn'T been updated for a while as a deb package. I have created my ppa, generated the project, described the branch and asked for a pull (CVS), the first build attempt returned this: https://launchpadlibrarian.net/166382622/buildlog.txt.gz i am not really experienced with any of this.. could someone help me please?
<sarnold> nathaneltitane: it looks like your build scripts try to use network resources when building; the buildds do not allow builds to use any networking.
<nathaneltitane> sarnold: hence, what should i do? upload the code manually?
<TJ-> nathaneltitane: You should be uploading (dput) the debianised package source to the builder
<sarnold> nathaneltitane: yeah, either as a new 'upstream tarball' in the build or modify the source via debian patching
<nathaneltitane> sarnold: afaik, i'M not familiar with deb patching, though upstream tarball sounds best.
<nathaneltitane> give me second to test
<nathaneltitane> sarnold: i just pulled the source from cvs on my system and made a tarball
<nathaneltitane> how do i push it?
<nathaneltitane> please bare with me, it's the first time i do this, and as much as I've read the links and indications, i'M still somewhat confused
<sarnold> nathaneltitane: do you have an 'unpacked' tree anywhere, with e.g. debian/control file and debian/changelog and so forth?
<nathaneltitane> sarnold: nope
<nathaneltitane> did a cvs pull, plain and simple
<sarnold> nathaneltitane: indeed, I've been doing it for 1.5 years and still lack the vocabulary to explain what I do and how to make it work :) hehe
<nathaneltitane> i need to 'debianize it' using the build-essentials?
<sarnold> nathaneltitane: can you apt-get source an existing package from the ubuntu archives? that'd give you an unpacked source tree
<nathaneltitane> there is no ubuntu archive
<nathaneltitane> i'm the one setting it up
<nathaneltitane> the source is in cvs
<sarnold> nathaneltitane: oh! okay. then there's a bit more work ahead of you :)
<sarnold> (Please forgive me, all I do is pull existing stuff, make tiny changes, and push it back. :)
<nathaneltitane> well ideally, that'S what i'll be doing too :)
<sarnold> :)
<nathaneltitane> so i have a pull.. what now
<Unit193> sarnold: Tip, use dh_make, handy for creating a template to work off of.
<sarnold> nathaneltitane: well, there's two different ways of doing packaging; there's the newfangled "ubuntu distributioned development" method, which is pretty well dscribed at http://packaging.ubuntu.com/html/ -- but it always felt like a lot of extra overhead compared to the older more traditional debian packaging..
<sarnold> Unit193: ooh. that looks cool.
<nathaneltitane> let'S get started the 'easy' way then
<Unit193> sarnold: Yeah, used it for the first time recently, pretty nifty.  Note that the older release you're running on, the more slightly outdated it'll be (dh8 vs dh9 on saucy)
<sarnold> nathaneltitane: Unit193's suggestion of dh_make looks fantastic; apt-get install dh-make and check out the dh_make manpage. it looks straightforward and simple. :)
<sarnold> Unit193: yeah, that makes sense. most tools I'm used to using do require running fairly new releases to keep building for fairly new releases. :) hehe
<sarnold> Unit193: Thanks for the pointer, this'll save tons of time :)
<Unit193> sarnold: Sure, welcome.
<nathaneltitane> sarnold: looking into it
<nathaneltitane> wow, that seemes to have worked like a charm sarnold
<nathaneltitane> so i now have an ldview-4.2.1/debian dir tree
<nathaneltitane> i used the Tar.gz i pulled as the original source
<sarnold> nathaneltitane: nice!
<sarnold> nathaneltitane: check out the debian/changelog file and make sure it looks useful and then try to build with dput: https://help.launchpad.net/Packaging/PPA/Uploading
<nathaneltitane> shouldn't i make the install dirs first?
<sarnold> nathaneltitane: heh, I was just hoping it would Do The Right Thing :)
<Unit193> Also all the debian/*ex files.
<nathaneltitane> sarnold, all the ex files look good
<nathaneltitane> i have no changes file....
<sarnold> nathaneltitane: that might not be an issue for a first upload?
<nathaneltitane> sarnold, i still dont get which one i need to upload
<nathaneltitane> i have the deb tree and the tar gz that was generated by dh-make
<sarnold> nathaneltitane: hrm. sorry, I hadn't realized the dsc wouldn't be sufficient for the upload.
<Unit193> You normally dput the changes file.
<infinity> Unit193: s/normally/always/
<Unit193> Yes.
<doko> infinity, can't see that
<infinity> doko: https://launchpad.net/ubuntu/+source/gccgo-go/1.2-0ubuntu5
<infinity> doko: The FTBFS on armhf and powerpc.
<doko> urgh, and the non-build on ppc64el ...
<doko> jamespage, ^^^
<infinity> doko: The non-build on ppc64el is because we're purging the archive.
<doko> ahh
<infinity> doko: It'll get a build record tomorrow.
<infinity> doko: Shot in the dark, but libgcc-4.8-dev would imply perhaps a mismatch for headers/static library from the 4.9 libgcc1?
<doko> no, thats blindly shooting
<infinity> Hence "shot in the dark". :P
<infinity> doko: Mostly just want to know that whatever that issue is, it's not something that's going to screw the ppc64el rebuild tomorrow.  If it's specific to gccgo, or gccgo-go, then yay, if it's something that needs fixing with libgcc, on the other hand...
<infinity> doko: Erk.  So, on x86, I have a /usr/lib/<triplet>/4.8/libgcc_s.so symlink to /lib/<triplet>/libgcc_s.so.1
<infinity> doko: On ppc64el, it's a linker script instead of a symlink.
<infinity> doko: Seems an odd disparity.
<infinity> Oh, maybe that's intentional too, since some arches need -lgcc?
<doko> it's intentional. the .so symlink is just missing
<infinity> Which symlink?
<qengho> Hi all.  I'm trying to boot a CD for the first time in ages.  I find I'm dumped into a initramfs shell, but it's not clear why -- no messages or anything.  A strange thing, I think, is that after the shell prompt, the kernel displays the device-discovery lines for the CD device.  So, I suspect that it's trying to rotate root, hasn't settled USB, aborts silently.
<qengho> I found this to be the same for when I'm booting off a UMS stick too.  Device discovered about 1 sec after being dumped into a initramfs shell.
<qengho> Trusty daily image of yesterday, for that^.
<teward> is there a reason that some packages only have arm64 and ppc64el builds and not builds for other architectures?
<Ampelbein> teward: They most likely have been built in earlier releases for i386, amd64 etc
<teward> Ampelbein: ah, okay, i see.  it would only show builds for a given release if, say, the version changed?
<teward> (the package in question seems to have remained the same version since Quantal)
<Ampelbein> teward: Yes, pretty much. Once a binary package is published, that version will not be rebuilt.
<teward> okay, that threw me off on Launchpad
<teward> thanks
<Ampelbein> teward: Like https://launchpad.net/ubuntu/+source/aoetools -> Uploaded in lucid, built for the architectures that lucid was released with. Then, in precise, the armhf was introduced, so it was built there.
<Ampelbein> Quantal didn't have a new architecture, so no build records at all.
<Ampelbein> Saucy then got arm64 and finally trusty got ppc64el
<teward> right
<Noskcaj> darkxst, What do we still need to get gnome-desktop 3.10? Also, are there any 3.12 parts we want?
<highvoltage> ogra_: thanks so much
#ubuntu-devel 2015-02-09
<darkxst> pitti, hi, more systemd woes ;( not getting any filesystems (from fstab) mounted, seemingly triggered by glib on ubuntu-desktop ppa
<pitti> Good morning
<pitti> hey darkxst
<pitti> darkxst: oh? would you mind booting with "debug", and put the "journalctl" output to a bug report?
<darkxst> hey
<darkxst> ok
<pitti> darkxst: glib is rather unlikely, but it may have triggered some timing stuff
<pitti> s/stuff/difference/
<pitti> darkxst: oh, not in #u-desktop any more?
<darkxst> pitti, on laptop
<pitti> darkxst: so, by the release I plan to fix that "adm" users can access the journal
<darkxst> most normal users are in that group?
<pitti> darkxst: debian bug 771980
<ubottu> Debian bug 771980 in systemd "systemd: /run/log/journal is not readable by the adm group" [Minor,Open] http://bugs.debian.org/771980
<pitti> darkxst: no, only the first one (which also gets sudo); other than that, that should be limited to administrators
<pitti> darkxst: exactly the same as syslog, BTW
<pitti> -rw-r----- 1 syslog adm 809053 Feb  9 07:24 /var/log/syslog
<darkxst> pitti, right, so there is really no way to get logs then from apport?
<pitti> darkxst: you mean now, or after fixing the above?
<pitti> darkxst: nothing regressed under systemd, you can still get syslog etc.; but of course accessing the per-unit journal would be nicer
<pitti> darkxst: if you aren't in "adm", then the hook could still ask for it with root privs (you'll get a polkit prompt then, and an admin has to authenticate)
<darkxst> pitti, well currently we grab the upstart user logs for say gnome-session
<pitti> darkxst: oh, user
<pitti> darkxst: nothing has changed for the user session
<darkxst> maybe its a GNOME thing? but no user logs with that stuff now
<pitti> darkxst: I don't know, did GNOME Ubuntu ever use upstart sessions?
<pitti> I thought all of our DEs would
<darkxst> pitti, yes
<pitti> and session init is still upstart
<darkxst> pitti, I am 100% we do not get logs in .cache/upstart
<darkxst> and also a couple of wierd bugs due to upstart user sessions disappear
<darkxst> under systemd init
<pitti> darkxst: oh, indeed; I only have one recent file there, .cache/upstart/unity-panel-service.log
<pitti> but also some rotated stuff from yesterday
<darkxst> pitti, bug 1419623
<ubottu> bug 1419623 in systemd (Ubuntu) "systemd init is no mounting drives from fstab" [Undecided,New] https://launchpad.net/bugs/1419623
<darkxst> and bug 1385572 is the reason I think there is no upstart user sessions under systemd init
<ubottu> bug 1385572 in upstart (Ubuntu) "gnome-session not shutting down cleanly" [Low,Confirmed] https://launchpad.net/bugs/1385572
<pitti> darkxst__: I suppose logging into a VT works and puts you into the root dir; there sudo mount -a should work?
<pitti> darkxst__: (just making sure it's not something serious with util-linux or the actual partitions)
<darkxst> pitti, yes that is what I have been doing
<pitti> cyphermox: oh, nothing wrong with python-dbusmock -- it just detected gnome bug 734466 :)
<ubottu> Gnome bug 734466 in nmcli ""nmcli dev wifi" crashes with multiple wifis" [Normal,Resolved: fixed] http://bugzilla.gnome.org/show_bug.cgi?id=734466
<dholbach> good morning
<pitti> infinity: hm, the latest "patch" release fixes the dangling symlink problem for most packages, but apparently not glibc yet; I wonder what kind of funky thing it tries to do there, symlink outside the build tree or so?
<Mirv> can a core-dev "ack" https://ci-train.ubuntu.com/job/ubuntu-landing-006-2-publish/lastSuccessfulBuild/artifact/packaging_changes_ubuntu-ui-toolkit_1.1.1403+15.04.20150206-0ubuntu1.diff ? both new build-deps are in main.
<infinity> pitti: The new glibc should be fine, no?
<infinity> pitti: It unpacks and builds locally, at least.
<infinity> pitti: Seems to be going happily on the buildds too.
<pitti> Mirv: LGTM
<infinity> pitti: No idea, TBH, why -13ubuntu1 is/was sad, but I think we're past that.
<pitti> infinity: hm, I still see it on http://d-jenkins.ubuntu-ci:8080/job/vivid-adt-glibc/27/ARCH=i386,label=adt/console which ran on Feb 6
<pitti> glibc_2.19-13ubuntu3.dsc
<pitti> infinity: ok, if it works locally now I'll investigate, thanks
<infinity> pitti: -15ubuntu1 is the one that works.
<LocutusOfBorg1> hi people
<pitti> hm, why didn't that run
<infinity> pitti: It only uploaded 43m ago.
<pitti> oh! just from 33 minutes ago :)
<Mirv> thanks martin
<pitti> wgrant: hey William, how are you?
<pitti> wgrant: not sure if you saw my email about RTM langpack exports the other day, but would we have enough capacity to build them more often? like twice a week?
<alkisg> mvo: Good morning! About the update-manager SRU, and a possible re-upload without the other changes, last Friday you said "I look at this, in a call right now" - did you? Should I wait for a re-upload, or just try to make SRUs out of the other changes included in the same upload?
<wgrant> pitti: Ah, missed that. RTM exports only take about 90 minutes, so we can do them daily, particularly since the new DB servers are slowly coming online. I'll have to add a new flag for the persistent full exports, though. How pressing is this?
<alkisg> https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/1415785
<ubottu> Launchpad bug 1415785 in update-manager (Ubuntu Precise) "Please remove all ltsp* blacklisting" [High,In progress]
<pitti> wgrant: vrr knows more about how pressing it is, but I suppose it's the kind of "the earlier the better", but "not world breaking" class
<pitti> wgrant: cjwatson proposed to just add the "export full pack" to the API so that we can set it via cron
<wgrant> pitti: If you're happy with that then that's fine too.
<wgrant> It's a little easier from our end.
<pitti> wgrant: yes, that'd work well enough for me
<pitti> le huh? my mouse pointer just became invisible; VT switching and switching between different windows (with different cursor shapes) doesn't help
<pitti> is there a trick to make it visible again?
<ogra_> wiggle it
<ogra_> :)
<pitti> mlankhorst, tjaalton ^ do you happen to know?
<alkisg> Unplug it from the usb port and plug it again? :)
<pitti> alkisg: no; the mouse clearly works (FFM, marking text, clicking, etc.)
<pitti> I just don't see the cursor
<pitti> (unpluggging, VT switch etc. doesn't help)
 * ogra_ hands pitti some http://i.stack.imgur.com/DVuWk.png
<pitti> :)
<pitti> well *shrug*, I'll just reboot as soon as I can
<tjaalton> try restarting compiz?
<tjaalton> gtk can hide it, maybe it got stuck
<tjaalton> this happens frequently for me when logging in, but it comes back once everything is loaded
<pitti> nope, restarting compiz didn't help either
<pitti> anyway, probably sun rays / rare graphics driver bug
<mlankhorst> pitti: no idea, I know gsd hides the cursor if no mouse is found, annoying with synergy :P
<pitti> oh wow, and all of a sudden it popped up again
<pitti> mlankhorst: ah, perhaps some weirdness with the thing that hides the touchpad and/or mouse cursor on inactivity
<pitti> syndaemon
<mlankhorst> sounds likely
<tjaalton> is that even used anymore?
<tjaalton> guess it shouldn't
<pitti> yeah, if you enable the option in control-center
<pitti> now I remember that I enabled it in in the train last weekend
<tjaalton> sounds legacy
<tjaalton> anyway :)
<pitti> but I thought that was for disabling the touch pad during typing, not disabling the mouse pointer on inactivity
<pitti> we once had something for the latter in the past ("unclutter"), but I thought that has long been obsolete
<pitti> and/or went into GTK or whereever
<tjaalton> yep
<LocutusOfBorg1> hi people does anybody know if bug 1417716 is affecting virtualbox or sysvinit?
<ubottu> bug 1417716 in virtualbox (Ubuntu) "package virtualbox 4.3.18-dfsg-2ubuntu1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [Undecided,Incomplete] https://launchpad.net/bugs/1417716
<LocutusOfBorg1> I can't figure it out
<LocutusOfBorg1> seems more bug 1385817
<ubottu> bug 1385817 in Release Notes for Ubuntu "initscripts package fails to upgrade if there are local init scripts on the system with no LSB headers" [High,Triaged] https://launchpad.net/bugs/1385817
<xnox> LocutusOfBorg1: most of the time it's neither.
<xnox> LocutusOfBorg1: it's duplicate of "initscripts must have sysv headers"
<xnox> bug
<LocutusOfBorg1> thanks xnox :)
<LocutusOfBorg1> I was so tempted to close as duplicate
<infinity> pitti: That calibre/powerpc failure that references 'Pool(cpu_count)' ... It's not losing its mind because sagari has 24 CPUs, perhaps?
<pitti> oh, I didn't even know about it
<pitti> I guess I don't get ftbfs mail for autosynced packages
<infinity> pitti: Yeah, cause you don't get mail from LP... That.
<pitti> thread.error: can't start new thread
<seb128> bdmurray, hey, is there a known issue with e.u.c and crossing of lines corresponding to fixed bugs? it seems it stopped doing that since the "... seen" columns indicate series rather than versions?
<infinity> pitti: I'm betting that if I re-run it on one of the <= 8 CPU buildds, it'll work fine.  But that's just a wild guess.
<pitti> sounds a bit like debian bug 760865
<ubottu> Debian bug 760865 in src:calibre "calibre: FTBFS on mips: thread.error: can't start new thread" [Serious,Fixed] http://bugs.debian.org/760865
<pitti> I coudl extend the workaround to powerpc
<pitti> but that was also just a workaround without truly understanding the issue
<infinity> pitti: Yeah, the workaround definitely sounds incorrect. :P
<pitti> $ python -c  'from multiprocessing import cpu_count; print(cpu_count())'
<pitti> 4
<infinity> pitti: And I bet I can reproduce on other machines with sufficiently large numbers of cores/threads.
<pitti> so that would print 24, but it cannot actually handle 24 threads?
<infinity> pitti: It can handle 24 threads fine, but I suppose it depends on what "handle" means.
<mvo> alkisg: hi, sorry for the slow reply, I added a sru header to the bugreport now where it was missing (the https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/1402706)
<ubottu> Launchpad bug 1402706 in update-manager (Ubuntu Precise) "More explicit wording needed for HWE updates" [High,In progress]
<infinity> pitti: 24 threads consuming massive amounts of memmory each could explode, for instance.
<alkisg> mvo: hi, I think there are 2 more involved bug reports that lack SRU headers? Let me check...
<alkisg> mvo: LP #1415785, #1402706, #1341320, #1343296
<ubottu> Launchpad bug 1341320 in update-manager (Ubuntu) "empty apt-get install command suggested by hwe-support-status" [Undecided,Confirmed] https://launchpad.net/bugs/1341320
<ubottu> Launchpad bug 1415785 in update-manager (Ubuntu Precise) "Please remove all ltsp* blacklisting" [High,In progress] https://launchpad.net/bugs/1415785
<ubottu> Launchpad bug 1343296 in update-manager (Ubuntu) "hwe-support-status does not output all necessary commands for upgrade" [Undecided,New] https://launchpad.net/bugs/1343296
<mvo> alkisg: let me check
<infinity> pitti: It would be better to find out *why* we're seeing "thread.error: can't start new thread"
<infinity> pitti: Cause it's nonsensical to make a blanket statement like "arch $foo can't handle $bar threads", given than a single-core machine can run thousands of threads.
<infinity> pitti: But if it's trying to eat a ton of RAM with each, or hitting some bizarre internal counter or something, that would be worth knowing.
<infinity> pitti: I figure that replacing the autodetection with a static "200" and testing locally would probably show the same bug.
<infinity> pitti: Or, from a random stackoverflow hit: "You're using a 32bit system and running out of virtual memory. One of your libraries is likely spawning threads and not reclaiming them correctly. As a workaround, try reducing the default thread stack size with threading.stack_size."
<infinity> pitti: So, maybe just wise to limit your thread count to "NUM_CORES || 8", whichever is smaller, or do so only on 32-bit systems...
<infinity> pitti: Seems like python's just exhibiting a bit of suck here. (not surprising, from how much I know about python threading sucking)
<pitti> infinity: ah yeah, trying with "200" on a low-ram VM or so could work
<pitti> (to try and reproduce)
<infinity> pitti: Note that that machine is hardly "low RAM".  It's 16G, but yeah, also 32-bit, so python's only getting 2G (or 3G, I can't remmeber what the user/kernel split on ppc32 is).
<pitti> ah ok, so "200" on an i386 VM should be reasonably close then
<infinity> pitti: So, reproducing on i386 with a large thread count should be easy, I'd think.
<infinity> pitti: Yeah.
<popey> pitti: seems something changed recently in udev (perhaps) on vivid, as I can no longer "adb devices". adbd has to be started as root. This seems to be a regression over the last week or so.
<pitti> popey: i. e. your /dev/usb/... is no longer accessible to you?
<pitti> popey: you should get an automatic ACL to it
<ogra_> pitti, he can see the device when he runs "adb devices" as root
<ogra_> (after adb kill-server on the PC)
<pitti> (check lsusb for bus/device number, then getfacl /dev/bus/usb/001/002 and change the numbers accordingly)
<infinity> pitti: Anyhow, it would make sense if mips is seeing a similar issue, cause Debian's mips buildds are Cavium CPUs with a ridiculous number of cores, and 32-bit userspace.
<ogra_> http://paste.ubuntu.com/10140289/
<ogra_> this is what we ship with the android-tools-adb package
<infinity> pitti: Which is something no other port has.  I don't think any other 32-bit port goes over 8 cores in any Debian or Ubuntu buildd configuration.
<popey> pitti: http://paste.ubuntu.com/10140305/
 * ogra_ sees infinity's lanst android upload and thinks we really need to get rid of these win32 build deps at some point 
<pitti> user:alan:rw-
<pitti> popey: ^ LGTM
<popey> hm, so I wonder why adb devices returns no devices then.
<ogra_> well, adb didnt change since november
<infinity> ogra_: I'm not convinced mingw32 is actually used in the build (a grep in the build log didn't seem to show it being called), but I didn't feel the urge to experiment either.
<popey> http://paste.ubuntu.com/10140312/
<ogra_> yeah
<pitti> hard to tell; perhaps stracing adb as user reveals some EPERM thing someplace else?
<pitti> (FTR, works fine here with nexus 4 on current vivid)
<popey> hmm, ok. thanks.
<pitti> popey: can you run adbd in the foreground? perhaps that already spits out some error message
<popey> will try
<ogra_> not adbd ... adb
<ogra_> adbd is the bit running on the phone
<pitti> ogra_: ah, ok; I mean the server bit that it forks off into the background
<pitti> I don't see a CLI switch to run it in foreground, so I guess strace it is :/
<ogra_> right, not sure you can run it easily in the fg
<popey> :(
<popey> aha!
<popey> I think some path has changed and it's found another version of adb? http://paste.ubuntu.com/10140430/
<pitti> /home/alan/tools/android/eclipse-adt/sdk/platform-tools/adb
<popey> \o/ "/usr/bin/adb devices" works!
<pitti> so you have that in your $PATH?
<popey> yeah, blame didrocks ã
<popey> umake :)
<popey> looks like it was added to my bashrc
<didrocks> popey: that's what you gain by listening to users! :)
<popey> I know right!?
<didrocks> why the adb version here doesn't work for you? (should I backlog?)
<popey> ogra_: did we patch adb in android-tools-adb?
<ogra_> popey, sure
<didrocks> ah, here we go :)
<popey> :)
<ogra_> popey, adb abd adbd are both a cmpolete patch
<didrocks> popey: I purified your bashrc with upstream goodness :)
<popey> I feel blessed.
<ogra_> (not sure we make any changes to it though )
<ogra_> (for adb that is, adbd is heavily changed)
 * popey modifies his bashrc
 * popey has learned things today. thanks chaps :)
<alkisg> mvo: should I help with the SRUs for the other 2 bug reports?
<alkisg> (sorry if you talked to me and I didn't receive it, laggy network today here...)
<caribou> tkamppeter: Hi, remember the cups fix you sponsored for me recently ?
<caribou> tkamppeter: I have just uploaded the debdiffs for Trusty & Utopic. want to sponsor those as well ?
<tkamppeter> caribou, Utopic I have uploaded now, now I will do Trusty.
<caribou> tkamppeter: perfect! I've already built & tested on both; I'll add the SRU team once you're done
<tkamppeter> caribou, Trusty is now done, too.
<caribou> tkamppeter: great, thank you !
<tkamppeter> caribou, thanks for setting up the CUPS SRUs.
<tkamppeter> caribou, the CUPS SRU path for Trusty is still blocked by bug 1386241. I will look into what can be done here. The Utopic SRU can already be processed though.
<ubottu> bug 1386241 in system-config-printer (Ubuntu Trusty) "Add the full IPP Everywhere support from Utopic to Trusty" [High,Triaged] https://launchpad.net/bugs/1386241
<caribou> tkamppeter: ok, thanks for checking that out
<bdmurray> seb128: not, that I'd heard of
<ricotz> mvo, hi, please take a look at the attached debdiff here https://bugs.launchpad.net/ubuntu/+source/aptitude/+bug/1399582
<ubottu> Launchpad bug 1399582 in aptitude (Ubuntu) "aptitude fails to fetch changelogs because of illformed URL request" [High,Confirmed]
<sabdfl> ScottK, wow, that was a fun memory!
<sabdfl> or, sort of memory :)
<sabdfl> the sea survival training was a bit of a blur
<bdmurray> seb128: I'm looking into it though, thanks
<seb128> bdmurray, can you confirm? want me to report a bug?
<bdmurray> seb128: I can confirm, it works better on a filtered page like https://errors.ubuntu.com/?release=Ubuntu%2015.04&package=media-hub&period=day and a bug would be helpful
<seb128> bdmurray, against what component?
<bdmurray> launchpad.net/errors/
<seb128> bdmurray, https://bugs.launchpad.net/errors/+bug/1419878
<ubottu> Launchpad bug 1419878 in Errors "default view doesn't seem to cross lines corresponding to fixed bugs" [Undecided,New]
<alexbligh1> Dependency question. Package A provides, conflicts, and replaces B. Package C conflicts with package B. The idea here was for an upgrade from A(old) to A to remove package B, but to optionally let a legacy version be reinstalled (package C shares some of the same files as package B). What happens in practice is package C can't be installed without removing A. Any ideas?
<cjwatson> alexbligh1: Make the Conflicts from C to B versioned, so that it won't match the Provides.
<cjwatson> E.g. <= max-version-that-ever-existed, or even just >= 0
<alexbligh1> cjwatson, aha! very clever. Thanks
<rharper> hallyn: stgraber:  is there a non-interactive form  of lxc remote add <url> when the password is set?  currently it prompts when password is set, would like to do this automatically
<hallyn> rharper: I work around it by adding the client certificsate in the server's certs dir
<hallyn> then server doesn't ask for pwd
<rharper> hallyn: hrm... for some reason I thought I needed to do the pass bits before the certs were generated
<rharper> I'm doing: 1. start lxd locally, 2) lxc config set password <pass>  3)  I want to add the remote  --    4) copy client certs ... but you're saying I can swap 4 and 3 ?
 * rharper gives it a go 
<hallyn> rharper: yeah just do a 'lxc remote list' first to generate th client certs, copy them over, restart lxd
<rharper> cool
<hallyn> i've got a juju charm that tries to do this.  (but fails at some point, and i've neglected it)
<rharper> I get fingerprint prompt
<rharper> hallyn: oh, I should look at what you have then
 * rharper is charming lxd/lxc stuff as well 
<hallyn> rharper: oh excellent then i may not have to :)  what i've got is at... oh lemme re-push
<rharper> hrm, looks like somethin with config trust list might help fill out the client/servercert/local.crt bits...
<hallyn> lp:/~serge-hallyn/charms/trusty/ovs-lxd/trunk
<hallyn> ?
<rharper> http://paste.ubuntu.com/10146613/
<rharper> hallyn: I noticed that once I do the remote add, I get a new file in ~/.config/lxc/servercert/<name>.crt
<rharper> I assume once that's present (from accepting the fingerprint) that we don't get prompted again
<hallyn> right
<rharper> but I still want a way to accept the server cert without prompting
<hallyn> but 'config trust', if that was implemented, i missed the pull request to od that :)   obviously shouldn't crash though
<hallyn> raise a github issue :)
<rharper> heh
<hallyn> that tych0 chap will get on it in a jiffie
<hallyn> uqestion is how would we make that safe?
<rharper> right, so what would let me pull down the server cert into the local config  ?
<rharper> I assume the same way ssh does it (you put your hands in your ears and supply a parameter that says I don't care)
<hallyn> i understnad on a trusted network with auto-instlal it's what you want.  but how do we keep users from then using that to their ec2 host
<rharper> but seriously it'd need to be done via some published fingerprint ... maybe gpg keyring publishing ?
<hallyn> yeah i think best ot discuss this on a github issue
 * rharper is way out of his comfort zone 
<hallyn> with certs, or with github issues?
<hallyn> btw what are you doing, testing nc-lxd?
<rharper> yes, nc-lxd, charming it up while zul works on kilo stuff;
<rharper> hallyn: I see now how yuo get the servercert
<rharper> in the nc-lxd case, it's eaiser since the server/client are the same machine
<rharper> I just need to fish out the lxd server cert file
<rharper> copy it to the client config location
<rharper> and won't get the prompt
<zul> rharper:  im going to be using the unix socket daemon in the next iteration
<hallyn> don't make him cry
<zul> hallyn:  i dunno...rhaper is a big boy
<rharper> sometimes
<israel> does anyone know how to set _NET_WM_ICON easily in C++ I haven't been able to easily find documentation on this
<dobey> israel: in qt?
<israel> No dobey in FLTK... sorry I should have specified this..
<israel> I was going to try to simple set it via xkb stuff (or xlib) but I am not very familiar with that
<israel> the documentation for xkb is not very good for someone unfamiliar with it
<dobey> israel: i think you'd use Fl_Window::iconlabel("exe-name") and it will pull the icon from the theme and set the appropriate x window hints
<dobey> xkb is for keyboards
<dobey> so i can see how that would be confusing :)
<israel> heheh sorry xcb
<israel> too many x acronyms
<israel> i will try it dobey and let you know
<dobey> at least, that's what i gathered from a simple "fltk set window icon" search :)
<israel> not quite working.... dobey thanks for the try :)
<dobey> israel: if fltk doesn't provide working facilities for it, and you don't care about portability, then you'll need to use Xlib indeed; best place to look at that is probably the gdk-x11 code in gtk+
<Noskcaj> cyphermox, What are we still waiting on for bluez5?
<israel> thanks dobey  it is GNU/Linux only (JWM specificly)  I will check it out!
<cyphermox> Noskcaj: just coordinating things, I'm not convinced that we are waiting on much. You should ask seb though
<cyphermox> there's already a PPA with the transition in progress: ppa:ubuntu-desktop/transitions
<arges> hallyn: hey
<arges> hallyn: almost have this patch done for disabling ksm in vm. found an issue when testing.
<hallyn> arges: ok, cool.  i'm doing the merge right now.  head spinning a bit, will bbiab
<arges> hallyn: yea no hurry, i'll just post it to the bug when its ready
<hallyn> arges: ok, thanks
<rharper> hallyn: stgraber: where do you get updated golang package for trusty ?
<roaksoax> ScottK: do you have any plans of updating psycopg2 to 2.6 in debian anytime soon?
<ScottK> roaksoax: I hadn't noticed it was out.  I can look at doing an upload to experimental.  Possibly as soon as Friday.
<roaksoax> ScottK: yeah, I just noticed today. And thanks! Let me know if you do so we can make sure it makes it into vivid
<hallyn> rharper: https://launchpad.net/~ubuntu-lxc/+archive/ubuntu/lxd-daily
<rharper> hallyn: thanks!
<stgraber> rharper: ubuntu-lxc/lxd-daily
<rharper> stgraber: thanks!
<aeoril> How do I use /debian/rules to configure a make environment for an Ubuntu package?  Or, where would I find that info on the web?
<aeoril> Should I set up my build environment using this tutorial, or is it out of date?  https://wiki.ubuntu.com/BeginnersTeam/FocusGroups/Development/Devbeginnings
<aeoril> (I think the BeginnersTeam was disolved some time ago, IIRC)
<sarnold> aeoril: I suggest this instead of the pbuilder: https://wiki.ubuntu.com/SimpleSbuild
<aeoril> sarnold hey!  Thanks!
<sarnold> aeoril: but e.g. Unit193 said he uses pbuilder, so it's not like pbuilder is wrong; I've heard though that sbuild does a better job approxmiating the buildds
<aeoril> sarnold I remember Unit193 - I used to interact with him a lot on #ubuntu-beginners-team or whatever ...
#ubuntu-devel 2015-02-10
<aeoril> sarnold I don't need sbuild or pbuilder if I can use vms though right?
<cjwatson> VMs are way more cumbersome for this
<aeoril> sarnold why?
<sarnold> aeoril: to a point, yes, but it's sometimes nice to keep VMs clean so they can be easily re-used..
<aeoril> cjwatson why?
<cjwatson> I mean, yes, you can arrange to bring up a clean VM from a base state every time and install just what you need to do the build
<sarnold> aeoril: and once you get the build environment set up, it's always ready for further use :)
<cjwatson> But sbuild automates all that and it's much faster
<aeoril> sarnold cjwatson ok, that makes sense
<cjwatson> And if you don't arrange to be starting from a clean state each time, it's not as reliable a test that you got everything right
<aeoril> ok
<aeoril> cjwatson sarnold The first thing I will need to do after setting up my build environment is build vim the same way it was built in the trusty package that was released with Ubuntu.  How do I do that?  I need to use the /debian/rules somehow I think - it has the correct rules to set up the make envirnonment
<aeoril> cjwatson sarnold what I really need to do is learn how to build the upstream vim from its git source just like it was built under trusty so I can bisect correctly
<aeoril> I have experimented with passing various command line parameters to ./configure but have not succeeded in reproducing the same build environment.  I can reproduce the bug, but it is not reproduced in exactly the same way
<aeoril> (I gleaned them from /debian/rules)
<aeoril> Anyway, when I get back from dinner I will re-read the instructions for sbuild and try them out on a clean virtual machine until I get them right
<aeoril> cjwatson sarnold note that I successfully reproced the bug using a certain command line I created from options in /debian/rules, but unfortunately the bug still happened even using the latest source code so it was bad in code that was in trusty and beyond vivid, so that was not usable.  Also, the build was not identical by any means, but it was the first time I could reproduce the bug
<aeoril> from the upstream source, so that may have some value in knowing
<aeoril> s/reproced/reproduced/
<sarnold> aeoril: this is even harder to nail down than I expected..
<aeoril> sarnold yes, I really need to somehow figure out how to build it like they did in trusty - I think that seems to be key at this point.  The bug is not cooperating.
<aeoril> sarnold but, I was able to reproduce it from the upstream git source using an "screwed up variant" of the trusty build environment, so that gives some insight somehow
<aeoril> sarnold maybe it points to the build environment as the source of the bug rather than the source code itself?
<aeoril> vim source code*
<sarnold> aeoril: that's a possibility, not easy to track down though :)
<aeoril> sarnold by "build environment," I mean whatever was created by ./configure [command line ...]
<aeoril> command line params*
<aeoril> sarnold yes, I am beginning to realize that
<tkamppeter> when does the Upstart -> systemd transition take place? Can I drop Upstart support in CUPS already in Vivid?
<aeoril> sarnold we'll get 'er figured out though ... sooner or later ... :)
<aeoril> sarnold I definitely need to get a proper build environment set up for this though using sbuild I guess
<aeoril> (build environment here meaning more correctly the proper gcc, libraries, etc.)
<aeoril> darkxst hey, I made some headway today, but it is going to be harder than thought
<cjwatson> aeoril: Right, so for bisection sbuild is probably in fact a bit cumbersome to set up in full because you'd have to recreate full working packaging at each step, but I'd still at least use the schroot part of it for your builds.  I suspect that you can get most of the way by just fishing out the appropriate configure options and any relevant environment variables from debian/rules.
<cjwatson> tkamppeter: Part of a smooth transition is likely to require keeping upstart support past the transition (at least until the next LTS, I should think) so that upgrades can be smooth.
<aeoril> cjwatson ok, cool - that was my first question - I fished out a portion of them already, but it was not quite correct.  I will try to fish out the rest when I get finished with dinner.  Would you be available to help me when I do to get all the options correct?
<cjwatson> aeoril: Unlikely, sorry.  It's late.  Only awake because my eye's irritating me.
<cjwatson> Also I'm really just doing drive-by Ubuntu development these days :)
<aeoril> cjwatson ok, that is ok - thanks for the help anyway
<darkxst> aeoril, good!
<aeoril> darkxst I have reproduced the bug by passing a partial list of command line params to ./configure on the git source by fishing them out from /debian/rules.  However, the same bug happened on the latest upstream with those same params.  cjwatson suggests I fish out the rest of them (to paraphrase) so I and use them to bisect.  Would you agree?
<darkxst> aeoril, yes
<aeoril> darkxst I could tell I did not build it exactly the same with --version because the gcc and ld command lines were not the same ...
<aeoril> darkxst would you be available after I have dinner if I have trouble figuring out what I need from /debian/rules ?
<aeoril> darkxst figuring out what I need to pass to ./configure in the upstream build from git?
<darkxst> aeoril, should be around, but likely in and about a bit today
<darkxst> aeoril, have you tried looking at the buildlogs?
<aeoril> darkxst also, I am thinking it may be more of a build environment bug so I think the first thing I will do is diff /debian/rules between vivid and trusty ... that would be quick, hopefully
<darkxst> pretty sure the exact configure command will show in the buildlogs
<aeoril> darkxst oh, did not know about buildlogs - I will do that
<aeoril> darkxst you mean just ./configure without any params?
<aeoril> oh, sorry - misread - gotcha, will look at the logs - that would be wonderful! :)
<darkxst> the actuall full configure command
<aeoril> darkxst yes, misread - gotcha!  Thanks1  I hope that is true!
<darkxst> aeoril, and you probably need to set CFLAGS also, to get a build exactly the same
<tkamppeter> cjwatson, OK, thanks.
<aeoril> darkxst I was thinking about CFLAGS and there is another one, maybe like it ... do you mean actually set CFLAGS from the command line before running make?
<aeoril> darkxst I saw CFLAGS in /debian/rules, IIRC
<darkxst> aeoril, yes (before running configure though)
<aeoril> darkxst oh, ok - yah, I would need to know what that is - hopefully from the logs???
<tkamppeter> slangasek, around?
<darkxst> aeoril, should be
<aeoril> darkxst ok, cool - thanks for all the help!  Gotta go to dinner!
<darkxst> aeoril, debian/rules is rather complicated, so the buildlogs are likely your best bet
<aeoril> darkxst yes, ok - I will hope for the best on that ...
<darkxst> aeoril, https://launchpadlibrarian.net/192193726/buildlog_ubuntu-vivid-amd64.vim_2%3A7.4.488-3ubuntu2_UPLOADING.txt.gz
<aeoril> darkxst cool!  Thanks!
<darkxst> look for the lines with ./configure
<aeoril> ok - what about trusty?
<darkxst> you can probably just cut+paste that entire line
<aeoril> yah, cool - I am leaving about as fast as you did the other night!
<aeoril> lol
<sarnold> darkxst: hah! that's so much easier than figuring out what debian/rules "would" execute. very nice. :)
<darkxst> aeoril, got to vim page on launchpad and click through through the trusty packages
<aeoril> ok, cool - thanks
<aeoril> darkxst ok, so this:  https://launchpadlibrarian.net/161446547/buildlog_ubuntu-trusty-amd64.vim_2%3A7.4.052-1ubuntu3_UPLOADING.txt.gz
<aeoril> Yippeee!
<aeoril> That also shows me v7-4-488 was vivid ...
<aeoril> LEAVING!!!
<ahoneybun> hey darkxst
<darkxst> ahoneybun, hi
<ahoneybun> balloons:  it runs damn well
<aeoril> darkxst I found and used the entire ./configure command line along with the LDFLAGS and CFLAGS settings from the logs.  The problem occured both on the standard trusty package and in the git upstream source I pulled a few days ago.  I looked at the vivid logs on launchpad, and the ./configure command line is different.  I tried it on trusty, but the version of GCC on trusty could not
<aeoril> recognize one of the command line parameters given to it (gcc: error: unrecognized command line option '-fstack-protector-strong')
<darkxst> aeoril, remove the unrecogonized flags
<aeoril> darkxst I was going to try it on vivid (I already have a vm set up) to see if it would work
<aeoril> darkxst then maybe try the trusty command line on vivid to see if it causes a failure.  That would perhaps indicate a failure with the build, not the code?
<darkxst> aeoril, things like -f should affect things to much
<darkxst> alteast keep any -D's
<darkxst> (^^ unless its some weird compiler bug, but I think that is unlikely at this stage)
<aeoril> darkxst so you think I should try without the offending flag on trusty rather than worry about vivid right now?
<darkxst> your using the command from vivid?
<aeoril> darkxst yes, I tried the vivid command line from the vivid logs on my trusty machine - ./configure halted with the above error
<darkxst> aeoril, yes just drop any flags that error
<staylor> Anyone know what causes a package to refuse to be installed with :arch without attempting to remove the host architecture packages?  For example attempting to install libgirepository-1.0-1:armhf on 14.04 causes apt to want to remove the host gir and dependent packages.  I'm assuming it has something to do with the package not correctly using /usr/lib/TRIPLET/lib*.so and instead goes directly into /usr/lib/lib*.so yes?
<aeoril> darkxst should I try real quick to run that command line on my vivid vm?
<darkxst> aeoril, sure if you want
<aeoril> darkxst I was thinking I could do that to verify it createst he same --version output as the /usr/bin/vi on vivid (it did so using the trusty command line on trusty) then try compiling the trusty source on vivid with the vivid command line to see if it failed or worked.  If it works, I would think it points to a build environment bug not a code related bug ...
<aeoril> anyway, I am going to bed.  Good night
<darkxst> night
<mitya57> pitti: On https://jenkins.qa.ubuntu.com/view/Vivid/view/AutoPkgTest/job/vivid-adt-yade/41/, both i386 and amd64 are successful, but the "global" build is marked as failed
<mitya57> Where can I see the reason for failure?
<pitti> Good morning
<pitti> mitya57: yeah, jenkins fail :( I had lots of fun with that yesterday already, I'll sort out the rest today (hopefully the queue has caught up)
<darkxst> hey pitti
<pitti> hey darkxst, how are you?
<darkxst> pitti, good, but hiding from the heat again
<mitya57> pitti: jenkins says it's fixed now, thanks!
<dholbach> good morning
<LocutusOfBorg1> hi all
<yousry> Hi?
<LocutusOfBorg1> dholbach, hi, do you plan to look at the tcl/tk merges I did?
<LocutusOfBorg1> :)
<dholbach> hi LocutusOfBorg1 - today I'm going to be busy with other stuff
<dholbach> can anyone help LocutusOfBorg1 with the merges?
<dholbach> it'd be great in any case if folks could help out with http://reqorts.qa.ubuntu.com/reports/sponsoring/ - we're up to 67 items in the queue!
<LocutusOfBorg1> no problem :) I also fixed a virtualbox 3d graphic bug, if somebody is interested  bug 1351376
<ubottu> bug 1351376 in virtualbox (Ubuntu) "3d is not proper working inside a virtualbox guest" [Undecided,Confirmed] https://launchpad.net/bugs/1351376
<LocutusOfBorg1> I didn't convert in a SRU format, I'm waiting for a prior feedback
<infinity> pitti: Is the gmsh/i386 failure a testbet timeout?
<infinity> pitti: I'm unclear on what it means when qemu is killed.
<infinity> pitti: Ditto for lxc.
<infinity> pitti: And kio
<infinity> pitti: Or is that a log parser that checks the output and then kills qemu?
<infinity> pitti: Ahh, I guess the latter in some cases.  Not sure how I never noticed that's the last line of these logs. :P
<dholbach> awe__, barry: Happy birthday! :)
<alkisg> mvo: hi, did you check if the other 2 bug reports also need sru headers? Do you need help there?
<mvo> alkisg: hi, sorry that we missed each other yesterday
<mvo> alkisg: I looked at this yesterday and one bug is actually wrong in the changelog, so I need to reupload
<alkisg> Ah, ok, do ping me if I can help anywhere :)
<mvo> alkisg: but yeah, help much appreciated :)
<mvo> alkisg: I will!
<alkisg> pitti: could I also help with https://bugs.launchpad.net/gvfs/+bug/453605, e.g. do you want me to mention some specific test case etc?
<ubottu> Launchpad bug 453605 in udisks2 (Ubuntu) "Make default mount umasks configurable" [Undecided,Confirmed]
<alkisg> I believe it only involves changing the dmask numbers to 0022, nothing more...
<alkisg> *err, removing dmask completely, sorry
<pitti> re
<pitti> infinity: yeah, we have a few tests which get stuck and then get killed after the timeout
<pitti> infinity: it took until this morning for jenkins to catch up (and it broke yesterday, too)
<pitti> infinity: I'll sort out the remaining blockers for glibc
<pitti> infinity: there's no log parser; adt-run just kills the test after a timeout
<pitti> alkisg: should be okay, still on my list; just been busy with other stuff so far, sorry
<alkisg> np, thank you
<pitti> infinity: and there's a bunch of KDEish things which are actual regressions (but not from glibc)
<infinity> pitti: I already let glibc in after examining everything by hand.
<pitti> infinity: ah, ok; I just overrode the failed test resultls for glibc
<infinity> pitti: A bit late, it was already accepted. :P
<pitti> infinity: OOI, how did you do this?
<pitti> infinity: hopefully not in a way to let the regressing packages in (like lxc)
<pitti> just glibc specific?
<infinity> pitti: Just let in glibc.
<infinity> pitti: http://bazaar.launchpad.net/~ubuntu-release/britney/hints-ubuntu/revision/899
<pitti> infinity: ah, neat
<infinity> tumbleweed: Gah.  Going through britney hints history.  Don't force packages when they stop producing binaries on an arch!
<infinity> tumbleweed: Either it's a bug that needs fixing, or we can just remove the binary on that arch in the release pocket and it'll slide in without forcing.
<infinity> tumbleweed: Forcing is far too large a hammer, and lets us raise the uninstallable count, etc.  Do not use.
<infinity> tumbleweed: What you've created is a situation where the binaries are out of sync, which we don't want ever.
<Mirv> what's happening on PPA:s.. an armhf build that had been running for 3h and about just finished, now reports it was started 6 mins ago :(
<Mirv> argh
<Mirv> or since those are archive builders, what's happening on those
<Mirv> there was also one silent i386 "failed" build, no log
<ogra_> Mirv, cjwatson talked about a launchpad-buildd update yesterday ... not sure if that could be related
<Mirv> maybe that's it then.
<seb128> wth libtool
<seb128>  /bin/bash ../../libtool   --mode=install /usr/bin/install -c   libgbtgeoclue.la '/tmp/install/usr/lib/gnome-bluetooth/plugins/'
<seb128>  libtool: install: error: cannot install `libgbtgeoclue.la' to a directory not ending in /usr/lib/gnome-bluetooth/plugins/
<seb128>   
<darkxst> seb128, speaking of -bluetooth any progress on bluez5?
<seb128> darkxst, not much, the touch team still have an item to look at their kernel
<seb128> and larsu is going to pick up looking at indicator-bluetooth and unity-control-center
<seb128> since robert_ancell did start on that but let it half done
<didrocks> darkxst: rsalveti is away until tomorrow, I plan to ping him back to get some updates on this (their team has an item for this iteration before feature freeze)
<darkxst> seb128, still on target to land this cycle though?
<diwic> PA 6.0 is not out in a stable release yet
<seb128> darkxst, it's not under my control so unsure about that
<diwic> I was about to release it the other week but then a new discussion about the bluez 5 implementation came around
<didrocks> diwic: but we'll push that version nevertheless, that's what we agreed at vUDS, right? (it's close to be RC)
<darkxst> seb128, probably no one wants to control that mess, hence the delays getting it in I guess
<diwic> didrocks, if you ask me, I think we could push 6.0rc3 as it is into vivid today - the further, the more wide-scale testing we get
<seb128> darkxst, well, in fact supervision has been going fine, it's just identified items that need work
<didrocks> diwic: agreed, and some other distros are shipping it already it seems
<seb128> hopefully that happens before ff
<diwic> didrocks, interesting, which ones?
<didrocks> I guess I saw it on fedora 21
<didrocks> diwic: I need to recheck though
<diwic> ok
<seb128> diwic, is the new pulse depending on the new bluez, or could we already push it?
<diwic> seb128, PA 6.0 supports bluez 4 as well - that said, I think most testing has been done on bluez 5 because that's the new and shiny
<diwic> seb128, but yes, I believe we could push it before the rest of bluez 5 goes in
<seb128> diwic, asked differently, what is blocking uploading pa 6 then?
<darkxst> seb128, ok again probably out of the loop
<diwic> seb128, IMO, nothing really.
<seb128> diwic, just do it then? ;-)
<diwic> seb128, agreed. Just want to sync that up with Luke first
<cjwatson> Mirv: The buildds will have been restarted this morning for upgrades, indeed.  Sorry for the inconvenience.  I'd asked that I be around for the non-virt upgrades but that apparently didn't happen
<darkxst> seb128, my timezone is pretty whacko compared to all else except robert
<seb128> darkxst, yeah, I know
<cjwatson> (When I'm around, I try to take care to schedule the upgrades around long-running builds)
<seb128> darkxst, in that case robert_ancell was the one that needed nudging, he started on porting the indicator and u-c-c, but he stopped and that was stalled work for a while
<seb128> darkxst, it has been handed over to larsu now though
<darkxst> seb128, ok, maybe we could setup a short Ubuntu GNOME meeting each week?
<seb128> darkxst, up to Ubuntu GNOME to decide if you guys want a meeting I guess?
<darkxst> seb128, Well I and Jackson can't attend the ubuntu-desktop meetings
<seb128> darkxst, you can read the log and comment the next day or on the list if you want
<seb128> but sure, having a small meeting in the european morning would work as well
<darkxst> and seems pretty regularly left out of the loop
<darkxst> seb128, logs fade away, meetings would probably be far easy easier
<seb128> what would be the goal of the meeting?
<seb128> you don't want to move the main ubuntu-desktop meeting right?
<seb128> but add a smaller one/with a different set of people?
<darkxst> seb128,  unless you want to move the ubuntu-desktop meeting ;)
<seb128> we don't
<seb128> we have U.S team members
<seb128> well, up to willcooke I guess
<darkxst> seb128, mainly to keep us posted on things, mostly updates are not communicated back to our team, unless we are working on the packages
<darkxst> bluez5, nm 0.9.10, etc
<seb128> well, you could as easily the log from the main meeting
<seb128> not sure what's the point to make people join another meeting to repeat the same info
<seb128> when you can browse through the log
<darkxst> seb128, likely because we may have different questions
<seb128> darkxst, you can ask question any day on #ubuntu-desktop though
<seb128> well, if you think a meeting would be useful just set up one
<seb128> I'm happy to join and we can see if it's turn out to be useful or not
<seb128> if it's not we can still dismiss
<darkxst> seb128, ok I will check with the others
<pitti> jamespage: hm, the nova autopkgtest regression appears to be real
<jamespage> pitti, yeah - looking at that - probably eventlet related - I just bumped a new version in
<jamespage> pitti, that may resolve itself with the kilo-2 release we're working on
<pitti> jamespage: yes, that's what britney blames it on (http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html)
<willcooke> seb128, happy for there to be a Ubuntu Gnome meeting, but I would rather not move the Desktop Weekly, not least because my other meetings are around it and finding a new slot would be hard
<barry> dholbach: thanks! and awe__ hbd my 2-10 bruthah!
<RichiH> as upstream and debian package maintainer, what's the best way to get https://bugs.launchpad.net/ubuntu/+source/vcsh/+bug/1352280 fixed?
<ubottu> Launchpad bug 1352280 in vcsh (Ubuntu) "typo when setting default VCSH_HOOK_D" [Undecided,New]
<cjwatson> RichiH: if you fix it in the next nine days or so in unstable it'll autosync into vivid.  if you want to help fix it in stable releases too, that's https://wiki.ubuntu.com/StableReleaseUpdates
<cjwatson> oh, I see it's already fixed in vivid?
<cjwatson> (unstable)
<cjwatson> so just the SRU page above then
<RichiH> cjwatson: yah, it's been fixed for some time now
<RichiH> SRU =~ backports?
<rbasak> RichiH: no, it's a stable release update. For bugfixes, rather than feature backports. It'll end up in trusty-updates and users generally receive these updates automatically.
<RichiH> ok, that seems to fall under "Bugs which do not fit under above categories, but (1) have an obviously safe patch and (2) affect an application rather than critical infrastructure packages (like X.org or the kernel).Bugs which do not fit under above categories, but (1) have an obviously safe patch and (2) affect an application rather than critical infrastructure packages (like X.org or the kernel)."
<rbasak> RichiH: yeah - it should be fine to SRU that I think. See the Procedure section. I'll do step 4 for you now.
<cjwatson> RichiH: analogous to stable updates in Debian
<RichiH> cjwatson: yah; only simpler to get into
<Saviq> cyphermox, hey, I still can't pair with my car (bug #1362694), can I get any debug info to help fixing that?
<ubottu> Error: Launchpad bug 1362694 could not be found
<Saviq> huh, bug private?
<Saviq> bug #1362694
<ubottu> bug 1362694 in bluez (Ubuntu) "Can't pair with car kit (reverse mode)" [Undecided,New] https://launchpad.net/bugs/1362694
<Saviq> better
<cyphermox> Saviq: just make sure to add /var/log/syslog (with debug logs from bluez if possible, that's done by adding -d to the command line for bluetoothd), and the logs from ubuntu-system-settings
<Saviq> cyphermox, ok, I'll do that now
<slangasek> tkamppeter: wasn't so much around, no.  did you still need something from me?
<seb128> slangasek, hey
<seb128> slangasek, since you are around, I'm curious on what's the status of the systemd transition?
<tkamppeter> slangasek, can you reject the CUPS package for the Trusty SRU of bug 1386241, so that the Trusty SRU of bug 1352809 can be done first? Thanks.
<ubottu> bug 1386241 in system-config-printer (Ubuntu Trusty) "Add the full IPP Everywhere support from Utopic to Trusty" [High,Triaged] https://launchpad.net/bugs/1386241
<ubottu> bug 1352809 in cups (Ubuntu Utopic) "/usr/bin/lp on Trusty using -h option doesn't work as expected" [Medium,In progress] https://launchpad.net/bugs/1352809
<yousry> Hi
<slangasek> seb128: hi!  status should be all in the blueprint; the outstanding blockers that I'm aware of are console-setup+initramfs-tools merge and nfs-utils systemd support
<slangasek> seb128: https://blueprints.launchpad.net/ubuntu/+spec/core-1411-systemd-migration
<seb128> slangasek, do you know if anyone is working on those?
<seb128> slangasek, nfs-utils seems assigned to you :-)
<slangasek> seb128: I'm working on the first one, the second is in the "backlog"
<seb128> how is that work going? ;-)
<slangasek> seb128: it will be done this week
<seb128> slangasek, great to read, thanks!
<yousry> Is this the right place to ask a question about app-store submissions?
<Mirv> cjwatson: arm64, powerpc and ppc64el builds aborted by itself now. and arm64 for the second time too. just FYI, I'm EOD. https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-005/+build/6963104
<Mirv> I got the previous package fully built, though, so mostly good
<Mirv> but telling just in case it was thought any buildd upgrades were finished and working
<Mirv> amd64, armhf and i386 seem to so far work
<Mirv> wow, the queues are in tens of thousands of jobs
<cjwatson> infinity: Are you upgrading the arm64 and ppc64el builders at the moment?
<cjwatson> Mirv: There's a test rebuild in progress, hence the high job count.
<Mirv> ok, right
<cjwatson> infinity: If not, you might want to look into the above.  All I can see is that buildd-manager got BUILDERFAIL from the slave.
<cjwatson> But e.g. templar is apparently still up.
<cjwatson> Mirv: All the test-rebuild build records are scored <0, so anything real will be dispatched first.
<cjwatson> I wish I had a way to get the raw build slave log.  OTOH that will become useless once everything's in scalingstack anyway ...
<yousry> Can I upload a deb-package instead of a deb-src package to the app-store? It seems that your dpkg-shlibdeps script fails to recognize the -l (-ldirectory) option for packed libs.
<ogra_> yousry, no, the ubuntu archive only allows source packages
<yousry> Is there a workaround for the missing -l option in dpkg-shlibdeps? I don't see another pssibility to indicate internal (packed) libraries?
<pitti> yousry: I don't understand this; what should that option do and why is it missing?
<Unit193> Perhaps he should be looking into d/control deps line?
<pitti> yousry: if your package has internal libs, they must not have shlibdeps; and if it has external libs they shoudl be in the proper search dirs?
<pitti> besides, it does have an -l option
<yousry> pitty, I got this feedback from the reviewer: dpkg-shlibdeps: unknown option `-ldebian/memorytheminorplanets/opt/memorytheminorplanets' but this option works on my system.
<yousry> pitti, also I only reference systemlibs with shlibdeps
<yousry> pitti, I just checked the script source-code. I found this option and cannot understand why the revierer got this error message.
<pitti> yousry: I don't either; but why do you need shlibdeps in the first place?
<yousry> pitti, I followed the debian docs. I referenced vorbis, alut and some other libs.
<cjwatson> infinity: Hm, might have been a network glitch.  We got builderfail from most of 1SS at the same time.
<rbasak> Minified JS without original source is still unacceptable in a source package and the source package must be repacked in this case, right?
<rbasak> Also, is it a hard requirement to use libjs-jquery instead of an upstream shipped jquery? I can't find any reference to this to point someone to. Is there one, please?
<pitti> rbasak: lintian complains about that
<pitti> rbasak: depends on the license
<rbasak> Ah, thanks. I see the tag description refers to policy "Convenience copioes of code".
<pitti> rbasak: GPL and similar require including the preferred form of modification
<rbasak> Which is a should, not a must.
<pitti> rbasak: BSD and similar don't, for those you can ship any binary crap you like
<pitti> it's not "nice" of course, but at least technically accepted by the license
<rbasak> This is for jquery, which I think is BSD-alike.
<rbasak> I just want to know what to require from a contributor before I upload.
<pitti> code copies are generally frowned upon by archive admins regardless of the license
<rbasak> Understood, and I can relay that. I was hoping for a hard policy requirement as it's easier for me to require it fixed then, but it does help that you confirmed it will be flagged - thanks.
<tumbleweed> infinity: I *did* wonder what people would think :P (and was careful not to break anything, except requiring NBS cleanup). Next time I'll request archive-admin arch-specific removal
<Odd_Bloke> Where is the ubuntu-core task used in http://bazaar.launchpad.net/~ubuntu-core-dev/livecd-rootfs/trunk/view/head:/live-build/auto/config#L361 defined?
<pitti> tjaalton: btw, did anything come out of your investigation how to drop libopenvg1-mesa-dev from qtbase-opensource-src{,-gles}?
<pitti> (or reintroducing openvg if Qt/KDE/touch wants it)
<tjaalton> pitti: no it's gone upstream, those pkgs just can't build against it anymore
<tjaalton> did I not upload fixes?
<pitti> apparently not :)
<tjaalton> hrm
<pitti> tjaalton: dropping the build deps should technically work (it's [!hurd]), configure detects its presence; I just don't know what kind of functionality this brings (or loses, rather)
<tjaalton> nothing should use it aiui, it's just extra
<tjaalton> changelog didn't mention why it was enabled
<tjaalton> other than upstream adding support for it
<pitti> tjaalton: ah, good
<tjaalton> svuorela from debian is aware of this too
<tjaalton> so it should get fixed there soon, if not already
<hallyn> arges: is systemd safe to assume to be installed on all systems?
<hallyn> arges: oh, nm.  i see you're checking for it
<arges> hallyn: no. that's why I check for it; but i didn't want to dep on it
<hallyn> hm, so what about dmidecode?
<arges> hallyn: yea i'm not depping on that either... if that command fails though it just doesn't detect if we are on a VM
<tjaalton> will systemd get enabled before FF, or can a pkg depend on it being pid 1?
<arges> hallyn: well unless it catches it on dmesg
<hallyn> tjaalton: that would be the systemd-sysv package;  i'm only looking for systemd
<hallyn> arges: well ubuntu-standard depends on dmidecode.  is ubuntu-standard on all our flavors?
<tjaalton> hallyn: yeah that was a general question :)
<hallyn> (i agree it's "ok" if it's not installed the way you have it; jus ta bit fugly)
<hallyn> tjaalton: i suspect it'll be after FF that it gets enabled by default
<arges> hallyn: i mean... technically one could install ubuntu-minimal or other flavors...
<hallyn> tjaalton: there are still a few blockers, including juju
<arges> hallyn: so we could add another check for that command
<tjaalton> and nfs-common
<hallyn> right
<tjaalton> it's the only blocker for syncing freeipa
<hallyn> oh, the other thing, is VM_SEARCH##*$vm_string* a bash-ism or ok in dash?
<arges> hallyn: i tested iwth /bin/sh, but I need to check if my env has bash set or not
<cjwatson> hallyn: portable
<hallyn> cool, thx
<hallyn> heh actually it'd be saner for me to ask smoser to look at it than me to try to :)
<hallyn> arges: yeah should be fine a sis;  i'll take the patch as is now unless you are dying to make a change
<arges> hallyn: no. I think it will work for now. let's let it bake into vivid for a bit before thinking about SRUs
<rbasak> install: error writing â/tmp/adt-virt-lxc.shared.vo8ox3o3/downtmp/build.t2I/mysql-5.6-5.6.22/debian/tmp//usr/lib/mysql/libmysqld_pic.aâ: No space left on device
<hallyn> arges: ok, doing one more test build in ppa:ubuntu-virt/candidate (all tests passed this morning) then pushing to archive
<rbasak> pitti: ^^ any chance I can get it to use something other than /tmp? TMPDIR?
<rbasak> pitti: I'm not sure that /tmp is suitable for multi gigabytes of stuff. Current working directory would be better maybe here. Debatable I guess.
<rbasak> In this case apparently 3.9G isn't enough.
<rbasak> TMPDIR didn't seem to work.
<rbasak> My mistake. TMPDIR does work if it exists.
<slangasek> tkamppeter: bug #1352809, the package was already removed from trusty on Dec 12 per your request and this is documented in the bug...
<ubottu> bug 1352809 in cups (Ubuntu Utopic) "/usr/bin/lp on Trusty using -h option doesn't work as expected" [Medium,In progress] https://launchpad.net/bugs/1352809
<slangasek> tkamppeter: sorry, I mean bug #1386241
<ubottu> bug 1386241 in system-config-printer (Ubuntu Trusty) "Add the full IPP Everywhere support from Utopic to Trusty" [High,Triaged] https://launchpad.net/bugs/1386241
<alexbligh1> rbasak, any movement on https://bugs.launchpad.net/ubuntu/trusty/+source/apache2/+bug/1366174 ? Any chance of the fix getting merged for 14.04.2?
<ubottu> Launchpad bug 1366174 in apache2 (Ubuntu Trusty) "apache2 SEGV with multiple SSL sites" [High,Triaged]
<rbasak> alexbligh1: I think I'll have time in the next few days, but with everything going smoothly I don't think it'll get through SRU verification in time to make 14.04.2, sorry.
<rbasak> alexbligh1: I'm not sure it should matter that much though. Users would update apache2 from trusty-updates, no?
<alexbligh1> rbasak, well, the sooner the better. My concern is more that if 14.04.2 has other fixes in for apache2, my fixed version is going to get overwritten on customer sites.
<alexbligh1> rbasak, is there some way to find out if other stuff is queued?
<rbasak> alexbligh1: https://launchpad.net/ubuntu/+source/apache2 will show you current status.
<rbasak> alexbligh1: http://people.canonical.com/~ubuntu-archive/pending-sru.html shows you SRUs in flight. Normal updates will be on this page for at least seven days before landing in trusty-updates.
<lamont> how many times are we planning to break upgrades for python-oslo packages?
<smoser> hallyn, what did you need from me ?
<rbasak> alexbligh1: security updates are probably your biggest risk, since they go through urgently, often without warning (responsible disclosure, etc)
<smoser> lamont, 2 more. but thats it. :)
<lamont> smoser: Lp
<smoser> i'm happy to know that i'm not the only one using vivid and upgrading daily.
<rbasak> alexbligh1: but that's outside the 14.04.2 and other point release milestones, really. The point releases are mainly about the installer, and what users get before they update.
<alexbligh1> rbasak, ok so the first one shows 2.4.7-1ubuntu4.1 is the latest version (as per packages.ubuntu). The second shows no SRUs pending for apache. So I just need to worry about security updates, and 14.04.2's release adds/removes nothing there?
<hallyn> smoser: was going to ask you to look at https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1414153/+attachment/4315925/+files/lp1414153-vivid.debdiff , but i've gone ahead and taken it, so nm
<ubottu> Launchpad bug 1414153 in qemu (Ubuntu) "qemu should not enable KSM on nested guests" [High,In progress]
<hallyn> smoser: i've always been on the release distro;  except i've been on crappy networks this cycle so couldn't afford the updates.  so i'm on utopic :(  i'll upgrade this afternoon
<rbasak> alexbligh1: correct. 14.04.2 will only include what is already published in trusty-updates and trusty-security at the time the release is rolled.
<smoser> hallyn, my comments there...
<smoser> a. dmesg can't be relied upon for anything dude to buffer.
<smoser> dmidecode is likely to be dropped (its not in snappy) in favor of /sys/class/dmi
<smoser> VM_SEARCH##$vm_string*
<smoser> probably doesnt need the last '*' . i think that can only mess things up.
<hallyn> arges: ^
<smoser> and then the other thing, is that i would never bohter with full paths on checcking for executables.
<smoser> (and i think doing '-f /usr/bin/systemd-detect-virt' is bad logic anyway, you'd want '-x')
<alexbligh1> smoser, hallyn  - and whilst I look at this, why the need for sudo in a .postinst? (for my own interest)
<hallyn> uh, none
<smoser> that is odd, isnt it :)
<arges> this is good feedback
<hallyn> thanks gusy
<hallyn> guys
 * hallyn biab
<smoser> but my full path argument i think is probably not really valid. as i think lots of debian things hard code paths for whatever reason
<smoser> (even though PATH is safe in an upstart script)
<arges> smoser: so I can just remove the dmesg checking... but the biggest issue is that vm detection is just spotty.. so i'm trying a few things to get a reasonable idea if we're running in VM
<smoser> yeah. i know.
<smoser> i guess it doesn't hurt.
<arges> smoser: i'll drop dmidecode to use /sys/class/dmi/*
<arges> that seems like an easy fix
<alexbligh1> Also: sed -i 's/KSM_ENABLED=1/KSM_ENABLED=0/' /etc/default/qemu-kvm;
<alexbligh1> ^- isn't that going to mean if you upgrade qemu later, it's not going to upgrade the conffile?
<smoser> yeah.
<arges> alexbligh1: so this is the issue i have...
<alexbligh1> You might be better changing the init script to work this out rather than modify the /etc/default ...
<smoser> right.
<arges> i want to change the default /etc/default/qemu-kvm before the daemon restarts
<smoser> i tihkn he's right.
<smoser> change the init script (is there one ?)
<smoser> to do the right thing.
<arges> so if I change the upstart script, it just checks the /etc/default/qemu-kvm configuration
<arges> to determine if KSM should be enabled or not
<smoser> the rason being, if we built an image on bare metal and then ran the image in a vm, your logic is not used
<smoser> and vice versa
<arges> presumably a user could modify that on their own too
<smoser> ie, fast path install takes a cloud image, built in a kvm vm
<alexbligh1> arges, what I'd suggest is override the value of KSM_ENABLED if you discover (in the init script / upstart script) you are on a VM.
<smoser> and spits it to disk on a "real hardware"
<smoser> and it'd have your bad value of off. when youd' want it on.
<smoser> i agree with alexbligh1
<arges> alexbligh1: see that seemed bad to me... then what if a user actually wants KSM enabled in their nested VM?
<smoser> not override it by runtime logic.
<smoser> er....
<smoser> allow the user to turn it on or off or 'auto'
<smoser> and default 'auto'
<arges> is there a way i could modify etc/default/qemu-kvm _before_ it gets installed?
<alexbligh1> arges, OK, then add KSM_ENABLED_IN_VM=0 as a default in /etc/default/qemu-kvm, and if you find you are running in a VM, set KSM_ENABLED to KSM_ENABLED_IN_VM
<alexbligh1> arges, or just change the code that looks at KSM_ENABLED to look at KSM_ENABLED or KSM_ENABLED_IN_VM as appopriate
<arges> hmm
<arges> I think having KSM_ENABLED='auto' might make sense as smoser suggested. Then 'auto' is let the init script decide, otherwise respect the value set there
<arges> it seems a bit 'cleaner'
<tkamppeter> slangasek, but I do not succeed to upload the package of the new bug (which has the same release number). Should I simply bump the number by one?
<alexbligh1> arges, that also works.
<arges> smoser: alexbligh1 thank you both for the feedback. I'll work on v2 today : )
<slangasek> tkamppeter: yes, you can't reuse a version number once it's been in the archive.
<hallyn> smoser: will /sys/class/dmi be supported in precise's kernel?
<tkamppeter> slangasek, thanks, I will re-upload with a new version number.
<hallyn> arges: eta on your patch?  < 3 hrs?
<arges> hallyn: i could prioritize it
<hallyn> arges: just trying to decide whether to push as is or wait for it
<tkamppeter> caribou, I hace uploaded the Trusty SRU now, as cups 1.7.2-0ubuntu1.4. I had to bump the release number, as 1.3 was already used by another withdrawn SRU.
<tkamppeter> slangasek, with bumped version number the upload worked. Thanks.
<arges> hallyn: no don't push the version i have wait for v2
<hallyn> arges: ok (i could've pushe dit without your v1 :)  but i'll wait, thx)
<arges> hallyn: actually go ahead and push without my change, i'd rather not be hasty about this change
<hallyn> arges: ok.
<aeoril> darkxst sarnold cjwatson I am going to go ahead and make an sbuild environment on a new virtual machine at this point.  I need to learn that skill anyway, and I think for this bug in particular it is important to have a build environment as close to that as was used in the release builds, which the docunentation says is one plus of sbuild
<aeoril> I think it will also make my testing go faster once I have set it all up, and not be all gunky
<sarnold> aeoril: feel free to make hte sbuild environment on your 'nice' machine in a permenant spot
<aeoril> sarnold I am going to make a new virtual machine for it - it will become my "nice" machine.  I assume I can use trusty and still build for other environments, like 14.10 and 15.04?
<aeoril> that is the whole point, isn't it?
<sarnold> aeoril: yeah, my trusty laptop does builds for lucid, precise, trusty, utopic, vivid, no trouble :)
<aeoril> sarnold yes, that sounds great - I like the double entendre there "my trusty laptop ... " :)
<sarnold> aeoril :D
<robert_ancell> bdmurray, hey, the unity-greeter SRU is being held up due to "increased daily rate of errors". Looking at e.u.c the only significant errors I can see are https://errors.ubuntu.com/problem/5cb4c18c3fc57c4a33a0a31461bef0cc992a7f0b and https://errors.ubuntu.com/problem/7a0ce14fab00948fce6fe9a4f17cf9947b4d6fe1. I think these are existing problems that haven't increased since the update. Is there anything else I might have missed?
<bdmurray> robert_ancell: that has started phasing again
<robert_ancell> bdmurray, oh, thanks!
<aeoril> sarnold I have an older PC running trusty - I can blow it away and make it my "nice" machine - would that be better than a vm for long-term development?  It cannot support vms because it is older hardware, but I do not think I need to worry about that for an sbuild environment, do I?  Also, not sure which is best to test on - older hardware on bare metal or newer hardware in vms ... I
<aeoril> guess I could set up both, really, not either/or
<sarnold> aeoril: depends how often you want to build things; I want it on my best build box because I build things often.
<aeoril> sarnold I hope to do a lot of development for Ubuntu, so I would be building often.  But, I must support my wife with my main unfortunately at this time so it is not available for an Ubuntu build environment (I cannot "play" with it except in vms) ...
<RichiH> rbasak: just so i understand what you did in https://bugs.launchpad.net/ubuntu/+source/vcsh/+bug/1352280 : you simply pulled in a fixed version from another release?
<ubottu> Launchpad bug 1352280 in vcsh (Ubuntu Trusty) "typo when setting default VCSH_HOOK_D" [Undecided,New]
<aeoril> sarnold I will go ahead and learn sbuild on a vm on my main so I can easily work through making mistakes, then go ahead and worry about doing it on my regular trusty PC if/when I need to
<sarnold> aeoril :)
<aeoril> sarnold btw, vmware is fantastic ...
<aeoril> sarnold pm?
<sarnold> aeoril: sure
<brendand> anyone seen Xorg crashing whenever chromium/chrome are launched? this is on vivid with the latest kernel. intel haswell graphics
<brendand> gah - habitual clicking on chromium...
<sarnold> brendand: you didn't miss anything while you were gone
<ahoneybun> balloons:  how often should I test the vivid next images?
<balloons> ahoneybun, if you are interested in following along on a regular basis you have a couple options. You can use the lxc container and update it, or you can run vivid and install the packages (and update vivid)
<balloons> ahoneybun, as far as how often, that depends on what you are after. If you want some larger changes between each test you'll need to wait longer ofc.
<ahoneybun> balloons: I dont see any updates in the system settings
<balloons> ahoneybun, right, you have to update it via https://wiki.ubuntu.com/Unity8inLXC#Maintaining_your_unity8_installation
<ahoneybun> balloons: cool the main issues are touchpad and resizing but I imagine those are in the pipes already
<balloons> ahoneybun, touchpad?
<ahoneybun> yea it was on a laptop balloons
<ahoneybun> bbl
<balloons> yes, I meant what issues? did you file a bug?
<arges> hallyn: ok v2 is posted bug 1414153
<ubottu> bug 1414153 in qemu (Ubuntu) "qemu should not enable KSM on nested guests" [High,In progress] https://launchpad.net/bugs/1414153
<hallyn> arges: ok, thx.  i shoulda waited then :)  will wait to look at it tomorrow
<arges> hallyn: take your time. i'd rather not screw it up
<rbasak> RichiH: no, I just updated the bug status to represent that it is fixed in Vivid, but not in Trusty. That's what I understood from what you said?
<cjwatson> pitti: FYI Distribution should now be accurate in ddebs.txt: https://bugs.launchpad.net/launchpad-buildd/+bug/1348077
<ubottu> Launchpad bug 1348077 in launchpad-buildd "buildd slave config hardcodes --archive=ubuntu" [High,Fix released]
<cjwatson> Probably too late to matter, but :)
<rbasak> RichiH: you'll still need to follow the other steps in https://wiki.ubuntu.com/StableReleaseUpdates#Procedure please. It's easier for you to do it since you know the package.
<tkamppeter> I have a question about whether a package is in Main or in Universe. I is openjpeg. On https://launchpad.net/ubuntu/+source/openjpeg it says "Component: Main" but for the individual releases (for Vivid, Utopic, ...) it says Universe. What is correct? And if it is in Universe, what does the "Component: Main" at the top mean?
<dobey> tkamppeter: apt-cache policy says universe on trusty
<dobey> tkamppeter: maybe it's approved for main, but nothing ever seeded the binaries?
<sarnold> tkamppeter: I believe 'rmadison -S openjpeg' is the best way to discover which binary packages are in main vs universe
#ubuntu-devel 2015-02-11
<infinity> tkamppeter: Component on that page lists the component from debian/control, which is a bit confusing.
<infinity> tkamppeter: If you scroll down, you see it's in (universe) in the release pocket of vivid, etc.
<tkamppeter_> infinity, thanks, it is all in universe. So the "Component: Main" on Launchpad means perhaps that in Debian it is in Main? Has this an advantage for a MIR for Ubuntu?
<infinity> tkamppeter_: It's just that, yes.  It's in main in Debian (or, in the control file).  That has no bearing on an MIR.
<infinity> wgrant: What are the odds of making the Component field of +source/<package> either less confusing or not there at all?
<wgrant> infinity: I think I filed a bug about that in 2006, let me see.
<infinity> wgrant: This isn't the first time people have misinterpreted it.
<infinity> Heh.
<infinity> wgrant: I guess I would argue that the package info up there should all represent current reality and overrides in the current devel series, or just not be shown at all.
<wgrant> Ah, not quite.
<wgrant> https://bugs.launchpad.net/launchpad/+bug/93293
<ubottu> Launchpad bug 93293 in Launchpad itself "Details in source package portlet don't change without new upload" [Low,Fix released]
<wgrant> Was nwhat I was thinking of.
<wgrant> The portlet was fixed, but it made a reappearance in the main content, it seems.
<infinity> wgrant: \o/
<infinity> wgrant: Hrm, it's not always wrong, either.  That's even more confusing.
<wgrant> infinity: It should usually be wrong.
<infinity> wgrant: Looking at, say, poppassd, it displays universe, when I would have assumed it would say main (matching control).
<infinity> wgrant: But I guess a poke at the code and where it's actually getting that value would be enlightening.
<wgrant> infinity: Uploaded packages will show their original overrides.
<infinity> wgrant: poppassd and openjpeg are both syncs, AFAICT.
<infinity> wgrant: Oh, but poppassd predates syncs being a thing, so it's technically a manual upload.
<wgrant> Yep.
<infinity> s/syncs/copies/
<hallyn> infinity: hey, perhaps stupid question - are there cases (funky ld.so) where, when /sbin/foo is linked against libwhozit, libwhozit won't actually be read until it's needed?
<infinity> hallyn: No.
<sarnold> I thought that was default behaviour unless you set LD_BIND_NOW in your environment
<infinity> hallyn: Unless by "linked" you mean "dlopened()".
<sarnold> ohhh, that's just symbol resolution, not opening the libraries themselves.
<infinity> sarnold: Yeah, I was in the middle of typing that, and my WiFi had a fit.
<infinity> hallyn: ld.so loads all the objects it needs before jumping into the binary.
<infinity> hallyn: Key word being "needs", if there's no NEEDED entry in your ELF header (ie: your binary is incorrectly linked, or underlinked, or whatever), then no load for you.
<infinity> hallyn: Perhaps a real life example of the behaviour you think you're seeing and blaming on ld.so?
<hallyn> infinity: oh no i'm not seeing anything.  cgmanager needs to umount any dirs it doesn't need.  I'm trying to tell whether there's any reason to fight umounting /lib (if anyone has it as a mount)
<hallyn> i was worried someone might have a custom ld.so that loaded on-demand.  Though I guess I'm not sure how it *could* possibly do it
<hallyn> and yeah we're not dlopening so that's not an issue
<infinity> hallyn: /lib can't be a mount in any sane POSIX system.
<infinity> hallyn: Except in the case of a merged /usr, where it can be a symlink into /usr/lib, but then /usr/{lib,bin,sbin} need to follow the same "all on one FS or you're a moron" rule that / classically did.
<hallyn> infinity: so long as initramfs mounts it i see no reason why it oculdn't
<hallyn> i'm not sure wht "merged /usr" means.  in caes of separate /usr, i'd expect if anything /usr/lib -> /lib, not ht eother way around ,else you couldn't boot :)
<hallyn> this is going into debian, so i expect to see all sorts of perverse setups :)
<hallyn> infinity: thanks, so it sounds like i can ignore it.  good news
<infinity> hallyn: Sure, you could have an initrd that mounts /lib, /sbin, /bin, which is perverse, but you'd also not umount them until post-shutdown either (ie: by pivoting back into the initrd, or just doing a remount-ro and ignoring them)
<hallyn> infinity: right, but cgmanager is going to umount anything it doesn't need (in a private namespace) after it starts
<hallyn> problem is if the host is MS_PRIVATE, cgmanager starts a new mount namespace and runs in it.  if host then umounts something, cgmanager keeps it mounted in its ns
<hallyn> so the target can't be rmdir'd, and the source isn't totally freed
<hallyn> so i'm thinking of doing https://github.com/hallyn/cgmanager/commit/cef2ea8d89ac329b9ce744266f235bad4d6151ed
<infinity> hallyn: I guess you can't just stop cgmanager before the OS umounts at shutdown? :P
<hallyn> there's actually a number of debian bugs open about this
<infinity> hallyn: Or maybe I'm a bit confused about what's going on.
<hallyn> aufs, xfce, onandon
<hallyn> example: sudo stop cgmanager.  sudo mdir /tmp/serge; sudo mount -t tmpfs tmpfs /tmp/serge;  sudo start cgmanager;  sudo umount /tmp/serge;  sudo rmdir /tmp/serge <fail>
<sarnold> hallyn: does that leak 'line' on the continue statements?
<hallyn> sarnold: don't think so;  getline will reuse it if len is large enough for the next line
<sarnold> hallyn: aha, thanks
<hallyn> oh, heh, but loop exit will
<sarnold> hallyn: and, what's this "recursively umounted entries"?
<infinity> hallyn: Err, kay, I clearly don't get why cgamanager is holding that mount open in the first place.
<infinity> hallyn: Surely systemd doesn't have to do this same crazy "umount the world that I shouldn't have open anyway" thing?
<hallyn> well, if /sys and /sys/fs/cgroup are both mounted and you umount -l /sys/, then /sys/fs/cgroup will be umounted
<sarnold> hallyn: no kidding? :) cool. thanks.
<hallyn> infinity: well systemd mounts / MS_SHARED.  but yes it also had this problem
<hallyn> sarnold: so it'd be no big deal, but i just want to avoid the failure on attempting to umount /sys/fs/cgroup later
<hallyn> infinity: so anythhing which systemd spawns which then unshares mntns and mounte MS_PRIVATE wil hae the same problem
<hallyn> (which cgmanager used to do;  i switched it to MS_SLAVE for them;  that doesnt' for sysvinit though0
<infinity> hallyn: So, you could probably just lazily umount $world in your private namespace, minus the proc/sys bits you know you need, and just let the kernel sort it from there.
<infinity> hallyn: Instead of worrying about if /lib might be on a USB stick on Joe User's weird setup.
<hallyn> infinity: right that's basically what i do.  walking through /proc/self/mountinfo and skipping anything i know i need
<infinity> hallyn: But you don't necessarily even need / :P
<infinity> hallyn: In a merged setup, you might need /usr and not /
<infinity> hallyn: But if you just lazy umount them both, who cares.
<hallyn> what is a merged setup?
<infinity> hallyn: Merged-/usr, welcome to 5 years ago.
<infinity> hallyn: Where /lib, /bin and /sbin are symlinks into /usr, and /usr can be (but usually isn't) a mountpoint.
<hallyn> even so all i really need is /sys/fs/cgroup/cgmanager (which i created) and some target dirs for cgroup mounts, and /proc
<hallyn> suppose i could create an empty dir, copy /sys/fs/cgroup/cgmanager into it, pivot, umount old_root, and proceed
<hallyn> not sure whether that's better
<infinity> hallyn: Right.  And the kernel may or may not let you umount the bits where your libraries came from, depending on its mood and phase of the moon, but lazy solves that.  Well, "solves".
<hallyn> right, i'm doing lazy, cause i don't really care ,just don't want to pin it
 * infinity nods.
<hallyn> (my inodes are pinning it already)
<hallyn> hm
<infinity> hallyn: A pivot chroot is probably cleaner than trying to umount everything systematically.
<hallyn> grr but the other way is already coded :
<infinity> hallyn: But if you go full chroot style, you end up with a duplicate libc in RAM, etc, which is less ideal.
<hallyn> :)
<hallyn> why would that happen?
<hallyn> it's still the same inode, same page cache, no?
<infinity> Or, you might.  Depends on how smart we are about knowing that it's identical-but-from-elsewhere and deduping it.
<infinity> hallyn: Oh, I'm thinking an old skool chroot, where it very much wouldn't be the same inode. :P
<infinity> hallyn: If you can sort out something more clever that still frees up /, but gives me the same paged library, you win.  Do that!
<hallyn> yeah i don't need that
<hallyn> cool, something to play with in the morning i think.
<hallyn> thanks!
<hallyn> ttyl
<hyperair> what does upstart --user do that allows it to adopt orphaned childreN?
<hyperair> i thought orphaned children just jump straight to pid1
<infinity> hyperair: Make a decent salary, and have no criminal record.
<hyperair> infinity: :)
<hyperair> that'll work
<infinity> (no idea)
<hyperair> lol
<sarnold> hyperair: check out prctl(2), PR_SET_CHILD_SUBREAPER
<hyperair> aha
<hyperair> thanks
<tmpRAOF> Bah. Kernel ppa doesn't have linux-tools builds :(
<tmpRAOF> No perf for me until reboot.
<RichiH> rbasak: ok, thanks
<pitti> Good morning
<pitti> rbasak: /tmp overflow> ah, you are just setting $TMPDIR in the test itself? (that's a bit ugly indeed); I'm not opposed to adding an option for this
<pitti> cjwatson: ah, thanks anyway, in case we want to ever simplify this again
<alkisg> arges: good morning, could I ping you about putting an update-manager SRU in precise-proposed, if you happen to have some time today?  https://launchpad.net/ubuntu/precise/+queue?queue_state=1 and https://wiki.ubuntu.com/StableReleaseUpdates#Publishing
<infinity> tumbleweed: On a couple of arches, pypy seems to be leaving testsuite cruft lying around in the background, despite the build being complete.  This makes the buildds amazingly unhappy (and I'm going to kill the builds).
<infinity> tumbleweed: Before I kill it, this is the junk hanging around: http://paste.ubuntu.com/10169871/
<rbasak> pitti: no, I'm setting TMPDIR outside the test. "TMPDIR=... adt-run ...". That did work though.
<pitti> rbasak: oh, you mean your host's /tmp is too small, not the testbed's?
<rbasak> pitti: right.
<rbasak> pitti: I'm on Canonistack. / is not that big. /mnt provides more space.
<rbasak> Various things are symlinked to /mnt, but not /tmp.
<pitti> *nod*
<LocutusOfBorg1> hi Laney can I try to merge inkscape from debian/eperimental?
<rbasak> LocutusOfBorg1: there's already a merge bug on that.
<rbasak> LocutusOfBorg1: bug 1416651. Looks like nobody's working on it right now though.
<ubottu> bug 1416651 in inkscape (Ubuntu) "Please merge inkscape 0.91-2 from Debian unstable (main)" [Medium,Triaged] https://launchpad.net/bugs/1416651
<rbasak> I was going to take a look myself next week if nobody gets to it first, because I'd like the newer Inkscape on my desktop :)
<LocutusOfBorg1> wonderful
<LocutusOfBorg1> :)
<LocutusOfBorg1> thanks for the hint, I'll upload the debdiff here
<rbasak> Although I wouldn't do it without checking with someone from the desktop team first, as I'm not so familiar with the desktop side of things.
<LocutusOfBorg1> sure
<LocutusOfBorg1> :w
<LocutusOfBorg1> (damn focus)
<LocutusOfBorg1> now everybody knows I'm a VIM user, shame on me! :wq!
<LocutusOfBorg1> :)
<infinity> LocutusOfBorg1: At least you're not a filthy Emacs user.
<mlankhorst> or maybe he's doing an impersonation of a vim user to hide his emacsness
<LocutusOfBorg1> lol
<LocutusOfBorg1> I stopped using emacs after talking with its psychotherapist
<LocutusOfBorg1> :)
<Laney> LocutusOfBorg1: yap
<pitti> darkxst: uh, apparmor fails to start for you?
<pitti> sudo journalctl -u apparmor
<darkxst> pitti, apparently http://pastebin.com/zqBC4mtu
<pitti> darkxst: hm, that means that it never reaches sysinit.target?
<pitti> ah no, it's a Wants, not a Requires
<darkxst> pitti, doesnt seem like something a glib update would trigger though ;(
<pitti> darkxst: you have several hard disks/drives, would you mind adding your fstab?
<darkxst> pitti fstab http://pastebin.com/Eddi1pia
<darkxst> pitti, pretty sure ricotz hit this also
<pitti> darkxst: I see something odd in the log indeed
<pitti> /home gets mounted, then unmounted again
<darkxst> pitti, why would it get unmounted?
<darkxst> kernel? remounts ro, on errors, but nothing should unmount it? right?
<pitti> darkxst: I don't know yet; I wrote the interesting log excerpt to the bug for now, but I don't fully understand this yet either
<darkxst> pitti, seems my laptop is not effected by this though it has a slightly simpler configuration
<pitti> ok, we have some major kde uninstallability problem on i386
<pitti> ah, https://launchpad.net/ubuntu/+source/plasma-framework/5.7.0-0ubuntu1 FTBFS?
<pitti> and https://launchpad.net/ubuntu/+source/knotifications/5.7.0-0ubuntu1 finished on amd64 but failed on i386 (or rather, is currently rebuilding)
<pitti> I think that's causing it
<aeoril> darkxst sarnold suggested I intall and Sbuild environment then alter the debian/rules file to try to find the nail down the bug in vim ...
<aeoril> And apparently, I cannot type tonight
<darkxst> aeoril, sbuild is great (I use it all the time) but not for tracking down bugs
<Mirv> hey! could a core-dev run: syncpackage -d experimental -r vivid-proposed suomi-malaga  (and yes, I should probably ask for upload rights for my own Debian packages)
<aeoril> darkxst why not?
<darkxst> aeoril, its really slow for one
<Riddell> pitti: I uploaded lots of kde frameworks yesterday
<aeoril> darkxst he was suggesting I use it to build, then alter debian/rules to build a little different, kind of manually "bisecting" until I figured out the bug
<Riddell> pitti: as usual launchpad doesn't seem to be clever enough to do the required retries but I'm running ubuntu-build retry in a while true loop
<aeoril> darkxst yes, the logs on Launchpad show 20 minutes per build
<pitti> Riddell: well, that'd be called "versioned build dependencies" to make it dep-wait properlY :)
<pitti> Riddell: thanks
<Riddell> pitti: we do version them
<aeoril> darkxst do you think I should just manually change the build environment by altering the parameters passed to ./configure from the logs?
<aeoril> *gleaned from the logs
<darkxst> aeoril, that would be much faster!
<aeoril> darkxst I am doing it now ....
<darkxst> aeoril, and really just try what you think is right!
<darkxst> no need to ask my approval ;)
<aeoril> darkxst well, sbuild seems rather daunting right now, so I am going to fiddle with the vivid ./configure command line parameters for now.  See how that goes.  If need be, I can always do sbuild later
<darkxst> sbuild is great for whats its designed for
<Riddell> pitti: if you can offer any insight into why it doesn't know it needs to rebuild them that would be useful, it's a bit nuts that I have to run retry in a while loop
<aeoril> darkxst what is it designed for?
<pitti> Riddell: well, LP never retries failed buildss
<darkxst> aeoril, bilding packages
<pitti> Riddell: it only auto-retries depwaits
<pitti> Riddell: i. e. if your build deps aren't tight enough and your build fails because it's building against a too old -dev package, there's not much you can do on the LP side
<aeoril> darkxst yes, that is why it may be important?  I may need to replicate the Launchpad build processes as closely as possible for this bug troubleshooting ... but twiddle with it as well to nail down the problem ...
<darkxst> aeoril, I do all my dev work in git and jhbuild
<pitti> Riddell: oh I see, it failed due to build dep uninstallability
<Laney> jamespage: yo, is someone looking at the oslo/nova dep8 failures?
<darkxst> then backport to the archive packages (and forward upstream where applicable)
<jamespage> Laney, yes I am
<jamespage> Laney, specifically nova
<Laney> great!
<aeoril> darkxst would jhbuild help me here?
<jamespage> but will work through today
<darkxst> aeoril, jhbuild doesnt work great outside of GNOME
<Laney> thanks
<aeoril> darkxst well, I am fiddling around with ./configure params for nwo - can't hurt - help me learn a bunch too ...
<darkxst> aeoril, in fact it often doesnt work great under ubuntu at all, but they are bugs that need fixing anyway
<darkxst> aeoril, wouldnt bother for a single package
<aeoril> darkxst wouldn't bother doing what?
<darkxst> jhbuild
<aeoril> oh, ok
<aeoril> darkxst thanks ...
<Laney> I use jhbuild okay on ubuntu
<Laney> recommend getting it from git instead of the package
<darkxst> Laney, fedora don't link with --as-needed
<Laney> so?
<darkxst> that creates DSO errors
<darkxst> and then there are usually other Ubuntu specific failures
<Laney> not seen that
<darkxst> but like I said these get fixed upstream
<darkxst> since if not, they would just cause pain when doing the real packaging
<Riddell> pitti: presumably the build dep uninstallability is due to the arch:all data packages being built on 1 arch and not the others?
<pitti> Riddell: right, that's the most common case
<pitti> Riddell: I think infinity has had some auto-detection/retry of this situation on his todo for a long time, but for now there's indeed just the retry button
<cjwatson> Mirv: done
<cjwatson> pitti,Riddell: I'd like to move to using dose-builddebcheck for this kind of analysis, but need to figure out whether it's sensible to put it on the master or the slave end, and how it interacts with PPAs etc.
<Mirv> cjwatson: thanks!
<pitti> darkxst: do you happen to have a rough idea when this mount failure started?
<pitti> darkxst: only with the recent glib update, or did it also happen earlier?
<pitti> darkxst: I can't get this bug in a VM, but I do see it on my laptop indeed
<darkxst> pitti, only with current ubuntu-desktop ppa
<darkxst> goes away if I purge that
<pitti> wow
<pitti> well, it's a race condition, so anything could happen
<darkxst> and/or gnome3-staging but alas that has the same packages copied from there
<darkxst> pitti, not seen in a VM either but then they all have very standard configs parition  wise
<darkxst> where as my desktop has ~4 hdd's most with multiple partitions
<pitti> darkxst: I created a VM with /home, /home/martin, and /srv on separate partitions, just like on the laptop
<pitti> darkxst: anyway, I'll investigate with upstream, thanks
<ypwong> slangasek, could your team help to take a look at Adam's acpi-support patch in bug 1396429? It is affecting some lenovo machines we enable, thanks.
<ubottu> bug 1396429 in HWE Next "[Lenovo ThinkPad ?40 series] Wireless key cannot turn BT off" [High,Triaged] https://launchpad.net/bugs/1396429
<darkxst> pitti, ok, I'm off to bed
<aeoril> is there an easy way to tell the runtime dependencies of a particular binary?
<aeoril> (google found nothing for me)
<xnox> aeoril: ldd ?
<xnox> however it's part of the story, if it e.g. does system() call to some other dependency that would not be listed.
<aeoril> xnox ok, thanks
<aeoril> xnox this also:  objdump -p /path/to/program | grep NEEDED (from the ldd man page)
<xnox> aeoril: same information, different representation. depends on your needs.
<aeoril> xnox ok, thanks again ...
<arges> alkisg: i'll review today
<ogra_> pitti, did one of your last systemd changes add a new user ?
<pitti> ogra_: it added a new group ("input"); we talked about it the other day
<pitti> no new user
<ogra_> pitti, right, i meant afterwards :)
<ogra_> P: Begin executing early chroot hooks...
<ogra_> /etc/group post-debootstrap hash doesn't match record
<ogra_> E: config/hooks/00-uid-gid-fix.chroot_early failed (exit non-zero). You should check for errors.
<ogra_> we have that on both, snappy and touch
<ogra_> one of the packages debootstrap installs has chnaged
<pitti> ogra_: no, it's been ages since it added a new user
<ogra_> right
<pitti> well, that'd be /etc/group again?
<aeoril> what pasting website is preferred here?  paste.ubuntu.com?
<ogra_> just wanted to make sure ... i usually trust your changelogs :)
<ogra_> i simply cant find anything on vivid-changes
<pitti> ogra_: so that /etc/group change does sound like the "input" group?
<pitti> or at least it could be?
<ogra_> it doesnt complain about /etc/group
<pitti> ogra_: or do you get a mismatch on /etc/passwd too? (and is there a diff?
<ogra_> the input group change is long gone in :)
<ogra_> trhere is no diff at that point ... thats my issue
<pitti> aeoril: kind of; it's what pastebinit defaults to in ubuntu; but it doesn't matter much really
<ogra_> (i'll add it but was hoping i could find the obvious change by looking at changes first)
<pitti> ogra_: hm, what do you add then if there's no diff?
<ogra_> i mean there is no diff that gets dumped into the log :)
<ogra_> live-build/ubuntu-touch/hooks/99zz-check-uid-gid.chroot actually dumps a proper diff that shows what you need to change
<ogra_> but i never added the same code to live-build/ubuntu-touch/hooks/00-uid-gid-fix.chroot_early
<ogra_> which is where we fail atm
<ogra_> and before diving into livecd-rootfs to add that code to the 00 script too and do a bunch of image rebuilds to find the issue, i was hoping to find it quicker via changelog entries on vivid-changes
<pitti> ah, I see; sorry, I'm not aware of a recent upload that added a new system user
<pitti> but then again I stopped following -changes@ years ago
<ogra_> (i will add the diffing code there too, but that takes longer than i like :) )
<ogra_> and sadly yesterday was KDE day ... -changes is spammed :P
<Riddell> how do you think I feel? I get all the build failures and I've been running retry --batch all day
<pitti> whack-a-buildd
<ogra_> haha
<aeoril> darkxst sarnold cjwatson Ok, so I went back to square one and seem to have made mistakes before.  Please look at this log of my activities since I started re-troubleshooting the vim bug:  http://paste.ubuntu.com/10173428/ I am thinking that this activity and their results point toward vim not being the problem but either something vim relies on or gnome-terminal.  I am not exactly sure
<aeoril> what I did wrong before, but have been very careful this time to do each step in my troubleshooting correctly.  Not sure what my next step should be.
<aeoril> xterm does not exhibit the same problem in vim on trusty sarnold darkxst cjwatson
<aeoril> rather, vim does not exhibit the same problem in xterm on trusty sarnold darkxst cjwatson
<aeoril> sarnold darkxst cjwatson I think I need to bisect gnome-terminal at this point on trusty to try to see if it is the problem
<cjwatson> aeoril: I'm sorry, I don't think I'll have time to help you with this; could you please not highlight me?
<aeoril> cjwatson sure, sorry to be a bother
<rsalveti> ogra_: pitti: http://paste.ubuntu.com/10174068/
<rsalveti> it seems the systemd users got removed
<rsalveti> was that expected?
<pitti> no, it's not expected
<pitti> /var/lib/dpkg/info/systemd.postinst creates them
<rsalveti> hm
<rsalveti> once the new livecd-rootfs gets published we will trigger another image and see
<rsalveti> but that might be the difference
<pitti> rbasak: so you discovered my s3kr1t way of checking whether anyone actually uses --timeout-factor :)
<rbasak> :-)
<rbasak> I do like the idea.
<rbasak> Timeout -> moar time please
<pitti> rbasak: while I'm at it, I should also add --warp-factor
<rbasak> Don't really care what the previous timeouts wanted.
<rbasak> So it's really tempting to use --timeout-factor over looking up default timeouts and then adjusting them.
<rbasak> And thus I fell into your trap :)
<ogra_> rsalveti, i'm startin a build, seems livecd-rootfs is in
<rsalveti> ogra_: great
<rsalveti> ogra_: pitti: already failed: https://launchpadlibrarian.net/197314114/buildlog_ubuntu_vivid_i386_ubuntu-touch_FAILEDTOBUILD.txt.gz
<rsalveti> and yeah, the same diff I got
<rsalveti> no systemd users
<pitti> rsalveti: what's curious there is that this does upgrade libsystemd-*, but not the systemd package itself; did that perhaps fall off the image?
<rsalveti> yeah, systemd is gone in there indeed
<pitti> (that'd be quite bad -- no logind and such)
<ogra_> rsalveti, but there is also a syslog user we dont have in the reference file
<pitti> no libpam-systemd either
<rsalveti> ogra_: oh, this is not in the end of the build
<rsalveti> so I think systemd would be added later on
<Laney> @pilot in
<ogra_> right
* udevbot changed the topic of #ubuntu-devel to: Archive: open | 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: Laney
<rsalveti> the lack of the syslog user is probably what caused the failure
<ogra_> hmm, no, the order is just different
<ogra_> i guess we need more info :/
<ogra_> the file created in 00-uid-gid-fix.chroot_early is not the one we md5sum
<ogra_> it is the file that needs to match *after* the build
<ogra_> aha
<ogra_> syslog:x:100:104::/home/syslog:/bin/false
<ogra_> vs syslog:x:100:103::/home/syslog:/bin/false
<pitti> bah, just a 0.97% error :)
<ogra_> i assume we just want to update the md5sum
<ogra_> yeah
<ogra_> phablet@ubuntu-phablet:~$ md5sum foo
<ogra_> 9ebb1c3da5b0ad8f1d366528b32c97cb  foo
<ogra_> thats what i get with the syslog user set to 103
<ogra_> phablet@ubuntu-phablet:~$ md5sum foo
<ogra_> 5e8366ef9c178b62079468966f38ce5f  foo
<ogra_> and that with it set to 104
 * ogra_ prepares a fix, but we'll need one more rebuild for /etc/group i guess
<xnox> kees: should chromeos switch to systemd?
 * xnox is mostly done with porting ubuntu
<rsalveti> ogra_: yeah, that might be the issue
<ogra_> rsalveti, change uploaded ... lets see if thats sufficient ... but i guess /etc/group will need updating too
<rsalveti> ogra_: we can keep going until we get a new image :-)
<ogra_> yeah
<ogra_> and improve the error output with each run
<ogra_> to make it easier next time
<rsalveti> yeah
<ogra_> i guess i should also log the expected md5
<ogra_> (i only added the computed one to this upload to be logged)
<Odd_Bloke> ogra_: I've been making changes to livecd-rootfs for our CPC builds; it would be good to get those changes merged in.
<ogra_> but it might be moot since you have to edit the source anyway
<Odd_Bloke> (If only so I don't have to rebuild the package in our PPA every time you bump the version :p)
<ogra_> juts make an MP :)
<ogra_> so someone can review :)
<Odd_Bloke> ogra_: Cool, will do.
<didrocks> rsalveti: hey, how are you?
<didrocks> rsalveti: I was coming to the new about the bluez5 Touch enablement. We are mostly done on the desktop side and don't want to miss FF. I saw that it's in your team scrum cycle iteration, but can I get some more details so that we are aligned?
<rsalveti> didrocks: we're working on getting our kernels to be compatible with it still, ricmm is actively working on that
<didrocks> rsalveti: do you think this will be done before Feature Freeze?
<rsalveti> didrocks: what is the date for FF?
<didrocks> rsalveti: Thursday 19th if I'm right
<didrocks> rsalveti: so a week + 1 day :)
 * didrocks rechecks the schedule
<rsalveti> didrocks: we hope so
<rsalveti> we're actively working on it, so should know more by the beginning of next week
<didrocks> rsalveti: mind if we sync up like next Tuesday then?
<rsalveti> sure
<didrocks> thanks a lot! good luck to you and ricmm :)
<tumbleweed> infinity: urgh. I've seen that before
<tumbleweed> I guess I could disable that test
<awe_> cyphermox, hey could you give me a hand with a Debian packing problem I'm having?
<cyphermox> awe_: sure, what's up?
<cyphermox> if you describe the problem here, if I can't help then others surely will be able to :)
<awe_> cyphermox, one sec
<awe_> cyphermox, so I have a library package that also includes a binary
<awe_> debuild is failed on the shlibdeps step
<awe_> because it can't find the library bundled in the package, that the binary references
<awe_> so I added an override for dh_shlibdeps that specifies -l <dir> to try and pickup the library directly, but it's still failing
<Mirv> mitya57: sure go ahead!
<awe_> cyphermox, http://pastebin.ubuntu.com/10175843/
<cyphermox> awe_: what's the exact error before you override dh_shlibdeps?
<cyphermox> could that binary be split out to a -utils package or something?
<awe_> it's part of the -dev package
<awe_> here's the git tree: https://github.com/tonyespy/libiodata
<awe_> so context, this is a library pulled from Sailfish
<awe_> and originally part of MeeGo/Moblin/Maemo
<awe_> and it's debian dir was seriously out-of-date
<awe_> the error I get is can't find the libiodata.so.0
<cyphermox> what is /usr/bin/iodata-type-to-c++ used for?
<cyphermox> assuming that's the c or c++ binary you're having trouble with
<awe_> it compiles .type files into C++ headers/code
<awe_> that allows C++ code to do structure io on pre-defined file types
<awe_> cyphermox, here's the build error: http://pastebin.ubuntu.com/10175926/
<awe_> I'm pretty sure the dh_shlibdeps override is needed, and that I've just bungled the syntax in debian/rules
<cyphermox> it seems to me like you would probably want to get that out of the -dev package completely, put it into a patch with the architecture it's built for, so that you can install just one -dev and multiple copies of the binary to be able to cross-compile things, that's probably going to help making where libiodata.so.0 is more evident to dh_shlibdeps.
<awe_> I'm not using patches
<cyphermox> that has nothing to do with patches
<awe_> ok
<awe_> so the binary is only used for development, so that's why it's in the -dev pkg
<Laney> I think one problem you have is that the library appears to be in /usr/lib/.../iodata/ instead of /usr/lib/.../ directly
<Laney> also libiodata.so.0..0 is weird
<cyphermox> there is that, yeah
<awe_> yes, I know...
<awe_> re: the so.0..0
<awe_> there's more stuff to fix
<awe_> right now my goal for this sprint was to get this in good enough shape to drop into a PPA so that we use for testing
<awe_> there's definitely more cleanup to be done
<awe_> Laney, but that said...  if I build on my desktop with the library package installed.  The build works and shlibdep succeeds
<awe_> when I build a device without the library package installed it's failing
<awe_> which is why I assumed an override of dh_shlibdeps with -l specified was required...
<awe_> as I mentioned to cyphermox earlier, the debian dir that was part of this project dates from Moblin v2 days ( '07-08 )
<awe_> s/I build a device/I build on a device/
<awe_> ( note, I'm building on a device as qmake doesn't support cross-builds, and I don't want to deal with a cmake conversion just yet )
<bdmurray> cjwatson: any luck with that publisher bug? vivid's contents.gz is about four days old
<cjwatson> bdmurray: erk, I totally forgot, sorry.  added an asana task to remind myself
<bdmurray> cjwatson: thanks!
<arges> hallyn: tych0 : bug 1384751 would be good to verify at some point as its blocking any other lxc updates from utopic.
<ubottu> bug 1384751 in lxc (Ubuntu Utopic) "checkpoint restore fails with /usr/lib/x86_64-linux-gnu/lxc/lxc-restore-net: not found" [High,Fix committed] https://launchpad.net/bugs/1384751
<tych0> arges: ah ha.
<tych0> arges: will look right now, sorry about that
<tych0> i totally missed it
<arges> tych0: its all good. figured I'd ping : )
<tych0> arges: what do i do if it wroks?
<tych0> arges: i guess add some tag, but i'm not sure what that tag would be :)
<arges> tych0: just change the tag to 'verification-done'
<tych0> arges: ok, will do
 * tych0 boots a vm
<arges> tych0: then that lets us SRU-team people know if its ready to be released: http://people.canonical.com/~ubuntu-archive/pending-sru.html
<Laney> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: open | 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:
<smoser> is it just me or are other people seeing an increase in 'hash sum mismatch'
<sarnold> smoser: seems no worse than usual
<tych0> i just saw one myself
<cyphermox> awe_: drop the space between -l and the argument, and make the path $(CURDIR)/debian... etc.
<smoser> i didn't know if it was just me, as my system now has i386 enabled, so i'm double as likely.
 * awe_ trying
<cyphermox> awe_: still, feels to me like that binary doesn't belong with the development files
<awe_> cyphermox, sure... it *could* be split into another binary package; again I want to get over this hump first
<cyphermox> sure
<awe_> the new package would probably the same exact failure
<awe_> thanks for the help!
<tych0> arges: ok, done. sorry about the delay :(
<arges> tych0: nice. No problem, thanks
<tych0> smoser: nah, i just saw one in utopic-updates on amd64; i don't usually see them, either
<dupondje> https://bugs.launchpad.net/ubuntu/+source/armory/+bug/1388396
<ubottu> Launchpad bug 1388396 in armory (Ubuntu) "Delete armory package from ubuntu" [Undecided,New]
<dupondje> can anyone give his optinion about this?
<dupondje> also, armory recommands bitcoind, but bitcoind isn't even in ubuntu ...
<dupondje> so it makes armory completely useless atm
<arges> dupondje: that would be useful information to put into that bug. can you add that info there?
<dupondje> vivid syncs from sid? And bitcoind is in sid? So why it isn't synced?
<dupondje> blacklisted?
<jtaylor> yes its blacklisted
<arges> dupondje: http://people.canonical.com/~ubuntu-archive/sync-blacklist.txt
<dupondje> guess we better kick armory also then
<awe_> cyphermox, your suggestions plus an additional $(DEB_HOST_MULTIARCH) in the path did the trick
<awe_> thanks
<cyphermox> right, it needs to be a full path
<darkxst> aeoril, of the bug is in gnome-terminal, its like libvte
<aeoril> darkxst here is my latest log:  http://paste.ubuntu.com/10177137/
<tkamppeter> caribou, trusty and utopic SRUs for CUPS are accepted now.
<chiluk> bdmurray, bug 1416906 should be ready for sponsorship now
<ubottu> bug 1416906 in samba (Ubuntu Trusty) "force user no longer works" [Medium,In progress] https://launchpad.net/bugs/1416906
<bdmurray> chiluk: there's a current samba SRU that needs verifying on trusty...
<chiluk> bdmurray, bug num?
<bdmurray> bug 1412909
<ubottu> bug 1412909 in samba (Ubuntu) "Please raise Suggests for lib{pam,nss}-winbind to Recommends in trusty" [Medium,Triaged] https://launchpad.net/bugs/1412909
<sladen> Ubuntu Font user of the day: http://www.weetabix.co.uk/
<Unit193> sladen: I thought http://www.ubuntu.travel/ was pretty good. :P
<robert_ancell> jsalisbury, thanks for your help with bug 1416277 - do you need any more information from me?
<ubottu> bug 1416277 in linux (Ubuntu) "toshiba_acpi: Unknown key 158" [Medium,Confirmed] https://launchpad.net/bugs/1416277
<chiluk> bdmurray,  .. I'm working on verifying it right now...
<bdmurray> chiluk: alright, thanks
<sladen> Unit193: Ubuntu *and* Ubuntu-Title
<chiluk> bdmurray, looks like it's still broken
<chiluk> I did this on canonistack n a precise system install samba and libpam-winbind
<chiluk> Upgrade to trusty
<chiluk> Observe that libnss-winbind is not installed
<chiluk> bdmurray, I'm not sure if it was user error on my part,  *(not having proposed archives enabled in the right places?).. I enabled the proposed archives while in precise, and it seems to have pulled the trusty-proposed package after the upgrade, but it didn't install libnss-winbind..
<bdmurray> chiluk: how did you upgrade? what command
<chiluk> do-release-upgrade
<bdmurray> that'll disable propose I think you need to manually edit sources and run apt-get update then apt-get dist-upgade
<chiluk> bdmurray, already tried.
<chiluk> but the the upgrade did give me the right version of samba.
<chiluk> bdmurray, it was real quick to check with canonistack.
<bdmurray> chiluk: okay, I'll test it then
<chiluk> I know it's not the news either of us wanted to hear
<bdmurray> chiluk: works for me - http://pastebin.ubuntu.com/10179397/
<chiluk> bdmurray, did you start all the way from precise?
<bdmurray> (precise-amd64)root@impulse
<bdmurray> it's a precise chroot
<chiluk> that's really odd.
<chiluk> I'll try once more in case I'm just insane
<bdmurray> to be clear I edited /etc/apt/sources.list and added proposed and s/precise/trusty/
<bdmurray> then ran apt-get update and apt-get dist-upgrade
<chiluk> ah ... I did differently.
<chiluk> bdmurray.. I edited sources to add proposed.
<chiluk> but then simply ran do-release-upgrade
<chiluk> maybe the do-release-upgrade is getting in the way somehow?
<bdmurray> Yes, I believe ubuntu-release-upgrader disables -proposed.
<chiluk> bdmurray, that's not what I'm seeing.
<chiluk> it came up with the correct -proposed version of samba
<chiluk> bdmurray, I'm running the test again on canonistack.. in case I'm insane..
<bdmurray> chiluk: okay, I'm testing it with do-release-upgrade myself
<bdmurray> slangasek: bug 1412909 is strangely verifiable via apt-get dist-upgrade but not with do-release-upgrade. It'd seem to be a bug in the update-manager, right?
<ubottu> bug 1412909 in samba (Ubuntu) "Please raise Suggests for lib{pam,nss}-winbind to Recommends in trusty" [Medium,Triaged] https://launchpad.net/bugs/1412909
<chiluk> bdmurray, I take it all back...it worked this time.
<chiluk> I'm not sure what I could have done wrong.
<chiluk> actually let me do the reboot.
<chiluk> very odd.
<chiluk> bdmurray .. well it worked this time..
<chiluk> I'm going to chalk that up to fat-fingering it the first time.
<chiluk> sorry about the unwarranted fire drill bdmurray ..
<chiluk> on that note I think I'm going to call it a day.
<psusi> cjwatson, mind if I pester you a bit about ubiquity and partman?  I'm investigating a bug where you get a pop up complaining about booting in efi mode but your disk looks like it is set up for bios mode.  This happens because the init.d/efi script is run *after* the visual.d scripts which create the partitions, and the efi script sees the newly created partitions as not being an esp
<sarnold> psusi: you were cut off at "being an esp"
<psusi> sarnold, that was the last word ;)
<sarnold> psusi: the entire last word? :)
<psusi> yea.. ESP = EFI System Partition
<sarnold> aha :)
<psusi> the other problem seems to be that ubiquity is running partman in the background and so when the question pops up, ubiquity proceeds to the next screen after a few seconds and if you haven't clicked either ok or cancel in that time, the window hangs
<psusi> so it feels almost like ubiquity is running different parts of partman in parallel or at the wrong time and its all racey
<jsalisbury> robert_ancell, I don't think I need any addition info for bug 1416277 .  I just need to do some more research.
<ubottu> bug 1416277 in linux (Ubuntu) "toshiba_acpi: Unknown key 158" [Medium,Confirmed] https://launchpad.net/bugs/1416277
<robert_ancell> jsalisbury, ok, thanks
<cjwatson> psusi: I'm not really working on this at the moment, and I'm not in a place where I can look at code, but firstly visual.d scripts don't create partitions, and secondly ubiquity may just need an extra question handler there in its partman module - the way it runs some other things in parallel with partman is perfectly intentional
<psusi> cjwatson, looking at the partman log it appeared to me that it ran the visual.d scripts, and they "created" the partitions ( sending the commands to parted_server ), but did not commit them to disk yet, and then init.d/efi runs and "finds" the newly created partitions
<psusi> ( I threw a set -x into the efi script and can see it finding the partitions but they don't yet exist on disk, but partman's log clearly shows the create partition commands prior to init.d/efi )
<cjwatson> visual.d merely collects information.  please investigate harder
<aeoril> darkxst I took a shortcut and just copied the binaries from trusty to vivid and vice versa, then ran them.  Here is the result:  http://paste.ubuntu.com/10179845/  Any thoughts?
<aeoril> darkxst Also, I was thinking of trying to run/compile then run using the vivid libvte on trusty and vice versa, but they have differnt filenames and versions so not sure how to accomplish that
<cjwatson> I'm on a phone, though, this is ridiculously cumbersome.  if you want me to investigate then please mail me an unedited log - it's easier than trying to guess here
<psusi> sure
<cjwatson> then I can explain the reasoning
#ubuntu-devel 2015-02-12
<darkxst> aeoril, libvte has a soname bump each release
<darkxst> that would make it tricky to bisect or swap versions etc!
<darkxst> aeoril, maybe https://bugzilla.gnome.org/show_bug.cgi?id=708213
<ubottu> Gnome bug 708213 in VteTerminal "zsh - lots of blank space upon resizing VTE based terminals" [Normal,Resolved: fixed]
<aeoril> darkxst thanks!  Looked over that bug - seems like the timing is approximately correct - 9/2013 for the bug work, 11/2013 for the release in trusty, as far as I can tell
<aeoril> darkxst wait, I take that back - would the bug fix have made it into trusty within that small of a window?
<aeoril> (not really sure about the trusty release date)
<infinity> hallyn: LP: #1419855
<ubottu> Launchpad bug 1419855 in qemu (Ubuntu) "must manually load kvm_hv or kvm_pr before using kvm on ppc64" [Undecided,New] https://launchpad.net/bugs/1419855
<infinity> hallyn: Due to a typo in debian/rules, the qemu-kvm init job is never actually installed on ppc64el.
<infinity> hallyn: I suspect we might also want to loosen it to install on powerpc and ppc64 as well (ie: anywhere where qemu-system-ppc is native)
<aeoril> I am looking for the patched code in launchpad for trusty release - but not really sure exactly if I am looking at the correct libvte for trusty darkxst
<hallyn> infinity: ok.  cgmanager needs my attention tonight, but wrote it down for tomorrow
<hallyn> man, on v0.36 already
<hallyn> was hoping it would be dead by now
<infinity> hallyn: We still need to SRU back the qemu-kvm bits at some point too, and whatever else we slacked on.
<infinity> hallyn: Perhaps a discussion better had when we're in the same timezone.
<hallyn> what tz are you in?
<hallyn> the sru of othe rqemu-kvm bits is on my list.
<infinity> hallyn: I'm in Hong Kong right now.
<infinity> hallyn: FWIW, qemu-slof is now in main on trusty too, though I'm not sure how much difference that makes until we either decide to backport utopic's qemu wholesale (ick) or get IBM to identify and backport all the necessary patches for LE host support.
<darkxst> aeoril, I didn't think that fix would have been in trusty, but maybe it was
<aeoril> darkxst I have been looking - it seems the version for the fix was 34.8, while the version in trusty is 34.9 ...
<aeoril> darkxst I cannot use pull-lp-source to get the library source code though - is there another way?
<hallyn> hong kong.  it's a globe-trotting month for you
<darkxst> aeoril, pull-lp-source needs the source package name
<darkxst> there is also apt-get source
<darkxst> that works with binary names
<aeoril> darkxst ok, I'll try that
<darkxst> aeoril, vte3 is the source package name from memory
<aeoril> darkxst I just did "sudo apt-get source libvte-2.90-9" and it seemed to work ...
<aeoril> but yah, vte3 is what I have been seeing ...
<aeoril> darkxst this worked, I will use it:  sudo pull-lp-source vte3 trusty
<infinity> aeoril: Err, there's no reason to run that as root (ie: don't use sudo).
<aeoril> infinity ok, thanks
<darkxst> pitti, indeed disabling cgmanager and lxcfs stops by drives getting unmounted
<aeoril> darkxst what do you think of this? https://bugzilla.gnome.org/show_bug.cgi?id=543919
<ubottu> Gnome bug 543919 in VteTerminal "window size changes don't always propagate" [Normal,Resolved: invalid]
<darkxst> aeoril, it looks like it predates gtk3?
<aeoril> darkxst yes, but they never fixed it and it was just marked as invalid for gtk3 with a mention that if it was seen in gtk3 to reopen
<aeoril> I am assuming just because they never saw it - that does not mean it still wasn't lurking around maybe ...
<darkxst> aeoril, your out by 1-2 lines? that doesnt seem even remotely similar
<aeoril> darkxst I must have misread it
<darkxst> aeoril, I'd probably be digging into the code and use git to find all commits that affect size/resizing
<darkxst> aeoril, maybe check that a resize event occurs when launch with --geometry
<aeoril> darkxst ok
<darkxst> aeoril, and maybe talk to Cpe if he knows what fixed it?
<aeoril> darkxst is git diff?
<aeoril> use git diff?
<darkxst> git log -p <file>
<darkxst> or git log -G/S <var/func name>
<darkxst> are handy
<darkxst> aeoril, that should have been chpe, youll have to head to the gnome channels on GIMPnet to find him though
<aeoril> darkxst so git log -p vte.c?
<aeoril> darkxst yes, his name is all over vte
<darkxst> aeoril, that will show you a log of all commits affecting vte.c (probably way to much to process
<aeoril> I'll grep around for --geometry and other stuff
<darkxst> thats just a command line switch
<darkxst> find the functions that actually handle geometry
<darkxst> and then look for changes in those functions
<darkxst> aeoril, you picked a pretty hard bug, and I certainly don't have time to investigate properly
<aeoril> darkxst it picked me - I would need your help to fix it.  If you need to bow out, I probably should too.
<darkxst> aeoril, I can keep sending you random guesses, thats all I've been doing anyway
<aeoril> darkxst no, you have been much more valuable than that for me, actually
<aeoril> darkxst given your last suggestions, I have a lot to go on for now actually if I were to stick with it
<darkxst> but perhaps a simple packaging bug, something like bug 1406200 could break up things a little! you have spent like all week on this bug
<ubottu> bug 1406200 in syncevolution (Ubuntu) "Add support for GOA in Syncevolution to make it work with Ubuntu-Gnome (Vivid)" [Undecided,New] https://launchpad.net/bugs/1406200
<aeoril> darkxst I have not devoted much time to this bug until today.  I have also learned a heck of a lot, which is invaluable.  But, i have taken up a lot of IRC time for you guys as well
<aeoril> darkxst really, I started from scratch this morning and did it right.  Basically, other than the initial learning stuff I did I have spent 1 day on this bug properly
 * darkxst never spends more than a couple of hours on a bug unless it involves writing lots of code
<aeoril> darkxst also, it is much more fun looking at code and seeing what it does, which is where I am at now
<aeoril> darkxst are you that fast?  Or you just lose interest and go onto another one?
<pitti> Good morning
<darkxst> aeoril, If i can't find the problem in that time, I'll just forward upstream
<pitti> darkxst: thanks for confirming
<aeoril> darkxst ok, I see
<aeoril> darkxst I tend to bite into things and stick with them beyond normal death
<aeoril> (as you can probably already tell)
<darkxst> pitti, morning an np, getting sick of rebooting but still haven't fixed gdm/gtk bug either ;(
<darkxst> aeoril, seems a little unproductive, always utilize upstream
<aeoril> darkxst so, at this point, you would go ahead and file a but on vte on gnome bugzilla and have done with it?
<aeoril> s/but/bug/
<aeoril> darkxst the problem is fixed in vivid though - I thought the whole point of this exercise was finding where the fix was to hopefully backport into trusty and utopic?  Upstream wouldn't be appropriate for that, would it?
<aeoril> darkxst talking to chpe would seem like the sanest thing to do at this point ...
<aeoril> (if possible)
<darkxst> aeoril, if you file a bug they will just probably close
<darkxst> it
<darkxst> but sure you can ask if they know about what fixed it
<aeoril> darkxst Unfortunately, I don't see a forum other than bugzilla on wiki.gnome.org ...
<darkxst> aeoril, #gnome-hackers on GIMPnet is probably your best bet
<aeoril> darkxst ok.  I'll go on there tomorrow and see if I get any help.  Otherwise, I'll think about looking around at geometry code and using git
<aeoril> darkxst to get the vte git repo, I would do "git clone git://git.gnome.org/vte" ???
<darkxst> aeoril, pretty sure you can answer that question yourself!
<aeoril> darkxst yes, you are right.  I am tired.
<darkxst> aeoril, message me again when you are stuck!
<aeoril> afk.  Good night.
<geser> Are there any known issues with permanently switching to systemd? My 15.04 VM won't start (kernel panic) unless I specify init=/lib/systemd/systemd
<darkxst> geser, maybe, pitti has been doing a good job of fixing them as I find them though
<darkxst> geser, but that said I'm now reconsidering swithing ubuntu-gnome to systemd (assuming ubuntu don't switch), it mostly works great,
<pitti> darkxst: argh WTH <censored> <censored>, I got it!
<pitti> darkxst: i. e. I finally understand what's going on with the mounts
<pitti> geser: you mean it panics with upstart and works with systemd? that's certainly not expected -- do you have some output/a bug?
<seb128> pitti, what's going on then?
<pitti> /etc/mtab, the nail in my coffin
<pitti> so systemd boots, parses /etc/mtab (which it expects to be a link to /proc/mounts)
<pitti> sees all the gazillion mounts from the previous boots and creates .mount units for them
<pitti> then unmounts the fstab ones as their devices aren't even there yet (that's the "cleanup mounts after yanking out a device")
<pitti> and then it turns /etc/mtab into a /proc/mounts symlink as intended, which suddenly makes all the mounts disappear
<pitti> so, it should parse /proc/mounts instead of /etc/mtab
<pitti> and for  cleanup we should also turn /etc/mtab into a symlink on upgrades; it's been many many years since it needed to be a file, and it keeps causing confusing
<pitti> confusion
<seb128> pitti, good work figuring it out!
<pitti> so, we do turn /etc/mtab into a /proc/mounts symlink, but something during shutdown or initramfs turns it back to a file
<darkxst> pitti, that sounds well convoluted
<darkxst> (the problem, not the fix)
<pitti> darkxst: yeah, perfect example of an emergent bug which you don't really see at each individual step..
<pitti> so, what is so insistant on making /etc/mtab a file..
<pitti> /etc/init/lxcfs.conf!
<pitti> and /lib/systemd/system/lxcfs.service
<pitti> ExecStopPost=/bin/sed -i "/^lxcfs \/var\/lib\/lxcfs fuse.lxcfs/d" /etc/mtab
<pitti> nonono!
<pitti> that also explains why these problems started about two weeks ago when we got lxcfs
<pitti> so it all fits together now
<geser> pitti: no, I switched that it starts with systemd by default (apt install systemd-sysv --purge (to purge the conflicting upstart package)) but it does so only when I specify init= in grub
<darkxst> pitti, pretty sure it was in some way linked to glib/gtk on ubuntu-desktop ppa though
<pitti> darkxst: I don't have that PPA
<darkxst> I first hit it when I installed that,
<pitti> darkxst: but, it's a race condition; anything which changes the timing during boot could trigger it
<darkxst> it went away when I purged it
<darkxst> pitti, fun old races
<pitti> that's why disabling lxcfs helped
<darkxst> pitti, makes sense
<pitti> geser: sorry, I thought I replied already
<pitti> geser: do you have some logs/a screenshot of the panic? can you please file a bug, that sounds quite serious
<geser> pitti: I can try to take a screenshot from within VMware. The kernel panics with "Attempted to kill init" about 2 sec after booting.
<pitti> geser: ah, can you please boot with "debug" on the command line, too?
<infinity> pitti: Can you verify LP: #1404509 for trusty when you have a chance?
<ubottu> Launchpad bug 1404509 in systemd (Ubuntu Trusty) "[precise, trusty] udev does not automatically load modules with kernel >= 3.11" [Undecided,Fix committed] https://launchpad.net/bugs/1404509
<pitti> infinity: hm, HWE promised to verify that; I don't have an affected machine
<pitti> infinity: I'll reply to them again with a prodding
<infinity> pitti: Ta.
<aeoril> darkxst I actually never did stop - I have been familiarizing myself with the vte code all night - pretty cool stuff
<infinity> pitti: I didn't find a test case (nor divine one from the comments) for trusty, since you said trusty already worked for the 'cpu' subsystem, but 'might fail' for 'others'.  Makes it all a bit nonspecific to test. :P
<darkxst> aeoril, ok, like I said message me again when you are stuck!
<aeoril> darkxst ok, sorry - won't keep bothering you
<pitti> infinity: yeah, that was a request from Dell for ipmi systems; I asked them again to test (our HWE engineers also have that hw)
<infinity> pitti: Spiffy.
<pitti> infinity: i. e. the real test case that we're interested in is "does that laptop work now"
<infinity> pitti: "No, the battery went flat, sorry."
<geser> pitti: filed as bug #1421117 with the debug output from the serial console
<ubottu> bug 1421117 in systemd (Ubuntu) "Ubuntu 15.04 VM doesn't boot after switching permanently to systemd" [Undecided,New] https://launchpad.net/bugs/1421117
<alkisg> mvo: good morning, the SRU was approved and it's now in precise-proposed, we did verification-done for one of the bugs, do you need help for the other 3 ones?
<mlankhorst> pitti: gmsh 'regression' with mesa upload again :/
<pitti> mlankhorst: argh; nudged
<mlankhorst> ty
<pitti> geser: replied to the bug
<mvo> alkisg: I would certainly not mind help ! can also give it a go later today
<geser> pitti: added the info you requested to the bug. It looks like /sbin/init being an absolute symlink is the issue.
<pitti> /sbin/init -> /lib/systemd/systemd
<pitti> geser: that's what it is here
<geser> here too (booted system), in the initramfs it's /root/sbin/init -> /lib/systemd/systemd but there is no /lib/systemd/systemd there, only /root/lib/systemd/systemd
<flexiondotorg_> Will the HWE stuff be installed/shipped by default in 14.04.2 or will it still be a post-install apt-get for users?
<dholbach> didrocks, wow, looks like there's a lot going on in the ubuntu-make project :)
<didrocks> dholbach: heh, yeah, and nice community contributions! :)
<dholbach> :)
<didrocks> dholbach: the next update would have 5-6 new supports, coming from the community :)
<didrocks> (a new contributor)
<didrocks> it's awesome!
<dholbach> wow, that's amazing
<didrocks> those people rocks! :)
<pitti> geser: hm, that all looks fine and expected; so I'm a bit stumped what to ask next..
<geser> pitti: so what's the difference to boot with "init=/lib/systemd/systemd" which works?
<pitti> geser: that's the thing, I don't have the slightest idea :/
<pitti> geser: the default is /sbin/init, but if that points to /lib/systemd/systemd it should be the same
<pitti> geser: I guess init=/bin/systemd doesn't work either?
<pitti> geser: if it does, that would be a major surprise
<geser> pitti: correct, init=/bin/systemd doesn't work either (with a different error: target filesystem doesn't have requested /bin/systemd)
<pitti> interesting (and a lie, too)
<geser> pitti: but with /sbin/systemd -> ../lib/systemd/systemd (created for testing) and init=/sbin/systemd it works again
<pitti> geser: fun; that sounds like an initramfs-tools bug then
<ricotz> pitti, hi, is "/sbin/init -> /lib/systemd/systemd" already default? since here is points to upstart
<geser> ricotz: it's only default when you install systemd-sysv
<ricotz> geser, ok, i guess i hold off that to keep ubuntu-minimal, ureadahead
<rbasak> Is it sufficient to supply jquery in debian/missing-sources/, when minified JS is being shipped upstream?
<rbasak> Or is it necessary to provide the mechanism to derive the minified JS also?
<rbasak> (the minified JS isn't actually used; the packaging uses libjs-jquery instead)
<pitti> rbasak: there's the option to repack the upstream source without the code copy; but if you want to use the original tarball, debian/missing-sources/ sounds ok to me
<rbasak> pitti: OK - thanks
<hallyn> pitti: hey - sorry to bother you, but would you mind taking a look at http://mentors.debian.net/debian/pool/main/c/cgmanager/cgmanager_0.36-1.dsc an dperhaps sponsorin ginto sid?
<flexiondotorg_> Will the HWE stuff be installed/shipped by default in 14.04.2 or will it still be a post-install apt-get for users?
<smoser> hey.
<smoser> do i need an MIR to move python3-serial to main ?
<smoser> https://launchpad.net/ubuntu/+source/cloud-init/0.7.7~bzr1055-0ubuntu1/+build/6969483
<smoser> it blocks cloud-init, but is from same source package as python-serial which is in main.
<pitti> hallyn: re (sorry, meeting); can do
<pitti> hallyn: wrt your recent comment on bug 1419623, that's what I did
<ubottu> bug 1419623 in systemd (Ubuntu) "systemd unmounts mounted filesystems when lxcfs is installed" [High,In progress] https://launchpad.net/bugs/1419623
<hallyn> pitti: thanks.  If you feel up to actual checking of the upstream patches too that'd be great :)  I'm feeling squeamish, but at the same time these fixes need to ge tout
<hallyn> pitti: oh!  i thought you said you'd sent a patch to systemd
<pitti> hallyn: well, both
<pitti> hallyn: systemd should be more robust in that situation, but we still don't want to turn a symlink into a file
<hallyn> cool, thanks
<hallyn> yeah
<mbruzek> Good morning #ubuntu-devel
<pitti> hallyn: we discussed the systemd patch on teh upstream ML this morning; it's unfortuantely a bit tricky as util-linux 2.25's libmount has a bug
<pitti> hallyn: but I'll keep a slightly hackish patch in our tree for now
<mbruzek> Someone from Nagios contacted me and he wants to update the packages for Ubuntu.  He does not know how to do that so was asking me for information on how to get started.
<pitti> hallyn: checking of the upstream patches> for what?
<hallyn> pitti: sanity?
<hallyn> it switches cgmanager so it now pivots into an empty root
<hallyn> it *should* be safe, but i'm not sure whether my imagination is just failing me as to ways in which it culd fail
<jpds> mbruzek: In which release? 14.04 LTS?
<mbruzek> jpds He did not specify release, but I would guess yes the LTS release
<jpds> mbruzek: That's not really possible.
<jpds> !sru | mbruzek
<ubottu> mbruzek: Stable Release Update information is at http://wiki.ubuntu.com/StableReleaseUpdates
<pitti> hallyn: ah, so mostly https://github.com/lxc/cgmanager/commit/a08d1c038c84 ?
<mbruzek> I will give him this information and see what I can do, I believe the reason he wants to update is because nagios core is verison 4.x now and we still have 3.x in the packages
<pitti> hallyn: do you have that packaging in git, or can I clean up the changelog? (Closes: #760281) (Closes: #767468) â (Closes: #760281, #767468)
<jpds> mbruzek: that's updatable in the development release.
<mbruzek> jpds: if that is not possible, perhaps he can start the process for the next LTS
<jpds> mbruzek: Exactly.
<mbruzek> I just want to point him to the right resources so he can get moving
<hallyn> pitti: not in git, cleanup apprecaited
<hallyn> uh, i think not in git.  what does the pkging say? :)  /me chekcs
<hallyn> pitti: so yeah, basically that commit and the one before and the one after it.  (the rest should be no big deal)
<cjwatson> smoser: no, that doesn't need an MIR.  moved
<pitti> hallyn: ah, so umounts etc. from the real systems were busted because cgmanager only made them slave in its NS, not private?
<hallyn> no,
<smoser> cjwatson, thanks.
<hallyn> pitti: it was bc it cgmanager only made them slave in its NS, not in the host ns
<hallyn> so it owrked fine under systemd, bc there the host is MS_SHARED
<hallyn> but in sysvinit/upstart it's private on the host so mounts don't get fwded in the first place.
<hallyn> it's not cgmanager's place to change that on the host
<hallyn> really it points to a problem with mounts propagation, but i didn't want to fight that fight for this bug
<pitti> hallyn: so, the patch looks sensible enough to me, and it seems some people tested it in the debian bugs too
<pitti> hallyn: note that as far as the unblock request goes, testing has 0.33 only; I figure you want 0.36 in testing as these two bugs are quite important?
<hallyn> pitti: yes, please.  I have a separate patch (though i have to rework it) for jessie
<hallyn> wait,
<pitti> hallyn: do you want to fix that? http://paste.ubuntu.com/10189427/
<hallyn> no, i mean i'd *like* 0.36 in testing but figured that wasn't possible, so am working in a debian bug on a debdiff for 0.33-3
<pitti> hallyn: (I suggest calling shlibdeps with -c4 to make the build fail on changed symbols)
<hallyn> pitti: feh!  those appeared in 0.33
<pitti> hallyn: ok, responded to https://mentors.debian.net/package/cgmanager
 * hallyn looks for an example of shlibdeps
<hallyn> pitti: so I dont' suppose I can use 0.33 in the new symbols file?  Or does it only matter tha tit was available as of 0.33-1 package?
<pitti> hallyn: you should use that (i. e. the version where the symbol appeared, not when you added it to the .symbols file)
<hallyn> thx
<hallyn> pitti: is there a DEB_SHLIBS_ARGS type variable I can set to pass -c4, or do i have to use a override_dh_shlibdeps section?
<pitti> hallyn: I think you have to override_dh_makeshlibs, and call dh_makeshlibs -- -c4
<pitti> I'm not aware of something easier :/
<cjwatson> overrides are more discoverable than variables anyway
<hallyn> cjwatson: yeah i'm just afraid i'll drop something in the override
<cjwatson> how so?
<hallyn> so ican be sure that dh_makeshlibs normally doesn't pass any variables?
<hallyn> as in, it would normally pass '-foo' and i dont' pass it in my override
<cjwatson> the unoverridden case of override_dh_foo is always simply dh_foo
<cjwatson> this is never a thing you need to worry about
<hallyn> ok, that's good :)
<hallyn> thx
<hallyn> hm.  dpkg-shlibdeps: unknown option `-c4'
<hallyn> pitti: ^
<pitti> hallyn: yeah, dh_makeshlibs :)
<cjwatson> makeshlibs not shlibdeps
<hallyn> oh, thx.
<zul> pitti:  is there a way were you can login to qemu for autopkgtest after a test fails?
<pitti> zul: yes; run it with -s (aka --shell-on-fail), it will then give you the ssh command (or minicom, netcat etc. if your machine doesn't have a running ssh server)
<zul> pitti:  cool thanks
<hallyn> pitti: updated package pushed to mentors
<pitti> hallyn: hm, I don't see it yet on https://mentors.debian.net/package/cgmanager
<hallyn> pitti: just did it 3 mins ago, sometimes it takes a bit...
<hallyn> pitti: it's there now
 * hallyn biab
<Odd_Bloke> smoser: Where can I get the most recent packaging for cloud-init in precise(-updates)?
<Odd_Bloke> smoser: lp:ubuntu/precise-updates/cloud-init looks out-of-date.
<rbasak> Odd_Bloke: do you know about pull-lp-source? "pull-lp-source cloud-init precise".
<rbasak> What's in the archive is the definitive "most recent", except for maybe work in progress in branch somewhere, but I'm not sure that exists for cloud-init.
<Odd_Bloke> rbasak: I did once, and now I do again. :p  Thanks. :)
<smoser> Odd_Bloke, looking
<smoser> bzr importer and cloud-init do not get along.
<smoser> its a regular PITA
<rbasak> There seem to be a number of server packages that the bzr importer fails with. For this reason I gave up on UDD a long time ago - I have to use the non-UDD workflow anyway, and UDD never seemed to gain me much.
<rbasak> I think it's an issue for new starters actually. More to learn, more edge cases to deal with. We should throw UDD away.
<rbasak> (and this includes me when I started)
<cjwatson> rbasak: Once we have git support, hopefully we will
<pitti> hallyn: in symbols you want s/0.36-1/0.33/, but I'll fix that
<cjwatson> (Since dgit is inherently much more reliable and does largely the same thing)
<rbasak> cjwatson: UDD with git would work really well IMHO. Though I think the importer should leave quilt patches unapplied. Then the importer can be written to never fail.
<rbasak> dgit did look good when I read about it. I didn't actually try to use it though.
<cjwatson> Ian was doing something with that in dgit recently, I forget exactly where he ended up
<cjwatson> It was certainly never-fail
<cjwatson> Er, I think
<cjwatson> It may well still need work, but it's much more tractable work in git
<smoser> Odd_Bloke,
<smoser> precise: lp:ubuntu/precise-proposed/cloud-init
<smoser> trusty: lp:ubuntu/trusty/cloud-init
<smoser> utopic: lp:ubuntu/utopic/cloud-init
<smoser> vivid: lp:ubuntu/vivid/cloud-init
<Odd_Bloke> smoser: Aha, -proposed. Thanks!
<hallyn> pitti: how did i do that!  i distinctly remember typing in 0.33
<pitti> hallyn: uploaded
<hallyn> pitti: thx!
<tumbleweed> jtaylor: have you seen the pyzmq autopkgtest failure?
<grimble_> Hi, my name is Bartek. I submitted my first bug (1410383) and provided patch. Do I have to do something more to receive feedback or just queue is full and need to wait for my turn?
<cyphermox> grimble_: for a puppet SRU, correct?
<grimble_> yes
<cyphermox> grimble_: so looking quickly it seems correct, but I don't usually touch puppet
<cyphermox> that said, since it's for a bug fix in a stable release, you might want to follow https://wiki.ubuntu.com/StableReleaseUpdates#Procedure
<cyphermox> to update the bug associated with that merge to make it easier to review the bug later and test the fix.
<grimble_> ok, thanks for link, I'll look into it and come back if I would have questions :)
<cyphermox> don't hesitate :)
<jtaylor> tumbleweed: no, whats up with that all logs say tests worked ...
<jtaylor> debian works weird
<hallyn> infinity: mwhudson: hey, you guys came up with the original kvm.powerpc script (/usr/bin/kvm for powerpc)?
<tumbleweed> jtaylor: https://jenkins.qa.ubuntu.com/job/vivid-adt-pyzmq/23/ARCH=amd64,label=adt/console - there's an import error
<tumbleweed> but that can't be explained by the 14.4.0 -> 14.4.1 diff
<jtaylor> hm
<jtaylor> that test shouldn't be uploaded yet
<jtaylor> someone nmu'd
<jtaylor> or I forgot what I did
<jtaylor> ah nmu
<tumbleweed> yeah, that was an ubuntu-specific upload
<jtaylor> yeyI know of that failure
<jtaylor> the reason its not uploaded yet
<jtaylor> its minor but didn't have the time to see whats going wrong yet
<tumbleweed> I can't see the cause from the diff :(
<jtaylor> the failign test is new
<jtaylor> just 3 lines
<tumbleweed> jtaylor: https://launchpadlibrarian.net/195372601/pyzmq_14.4.0-1build1_14.4.1-0ubuntu1.diff.gz
<jtaylor> search for test_ssh
<jtaylor> so its not a regression
<tumbleweed> oh, I see
<tumbleweed> there
<tumbleweed> I'll force that test failure then
<tumbleweed> no, disable that test
<jtaylor> its probably somehow related to the apckaging
<jtaylor> building from source normally does not cause the test to fail
<tumbleweed> yes, it's probably a bad PYTHONPATH
<bdmurray> zul: there is no bug for tracking the python-keystoneclient upload for a trusty SRU?
<zul> bdmurray:  the 1.0.0 upload?
<bdmurray> zul: right
<zul> bdmurray:  that was a mistake please reject it
<bdmurray> done
<mwhudson> hallyn: yes, with help from BenC iirc
<hallyn> mwhudson: smoser found that that fails for libvirt bc apparmor forbids the use of awk/uname.  So smoser switched it to using
<hallyn> just shell, but the question is whehter and how to do the uname -m check.
<mwhudson> ah
<hallyn> 'uname -m' will i assume report ppc personality on ppc64 host,
<hallyn> but ppc personality on ppc64host can run qemu-system-ppc64 just fine
<mwhudson> i don't know very much about any of this :)
<hallyn> so just wondering how best to emulate that
<mwhudson> i just wanted to be able to install qemu-kvm on aarch64 and have something useful happen
<mwhudson> BenC might know i guess
<BenC> hallyn: How would âuname -mâ report ppc on a ppc64?
<hallyn> mwhudson: BenC: in particular we're wondering whther http://paste.ubuntu.com/10191769/ is ok (minus adding extra ' in last case)
<hallyn> BenC: i assumed the same way that it reports i386 if i run 'i386' on x864 host
<BenC> svy@yoda1:~$ uname -m
<BenC> ppc64
<BenC> root@ctsendian:~ # uname -m
<BenC> ppc
<hallyn> is ctsendian a ppc personality on ppc64?
<BenC> bcollins@swarted:~$ uname -m
<BenC> x86_64
<BenC> ctsendian is a 32-bit ppc system
<BenC> (e500mc)
<BenC> hallyn: Ah, you mean like if I run âlinux32 uname -mâ?
<hallyn> right
<BenC> svy@yoda1:~$ linux32 uname -m
<BenC> ppc
<BenC> Right, that works
<BenC> Let me test the script
<BenC> hallyn: Add e5500* and I think it will work well
<BenC> hallyn: Does that work for PowerMac as well?
<BenC> i.e. does it match POWER*
<BenC> like G5 (which is 64-bit)
<BenC> hallyn: Hereâs one you can test on: https://github.com/jolicloud/base-installer/blob/master/kernel/tests/powerpc/g5.cpuinfo
<hallyn> BenC: cool, thanks!
<infinity> hallyn: Wait, what does apparmor prevent?
<hallyn> infinity: when libvirt starts a qemu instance, that is not allowed to run /bin/awk or /bin/uname
<BenC> infinity: libvirt does not have exceptions to execute awk and uname
<hallyn> (yes, we could add those, but we also could not)
<infinity> hallyn: I feel like that's a bug. :P
<infinity> hallyn: But sure, doing it in pure shell can accomplish the same thing.
<BenC> hallyn: I would add comments in the script saying why it needs to stay purely shell, else a year from now someone will âfix itâ by using snazzy awk and uname calls
<infinity> hallyn: The new one seems incorrect, however.
<infinity> hallyn: Since it won't catch all ppc64 cases.
<BenC> Yeah, and I think POWER4 is not 64-bit?
<infinity> BenC: It is.
<infinity> I mean, it's mostly a moot point, since older ppc64 CPUs can't run kvm anyway, but newer ones that won't be branded POWER* will be able to.
<hallyn> would it be easier to enumerate the 32-bit cases?
<infinity> hallyn: Maybe, as only a select few 32-bit CPUs are KVM-capable, but it's still simpler to use the logic we did before. :/
<hallyn> infinity: but then i was stil wondering whether the 'uname -m' check was actually wrong
<hallyn> ok, we can go half-way,
<hallyn> add an apparmor exception for uname but not awk
<hallyn> if the uname check was correct
<infinity> Maybe.  Or find uname in proc somewhere.  It might be hiding in there somewhere. :P
<BenC> hallyn: I assume if you call kvm with in a ppc personality, youâve put in effort to want to run a 32-bit VM
<hallyn> i dunno, seems to me you car eabout what the gues thas, and qemu-system-ppc64 will dtrt wrt that
<BenC> infinity: âuname -mâ is runtime dependent on the personality
<infinity> BenC: Yeah, I'm aware.
<BenC> hallyn: I canât even imagine calling kvm while under a ppc32 personality without knowing itâs happening and without knowing you want to do that for a reason
<infinity> BenC: But personalities are also a bit of a lie. :P
<hallyn> BenC: i suffer from a well-known lack of imagination :)
<BenC> hallyn: Can you give me a real use case for when that even makes sense?
<BenC> infinity: Eat your cake and go back to work
<infinity> Anyhow, I'd agree that following uname is probably sane.
<infinity> BenC: I refuse to work at 3:39am.
 * hallyn jealous
<BenC> infinity: Have you returned to AU?
<infinity> hallyn: Anyhow, I think the default fallback for 32/64 is sane, as we can't know (and don't want to know) what future CPUs might call themselves.
<infinity> hallyn: And uname seems the only halway sane way to do that bit.
<infinity> BenC: HKG.
 * BenC agrees
<hallyn> ok, thanks guys - so i'll stick with the current use of uname -m, and at most will reproduce the awk logic with shell
<BenC> infinity: Ah
<flexiondotorg_> cyphermox, Hi
<flexiondotorg_> cyphermox, Are you able to upload some of the packages we reviewed?
<cyphermox> did you get a second review?
<flexiondotorg_> Not yet. I'll chase tomorrow then.
<cyphermox> or ask here if anybody has time to review them :)
<flexiondotorg_> Any sponsor here who could review some packages for upload into the official archive?
<flexiondotorg_> mhall119, Do you know anyone in not-Europe timezone that could help? With the above?
<hallyn> BenC: so you were saying e5500* should run qemu-system-ppcemb right?
<infinity> hallyn: Well, currently that matches   e500*|e6500*)
<infinity> Did Ben's opinion change since we wrote that? :P
<hallyn> infinity: that's what i'm wondering
<hallyn> so looking at https://github.com/hallyn/qemu/blob/ubuntu-dev/debian/kvm.powerpc
<hallyn> hm, no
<hallyn> previous push failed :)
<hallyn> smoser: https://github.com/hallyn/qemu/blob/ubuntu-dev/debian/kvm.powerpc is working for me on test files
<infinity> hallyn: You don't really need the POWER*) case if you have the ppc64*) case.
<hallyn> infinity: yeah but i figure it avoids an extra exec for uname
<hallyn> s
<hallyn> (gr, cursorwarp)
<infinity> hallyn: Yeah, skips a fork, but meh.
<infinity> hallyn: I'd also use consistent formatting for the first two cases compared to the second two for readability, but that's a minor complaint.
<infinity> (Ideally multiline for all)
<hallyn> infinity: well, skip a fork, and inconsistent wrt personality i guess, so i'll remove it
 * infinity goes to bed instead of bikeshedding.
<hallyn> infinity: thx - gnight
<smoser> hallyn, ok. so its ok to run uname ?
<smoser> i just completely randomly picked 'POWER'
<hallyn> smoser: will be in about 3 minutes
<smoser> i dont know if POWER would be right for qemu-system-ppc or not
<hallyn> (dputing new libvirt now)
<smoser> (ie, line 18)
<hallyn> smoser: yeah i'm getting rid of that now
<hallyn> smoser: so maybe https://github.com/hallyn/qemu/blob/ubuntu-dev/debian/kvm.powerpc ?
<hallyn> hm, but that's not working
<hallyn> oh, heh.  nm
<mhall119> flexiondotorg_: what issue?
<flexiondotorg_> mhall119, cyphermox has reviewed some packages for Ubuntu MATE and suggested I get a second review prior to upload to the official archive.
<flexiondotorg_> mhall119, dholbach has been sponsoring but has been busy recently and not it is late here in Europe.
<flexiondotorg_> mhall119, I was wondering if a sponsor from a timezone still in office hours could help?
<mhall119> flexiondotorg_: I'm sure one could, I don't know who though
<mhall119> I assume any ubuntu developer can do this?
<mhall119> this is really where dholbach is an expert, not me
<cyphermox> mhall119: correct, any MOTU can
<cyphermox> flexiondotorg_: if you have bugs open for the uploads they could be added to the sponsoring queue so that would make things more easy to track
<flexiondotorg_> cyphermox, Understood.
<flexiondotorg_> cyphermox, I'll file bugs for ubuntu-mate-settings and ubuntu-mate-artwork tomorrow.
<flexiondotorg_> cyphermox, In fact, those have been review by dholbach previously and yourself.
<flexiondotorg_> So, those should be good to go.
<flexiondotorg_> Right?
<cyphermox> if they have been reviewed by two motus yes that's sufficient, so I can upload those
<cyphermox> you'll still need at least the metapackage uploaded before you can do much though
<flexiondotorg_> cyphermox, Agreed. Can that be uploaded before everything else is in the official archive?
<cyphermox> flexiondotorg_: well, yes, but it won't be installable until the other parts are uploaded
<cyphermox> so it would stay in proposed I'd say
<flexiondotorg_> cyphermox, Understood.
<flexiondotorg_> I've got some packages we are actually uploading to Debian because they are general MATE utilities and not specific to Ubuntu MATE.
<flexiondotorg_> So, I think we only need the ubuntu-mate-settings, ubuntu-mate-artwork and ubuntu-mate-meta packages, since the other stuff should come via Debian.
<cyphermox> sure
<cyphermox> and yuyo
<flexiondotorg_> cyphermox, Yes, yuyo too.
<cyphermox> is there much else that hasn't yet made it in to debian?
<cyphermox> because soon you'll end up caught in freezes
<flexiondotorg_> cyphermox, We are trying to add MATE Menu, MATE Tweak and Caja-Actions to Debian.
<flexiondotorg_> cyphermox, I realise the freeze happens on 19th.
<flexiondotorg_> Hoping they can make it before then if not I can either drop them (disappointing) or apply for exception.
<flexiondotorg_> cyphermox, I'm just double checking ubuntu-mate-settings and ubuntu-mate-artwork
<flexiondotorg_> cyphermox, OK ubuntu-mate-settings and ubuntu-mate-artwork are good to go from my point of view.
<flexiondotorg_> cyphermox, Any last thoughts from you?
<hallyn> hi - for a build-dependency which only exists on some of the arches on which the package being built exists, is there a good way to say in debian/control "only build-dep on libnuma-dev on these architectures" ?
<hallyn> i think i'm being silly
<hallyn> pls to ignore
<cyphermox> flexiondotorg_: no, I'll look at them after dinner
<flexiondotorg_> cyphermox, Many thanks!
#ubuntu-devel 2015-02-13
<pitti> Good morning
<alkisg> Good morning
<Noskcaj> Should we sync dbus-glib from exp? It includes a few fixes and officially deprecates the package
<alkisg> mvo, good morning, I did "verification-done" for 3 out of the 4 bugs for the update-manager precise SRU, but I'm having trouble with verifying LP #1341320
<ubottu> Launchpad bug 1341320 in update-manager (Ubuntu Precise) "empty apt-get install command suggested by hwe-support-status" [Medium,Fix committed] https://launchpad.net/bugs/1341320
<alkisg> (I did #1402706 #1415785 #1420217)
<alkisg> hwe-support-status doesn't give me an apt line at all
<mvo> alkisg: woah, you ROCK
<alkisg> :)
<mvo> alkisg: that happens if you have update-manager installed, then it won't tell you about apt-get :)
<alkisg> Aaah
<mvo> alkisg: is that maybe what you see?
<alkisg> Yes I was trying with the desktop cd
<alkisg> So I only need update-manager-core installed?
<mvo> alkisg: yeah, if it detect the GUI being instlaled it will not bother with the low-level apt-get as update-manager in the UI can also do the transition
<alkisg> Gotcha, trying...
<mvo> alkisg: thanks so much for your help with!
<alkisg> True, now it gives me an apt line. I'll do the verification-done step.
<mvo> \o/
<alkisg> mvo: for 1341320, am I supposed to get an empty apt line with the previous update-manager-core?
<alkisg> See https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/1420217 comment #3 for what I'm getting
<ubottu> Launchpad bug 1420217 in update-manager (Ubuntu Precise) "HWE meta packages "linux-signed-generic"/"linux-signed-image-generic" not considered" [Medium,Fix committed]
<mvo> alkisg: let me check
<alkisg> I.e. I'm getting an apt line, but it just doesn't contain the signed variant
<alkisg> And with .18, it does contain the signed variant
<mvo> alkisg: so if there is no meta package anymore but a leftover package, then it will report a empty line, hm, maybe the test case is not good
<mvo> alkisg: or just upgrade the meta packages first (i.e. run the commandline that is given there)
<mvo> alkisg: and see if after that you get the empty output :)
<alkisg> Gotcha
<alkisg> mvo: that one was a little tricky, I had to update everything and remove all the previous meta packages and only keep a couple of old kernels around
<alkisg> Could you check this output? http://sync.in/plinetio
<mvo> alkisg: looks excellent
<alkisg> OK, putting it to the bug report...
<mvo> alkisg: yes, its a bit tricky my description should have been better, its a bit of a corner case
<dholbach> good morning
<alkisg> mvo: all done, thanks for the SRU!
<mvo> alkisg: very nice, thanks for the verification
<alkisg> tjaalton: hi, could I ping you to release an update-manager SRU? Thank you very much! http://people.canonical.com/~ubuntu-archive/pending-sru.html and https://wiki.ubuntu.com/StableReleaseUpdates#Publishing
<tjaalton> alkisg: it's friday, so no packages released to -updates today :/
<alkisg> np, thank you
<tjaalton> you'll get it on monday ;)
<alkisg> :)
<flexiondotorg_> dholbach, Any chance you could help with a little sponsoring today?
<dholbach> hi flexiondotorg_
<flexiondotorg_> dholbach, Morning
<dholbach> if you're talking about https://code.launchpad.net/~ubuntu-mate-dev/compiz/compiz-mate/+merge/249578 I'm not sure I'm a good person to make a decision
<dholbach> bregma, Trevinho: ^
<dholbach> can you guys maybe help out with this?
<dholbach> or maybe other folks in #ubuntu-unity or #ubuntu-desktop?
<flexiondotorg_> dholbach, Nope, not that ð
<flexiondotorg_> I have some merge proposal, that have been approved and merged. But not packages have been built since.
<dholbach> aha?
<flexiondotorg_> https://code.launchpad.net/~ubuntu-mate-dev/ubiquity-slideshow-ubuntu/ubuntu-mate/+merge/244191
<flexiondotorg_> https://code.launchpad.net/~profzoom/lightdm-gtk-greeter/add-mate-badge/+merge/243069
<flexiondotorg_> https://code.launchpad.net/~ubuntu-mate-dev/indicators-gtk2/indicator-sound-gtk2/+merge/244120
<flexiondotorg_> https://code.launchpad.net/~ubuntu-mate-dev/indicators-gtk2/indicator-application-gtk2/+merge/244116
<flexiondotorg_> dholbach, There is also quite a serious bug in gtk2 affecting MATE but we have supplied a patch.
<flexiondotorg_> https://bugs.launchpad.net/ubuntu/+source/mate-control-center/+bug/1351890
<ubottu> Launchpad bug 1351890 in mate-control-center (Ubuntu) "Changing external screen resolution with dual monitors" [Medium,Confirmed]
<flexiondotorg_> Patch in #9
<caribou> When a package is synced from debian/experimental, does it get automatically synced again from experimental ?
<flexiondotorg_> dholbach, How do we progress that?
<caribou> I mean, do I need to re-sync everytime ?
<flexiondotorg_> caribou, No.
<caribou> flexiondotorg_: ok, thanks
<flexiondotorg_> caribou, At least not while the sync is still enabled.
<dholbach> flexiondotorg_, for the last bug, add a patch including a d/changelog entry and subscribe ubuntu-sponsors
<flexiondotorg_> caribou, Debian sync end February 19th for Vivid.
<dholbach> I'm fairly busy today, but I'll take a look at the bugs above - I would have expected somebody from the desktop team to land them :-(
<flexiondotorg_> dholbach, If you have contacts in the desktop team please introduce me.
<flexiondotorg_> So far I have been depending on you and cyphermox.
<dholbach> seb128, didrocks, Laney, happyaron for example
<flexiondotorg_> seb128, didrocks, Laney, happyaron - I am the lead for Ubuntu MATE. Would any of you be able to help with some sponsoring today?
<seb128> dholbach, easier to say #ubuntu-desktop
<didrocks> flexiondotorg_: note sure about today, I have some patch pilot round on Tuesday, I will take a look then if nobody beats me to it
<didrocks> maybe I'll be able to do one or two beforehand, but with FF, quite busyâ¦
<flexiondotorg_> didrocks, Understand. This is my concern. FF is upon us and I have quite a bit of outstanding stuff to be actioned ð
<didrocks> dholbach: flexiondotorg_: I'm happy to get some today if I get some time (switching with Tuesday's patch pilot), but as usual, then I won't be marked has having done my shift when I did it, but anyway :p
<flexiondotorg_> didrocks, Don't mess with your schedule on my account. I understand you guys are super busy.
<didrocks> flexiondotorg_: however, you should still see with bregma/Trevinho for the compiz one, I won't feel confortable on this one
<flexiondotorg_> didrocks, Yes. I will follow up with them regarding Compiz.
<flexiondotorg_> bregma, Trevinho - Please can you take another peek at https://code.launchpad.net/~ubuntu-mate-dev/compiz/compiz-mate/+merge/249578
<dholbach> looking at indicator-sound-gtk2 now
<happyaron> flexiondotorg_: I can look at the slideshow and maybe merge it, but you need someone else to get it uploaded
<happyaron> ah it's already merged
<flexiondotorg_> happyaron, Yeah, my issue is getting stuff uploaded.
<flexiondotorg_> dholbach, Thanks!
<flexiondotorg_> dholbach, You'll remember your review ubuntu-mate-settings and ubuntu-mate-artwork with me last year.
<flexiondotorg_> dholbach, I met with cyphermox last week and we did another review together.
<flexiondotorg_> dholbach, So they are ready for upload I believe.
<dholbach> ok
<didrocks> flexiondotorg_: bluesabre needs to do a release for lightdm-gtk-greeter it seems (he's doing upstream releases for it it seems)
<didrocks> flexiondotorg_: seems that it's mostly the xubuntu guys, so maybe contact them?
<didrocks> or ochosi maybe :
<didrocks> :)
 * ochosi hides
<flexiondotorg_> didrocks, I have been in contact with Xubuntu team last night.
<didrocks> spotted!
<ochosi> gah :)
<flexiondotorg_> ochosi, Hello again.
<ochosi> yeah, the greeter will get a 2.0 release and subsequent release soon
<flexiondotorg_> didrocks, I will chat with bluesabre later.
<dholbach> responded on ~profzoom/lightdm-gtk-greeter/add-mate-badge
<ochosi> we have all the features we want there, so it's just a matter of getting around to it
<ochosi> dholbach: hmm, that MR is merged already though.. :)
<dholbach> ok
<dholbach> ah ok
<flexiondotorg_> dholbach, Replied to  ~profzoom/lightdm-gtk-greeter/add-mate-badge
<flexiondotorg_> Regarding the gtk2 patch do you need a complete debdiff? e.g. new debian/changelog entry + patch itself + debian/patches/series diff (which specifies the patch file on the last line)
<didrocks> flexiondotorg_: interesting, the slideshow has a release tag for 92 but didn't get uploaded to the archive
<didrocks> (and more commits afterwards)
<flexiondotorg_> didrocks, Thanks for helping with this. Really appreciate it.
<didrocks> flexiondotorg_: no worry, just having one remaining to do help :)
<didrocks> flexiondotorg_: I'm trying to build this rev 92 (which contains your patch) and check
<flexiondotorg_> didrocks, Cheers.
<flexiondotorg_> dholbach, Regarding the gtk2 patch do you need a complete debdiff? e.g. new debian/changelog entry + patch itself + debian/patches/series diff (which specifies the patch file on the last line)
<dholbach> flexiondotorg_, an entry in d/changelog, the patch in d/patches and the patch being mentioned in d/patches/series (http://packaging.ubuntu.com/html/patches-to-packages.html has more info) - in the indicator-sound-gtk2 package, the change was applied directly in the source
<dholbach> ... or another option would have been to submit the patch directly to the "upstream" source
<dholbach> and get a new release made
<dholbach> commented on the badge proposal again
<flexiondotorg_> dholbach, I've added license information to ~profzoom/lightdm-gtk-greeter/add-mate-badge
<ochosi> flexiondotorg_: humm, actually you can let dholbach off the hook since there will be a release for the greeter soon and your changes will be included ;)
<ochosi> if you wanna add license information, please file a separate/new MR
<dholbach> ok
<dholbach> I'll leave you to it
<flexiondotorg_> ochosi, Thanks!
<flexiondotorg_> dholbach, Regarding the gtk2 patch do you need a complete debdiff? e.g. new debian/changelog entry + patch itself + debian/patches/series diff (which specifies the patch file on the last line)
<didrocks> flexiondotorg_: uploaded slideshow rev 92, which should contain your fix
<flexiondotorg_> didrocks, Thanks.
<dholbach> flexiondotorg_, I replied to that already, no?
<dholbach> flexiondotorg_, it's already uploaded
<flexiondotorg_> dholbach, You've already uploaded the patched gtk2? ð
<dholbach> sorry
<dholbach> the indicator thing
<dholbach> which gtk2 patch
<dholbach> https://code.launchpad.net/~ubuntu-mate-dev/indicators-gtk2/indicator-application-gtk2/+merge/244116?
<dholbach> or something different?
<flexiondotorg_> dholbach, Thanks for doing the Indicators.
<dholbach> flexiondotorg_, I still don't  understand
<dholbach> flexiondotorg_, can you give me a link to the merge proposal your question was about?
<flexiondotorg_> dholbach, I have you at cross purposes. Sorry.
<flexiondotorg_> Can I jsut confirm have you uploaded the following?
<flexiondotorg_> https://code.launchpad.net/~ubuntu-mate-dev/indicators-gtk2/indicator-sound-gtk2/+merge/244120
<dholbach> yes
<dholbach> you should have gotten a mail about it
<flexiondotorg_> and https://code.launchpad.net/~ubuntu-mate-dev/indicators-gtk2/indicator-application-gtk2/+merge/244116?
<dholbach> https://lists.ubuntu.com/archives/vivid-changes/2015-February/005355.html
<dholbach> the latter, not yet
<dholbach> I'm no desktop expert, so I'm not quite sure what's re-added and how it all works
<flexiondotorg_> dholbach, I'm on really shitty wifi here at the momment.
<dholbach> and I was additionally confused because bug 1319352 was marked as 'fix released'
<ubottu> bug 1319352 in ubuntu-mate "indicator-application does not work in MATE 1.8" [Wishlist,Fix released] https://launchpad.net/bugs/1319352
<flexiondotorg_> dholbach, That fixed release ralte to Trusty via a PPA because MATE isn't in the official 14.04 archive.
<flexiondotorg_> *relates
<dholbach> that's the bug mentioned in the changelog entry
<flexiondotorg_> dholbach, The indicator-application-gtk2 change has been tested by Xubuntu team and myself on stock Ubuntu, Xubuntu and Ubuntu MATE.
<dholbach> right, thanks a lot for that
<flexiondotorg_> So, from testing we are happy it works and doesn't conflict.
<dholbach> it's still hard for me (not being an expert) to find out from the MP (and links in there) what's going on
<flexiondotorg_> dholbach, Basically the .service files have been re-instated.
<dholbach> flexiondotorg_, ok... I'll play around with it
<dholbach> flexiondotorg_, what I'm just confused about is that the bug that is referenced in the MP is marked as 'fix released' - to me that makes it look like the issue is already fixed
<flexiondotorg_>  dholbach Would you like me to change that bug status?
<flexiondotorg_> MATE is not in the official archive. So, I maintain it in a PPA.
<dholbach> right
<flexiondotorg_> I submitted a fix to the PPA for Trusty. And marked it fixed.
<flexiondotorg_> Therefore, the "fix" exist in my PPAs only right now.
<dholbach> but that's the way we used those "(Ubuntu)" bug tasks - if it's "fix released", it means "this is no issue in Ubuntu any more"
<dholbach> I really don't want to be pedantic - I just wanted to explain what I thought when I looked that the MP and bug, trying to understand what needs to be done
<flexiondotorg_> dholbach, I understand.
<flexiondotorg_> I'l avoid introducing any confusion like that in the future.
<dholbach> the indicator-application-gtk2 branch fails to build for me
<dholbach> maybe somebody in #ubuntu-desktop can help fix it?
<flexiondotorg_> dholbach, It build in a PPA. Got a build log?
<dholbach> flexiondotorg_, http://paste.ubuntu.com/10202955/
<flexiondotorg_> dholbach, How strange. Same build in a PPA worked just fine?! - https://launchpadlibrarian.net/194192337/buildlog_ubuntu-vivid-amd64.indicator-application-gtk2_12.10.0.1-0ubuntu3~15.04~1_UPLOADING.txt.gz
<dholbach> I don't know
<dholbach> sorry, maybe somebody in #ubuntu-desktop or #ubuntu-quality can help to fix it?
<flexiondotorg_> dholbach, I'll chase that one. Thanks for looking into it.
<dholbach> thanks
<flexiondotorg_> dholbach, Can you look at ubuntu-mate-settings and ubuntu-mate-artwork?
<dholbach> do you have a link to those?
<flexiondotorg_> Just looking to see if the original package requests are still knocking about....
<dholbach> or is it https://code.launchpad.net/~ubuntu-mate-dev/ubuntu-mate/ubuntu-mate-settings and https://code.launchpad.net/~ubuntu-mate-dev/ubuntu-mate/ubuntu-mate-artwork to be uploaded to the archive?
<flexiondotorg_> Yes, precisely that.
<dholbach> were you waiting for a long time to get them uploaded now?
<flexiondotorg_> dholbach, Well you review them around September last year.
<flexiondotorg_> But we missed the merge window.
<dholbach> ah no... what I meant was: the need to get them uploaded just came up now?
<flexiondotorg_> They have changed since then, slightly. And cyphermox reviewed them with me in person last week.
<dholbach> ok... I didn't see a sponsoring request for them, which is why I asked
<flexiondotorg_> dholbach, No, I did have bug to upload them last year. Trying to find them.
<dholbach> nevermind, I'll take a look now
<flexiondotorg_> But, I didn't know about the adding ubuntu-sponsors back then.
<dholbach> these packages are not in the archive yet, right?
<bregma> flexiondotorg_, don't worry about the compiz MP, you proposed it after everyone was done for the day yesterday: it;s still in line for getting in by FF (assuming it passes all the tests)
<flexiondotorg_> bregma, Thanks.
<flexiondotorg_> dholbach, Correct, ubuntu-mate-settings and ubuntu-mate-artwork have never been in the archive.
<dholbach> ok
<dholbach> flexiondotorg_, is ./usr/share/glib-2.0/schemas/zubuntu-mate-live.gschema.override supposed to be "zubuntu"?
<flexiondotorg_> dholbach, Yes.
<flexiondotorg_> I work with the upstream Debian packaging team and correct naming of gschema overrides didn't arrive before the Jessie freeze.
<flexiondotorg_> So, alpha-numerically this is how I have to inforce the live session overrides ð
<dholbach> flexiondotorg_, I'm a bit unsure about the stuff going into etc/skel and if it couldn't conflict with other files at some stage
<dholbach> and etc/xdg/autostart/
<dholbach> and etc/X11/Xsession.d
<flexiondotorg_> Nothing in etc/skel has conflicted during the 14.04 and 14.10 releases.
<flexiondotorg_> I discussed etc/xdg/autostart/ with cyphermox last week.
<flexiondotorg_> The nm-applet-mate.desktop is required to overcome an issue with patches in nm-applet for GNOME3 and Unity.
<flexiondotorg_> cyphermox, Has confirmed my work around is correct.
<flexiondotorg_> The issue is MATE is the only desktop, other than GNOME3, that actually parses AutoStartConditations.
<tjaalton> pitti, Mirv: dropped libopenvg1-mesa-dev from qtbase-opensource-src{,-gles} BD so they build again
<pitti> tjaalton: yay, thanks!
<dholbach> regarding etc/skel: there you ship a default config file for tilda
<flexiondotorg_> But because MATE is not GNOME3, nm-applet.desktop as shipped will not start under MATE.
<tjaalton> almost forgot again :P
<pitti> tjaalton: nice, that'll clean up the last bit on http://people.canonical.com/~ubuntu-archive/nbs.html
<dholbach> I know that it (right now) probably doesn't conflict with anything - I'm just wondering if the mate package is best place for this - normally something like this would be shipped with tilda itself
<flexiondotorg_> So, I provide a MATE specific nm-applet that will only run under MATE.
<pitti> I cleaned up some days ago, but I didn't quite know what to do with that openvg bit
<dholbach> for the stuff in autostart I was just wondering if the files should probably have something mate specific in their name?
<flexiondotorg_> dholbach, Tilda doesn't have a system level configuration. So this way the only way to integrate it.
<Mirv> tjaalton: argh, that means I need to bump and rebuild my landing, but good
<dholbach> I was talking about shipping a file in /etc/skel
<tjaalton> pitti: ah, I was trying to find where they were showing up
<flexiondotorg_> It is only used at system install or when adding a new account, so won't clobber existing user confiurations.
<dholbach> I understand
<tjaalton> Mirv: right, it's a simple change at least
<tjaalton> well, the uploads were
<dholbach> what I'm saying is: let's say somebody else wants to ship some tilda configuration in etc/skel - in that case it'd make sense to agree on it in one canonical place - I just found it a bit confusing to see mate settings ship a default config file for tilda
<flexiondotorg_> dholbach, I see your point.
<flexiondotorg_> dholbach, ShouldI removed Tilda?
<dholbach> maybe ask the folks in #ubuntu-desktop if there's another good way to do it?
<dholbach> flexiondotorg_, do the yuyo files come from somewhere?
<flexiondotorg_> dholbach, I did check what other flavour are doing. I saw that Xubuntu and Lubuntu ship configs in their settings packages so assumed it was OK to do the same.
<flexiondotorg_> yuyo are mirroed from github.
<flexiondotorg_> https://github.com/snwh/yuyo-gtk-theme
<dholbach> could you mention that in d/copyright?
<flexiondotorg_> Sure.
<dholbach> cool
<dholbach> ok, I found two files https://bazaar.launchpad.net/~ubuntu-branches/ubuntu/vivid/xubuntu-default-settings/vivid/files/head:/etc/skel/
<dholbach> but mayb still bring it up with the desktop team to get some advice
<dholbach> I'm running out of time on a few other things now
<flexiondotorg_> dholbach, Thanks for helping.
<dholbach> anytime
<flexiondotorg_> dholbach, Yuyo Source corrected.
<flexiondotorg_> dholbach, In GitHub at least. Will need to sync with LP.
<dholbach> ok
<flexiondotorg_> Is ubuntu-mate-artwork in good shape?
<flexiondotorg_> Because if so, I can seek upload assistance elsewhere later.
<flexiondotorg_> With regard to ubuntu-mate-settings, bit concerned that will torpedo getting Ubuntu MATE official this cycle ð
<dholbach> from what I've seen it looked good, it just needed an update of d/copyright to explain which code/assets are borrowed from elsewhere, under which license and who the copyright holders are
<dholbach> send a mail to the desktop team list, ask the people there, and ask folks from other flavours too - in a few places I just wasn't sure if that was "the way to do it"
<dholbach> lunch time, bbiab
<flexiondotorg_> dholbach, ubuntu-mate-artwork copyright is updated accordingly.
<tjaalton> Mirv: uh, looks like dpkg-gensymbols wasn't too happy about dropping libopenvg1-mesa-dev build-dep
<tjaalton> or maybe unrelated, dunno
<Mirv> tjaalton: I think there's possibly a recent toolchain change causing that.
<Mirv> while preparing 5.4, I noted at one point I needed another symbols update
<tjaalton> ok.. you'll sort it out?
<Mirv> tjaalton: but it's only gles, right, the main package seems ok?
<tjaalton> apparently so
<tjaalton> still building the main package
<Mirv> tjaalton: the amd64 is past the symbol checking stage
<tjaalton> yeah just checked that myself :)
<Mirv> tjaalton: I'm landing Qt 5.4.0 (all of https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-005/+packages) on Monday anyway, but I guess there's only one symbol that'd need fixing on the -gles package
<tjaalton> ah ok, nice
<Mirv> those optional ones are on purpose there and part of the normal/-gles packaging, so it's the first symbol in the log that's actually wrong
<Mirv> I can upload a fix 5.3.2 -gles for that
<tjaalton> great
<tjaalton> actually the main package failed too
<tjaalton> on amd64
<Mirv> hmh, and the gles did not on i386
<Mirv> flaky symbols, my favorites
<Mirv> so all build logs would be needed to make sure which archs have that one symbol and which do not
<Mirv> tjaalton: so if you have time, wait the needed 2-3h still and then manipulate that single symbol only adding !amd64 etc as needed, and reupload. otherwise I'll probably simply land 5.4.0 on Monday.
<tjaalton> Mirv: probably just wait for monday then, I'll be gone in 1h :/
<Kano> hi, why does systemd-analyze not work in a current vivid live iso
<Mirv> tjaalton: yeah, I've the same problem
<xnox> Kano: beacause live-cd boots with upstart by default.
<Kano> why?
<Kano> i would remove upstart
<xnox> Kano: because ubuntu hasn't switched to systemd yet.
<xnox> Kano: it's not like there is multi-year effort to achieve that, pleora of things to fix and integrate still, and have working....
<Kano> lost time with upstart it seems
<Kano> next is mir ;)
<rbasak> hallyn: are you aware of cgmanager being stuck in vivid-proposed? lxc dep8 failure.
<rbasak> stgraber: ping, for when you get in, for kimchi NEW
<rbasak> stgraber: I have some questions - the developer is asking whether some issues are blockers for acceptance, and I'd like an answer from the person who will actually review it :)
<rbasak> stgraber: who gaughen says is you?
<rbasak> pitti: may I have some help with adt-run --changes please? I have built already using sbuild. Using just --changes seems to not do anything.
<rbasak> But the changes file doesn't include the source.
<rbasak> So do I need to specify the .dsc as well? In which case, which order?
<rbasak> I ask because it's taken dozens of minutes each try.
<rbasak> If you're around :)
 * rbasak tries --changes -B .dsc
<stgraber> rbasak: hi
<stgraber> rbasak: I just read your e-mail (gaughen forwaded it to me)
<pitti> rbasak: re from lunch; what did you run exactly? and does your .changes include the source?
<pitti> rbasak: if you built without source, you have to give the .dsc explicitly
<pitti> rbasak: otherwise, adt-run foo.changes foo.dsc --- ...
<rbasak> pitti: I built with sbuild, so I have an amd64 changes. I suppose I do have a separate source changes.
<rbasak> stgraber: arch-dep-package-has-big-usr-share has come up, because he switched to arch: any. He was arch: all, but a commenter on the ITP requested more specific per-arch qemu dependencies, and apparently you can't have that with arch: all (I didn't know that before this).
<pitti> rbasak: that's sbuild's -s option
<pitti> rbasak: but no matter, giving the .changes (or just *.deb which is pretty much equivalent) and then the .dsc should work fine
<rbasak> pitti: ah, thanks. I didn't know about that, not being a Debian uploader. I never use binary changes files for anything else ;)
<pitti> rbasak: right, it's the standard thing for a DD
<stgraber> rbasak: right. I think that's fine to override, another way around it would be to split the /usr/share stuff into a -data package which is arch:all and depend on it
<pitti> rbasak: for ubuntu I mostly run adt-run *.deb *.dsc in my /tmp/build-area/
<rbasak> stgraber: so you'd accept this without a -data split?
<rbasak> stgraber: finally, it's a web application, depends on nginx, which sets up a "system" default nginx on port 80, but he doesn't use that - he starts his own nginx daemon instance on a high port.
<stgraber> rbasak: I'd be fine with it yeah. Splitting to -data would basically make the main package empty which to me just makes things more confusing. Since you're not likely to want to co-install multiple arches of the main one (which would be a valid reason for the split), I think it's fine to override.
<rbasak> stgraber: OK, thanks. Do you want specific overrides for these tags explaining the reasoning?
<rbasak> stgraber: I don't like that at all. I suggested integrating properly with nginx, using conf-available et al, and providing the web app on http(s?):localhost/kimchi
<rbasak> He wanted to know if that would be a blocker, or if he can fix it later.
<stgraber> rbasak: yeah, I usually like to see all packages I review be "lintian -iI --pedantic" clean by providing an lintian-overrides file which overrides any irrelevant warning with a comment as to the why
<rbasak> OK
<rbasak> pitti: thanks. I understand this better now. My run of --changes -B .dsc seemed to work, but I guess the -B wasn't necessary there.
<stgraber> hmm, and I don't suppose there's a binary-only package for nginx (similar to dnsmasq-base vs dnsmasq)?
<rbasak> No. That was my first thought, but there isn't.
<rbasak> I don't want to introduce an Ubuntu delta just for that. We could request it in Debian though.
<rbasak> http://webapps-common.alioth.debian.org/draft/html/index.html suggests using http://localhost/<webapp> though.
<stgraber> hmm, so my concern then is that you'll have a change in behavior when you fix the issue as it'll be on a high port until then and will then switch to /<webapp> on upgrade
<rbasak> Unless there's a specific need to have another web server daemon instance running, it seems friendlier to the user to me to do it that way.
<stgraber> so I'd rather we do the right thing from the start
<rbasak> Yeah - I did wonder about that.
<rbasak> Probably makes it unsuitable for changing after feature freeze.
<stgraber> well, for a new package, getting an FFe isn't very difficult typically, but still, if we intend on making noise about this when it hits the archive, changing behavior a week later is suboptimal
<rbasak> So he wanted to know if this is a blocker for upload. As you're also concerned, I guess the answer is yes?
<stgraber> yeah, you'd need to provide me with a very good reason why the high port thing is needed for me to be fine with this and so far, there doesn't appear to be one
<rbasak> OK, thanks!
<rbasak> There were other minor issues but they shouldn't be any issue to fix up quickly.
<zul> can someone promote python-tempest-lib (#1420006) please its blocking the nova build
<flexiondotorg_> cyphermox, Are you available?
<stokachu> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: open | 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: stokachu
<cyphermox> flexiondotorg_: sure, what's up?
<flexiondotorg_> cyphermox, How are you fixed today?
<flexiondotorg_> cyphermox, I got some stuff done with dholbach earlier.
<cyphermox> yeah, I read backlog
<flexiondotorg_> cyphermox, I think dholbach is now on to other tasks.
 * dholbach hugs stokachu
<dholbach> yes I am
<flexiondotorg_> cyphermox, Can you pick up the baton?
<dholbach> stokachu can maybe also help out - he just went on review duty - but I'll leave you guys to it
<stokachu> o/
<flexiondotorg_> stokachu, Hi
<flexiondotorg_> stokachu, If you have some time for package uploading please let me know. I'm the Ubuntu MATE dev and trying to get everything I need in the official archive.
<stokachu> flexiondotorg_: hey there
<pitti> apw: I noticed you have a "merge initramfs-tools: INPROGRESS" on https://blueprints.launchpad.net/ubuntu/+spec/core-1411-systemd-migration
<stokachu> flexiondotorg_: sweet! what can i help with
<pitti> apw: question 1: will that still actually happen for vivid, as it's quite intrusive?
<flexiondotorg_> I have a package that hasn't been reviewed yet.
<pitti> apw: question 2: how does that affect the systemd transition?
<flexiondotorg_> And a couple that have been reviewed a couple of time are most likely ready for upload.
<pitti> apw: i. e. was that just a convenient place to record "merging i-t is overdue", or is there some actual effect on booting there?
<flexiondotorg_> StevenK, Which do you fancy?
<flexiondotorg_> StevenK, sorry.
<flexiondotorg_> stokachu, Which do you fancy.
<stokachu> flexiondotorg_: lets do the uploads first
<pitti> apw: the one thing that comes to my mind there is mounting /usr from the initramfs (as in 0.118 in Debian)
<stokachu> flexiondotorg_: then ill review the other package
<pitti> apw: but systemd has several patches to deal with mounting /usr from the real system, and 0.118 still didn't promote in Debian because apparently there was some fallout?
<flexiondotorg_> stokachu, https://code.launchpad.net/~ubuntu-mate-dev/ubuntu-mate/ubuntu-mate-artwork
<flexiondotorg_> That has been review by cyphermox and dholbach. All feedback implemented.
<stokachu> flexiondotorg_: is there a MP?
<cyphermox> stokachu: it's a new package ;)
<stokachu> is there a new package bug somewhere?
<pitti> tkamppeter: hallo, wie gehts?
<pitti> tkamppeter: did you notice the cups test regression in https://jenkins.qa.ubuntu.com/job/vivid-adt-cups/75/ARCH=amd64,label=adt/console? that holds the last cups upload in -proposed
<pitti> tjaalton: hm, the qt uploads are FTBFS..
<pitti> yay C++ symbol mangling
<flexiondotorg_> stokachu, There was at some point or though dholbach and I could track it down earlier.
<flexiondotorg_> stokachu, If you need a bug against what should I file it?
<stokachu> flexiondotorg_: https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages#Requesting_a_new_package_for_Ubuntu
<stokachu> just need a new package bug filed
<stokachu> you dont need to worry about debian as this is ubuntu specific
<stokachu> flexiondotorg_: heres an eg: https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages/ExamplePackageRequest
<flexiondotorg_> stokachu, Thanks.
<stokachu> flexiondotorg_: no thank you :) and please let me know when those are done and ill get started on it
<hallyn> rbasak: sigh
<stokachu> flexiondotorg_: you'll want to create one for each new package you need uploaded
<stokachu> flexiondotorg_: assuming they don't exist yet in ubuntu
<flexiondotorg_> stokachu, Hah. Here is the original bug ð
<flexiondotorg_> https://bugs.launchpad.net/ubuntu/+bug/1368218
<ubottu> Launchpad bug 1368218 in Ubuntu "[needs-packaging] ubuntu-mate-artwork and ubuntu-mate-settings" [Wishlist,New]
<stokachu> flexiondotorg_: ah ok perfect
<hallyn> rbasak: i'm at the publishing history - how do i get to the lxc dep8 failure results page?
<rbasak> hallyn: go from http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
<hallyn> stgraber: I don't supose https://jenkins.qa.ubuntu.com/job/vivid-adt-lxc/lastBuild/ARCH=amd64,label=adt/console is a known transient failure?
<stokachu> flexiondotorg_: ok great, give me a few minutes and ill work on these 2
<flexiondotorg_> stokachu, Thanks!
<stgraber> hallyn: oh right, I meant to look into that. Looks like it's stuck on test-ubuntu which is known to take quite a while.
<cyphermox> flexiondotorg_: you'll also need one for the metapackage
<stgraber> hallyn: it may be that a firewall change or similar is now preventing the jenkins builder from reaching cloud-images.u.c
<flexiondotorg_> cyphermox, Yep and yuyo.
<cyphermox> indeed.
<flexiondotorg_> I'm going to file them shortly ð
<hallyn> stgraber: ok, so you know that bc it just runs them alphabetically?
<stgraber> hallyn: yep
<stgraber> hmm, so it hanged quite a few times, certainly not transient...
<stgraber> lets see if I can reproduce the issue in kvm here (since we clearly don't hit that problem in LXC CI)
<hallyn> trying to reproduce locally with the new cgmanager
<stgraber> it's been failing since the first LXC 1.1 upload, so it's not caused by cgmanager, my guess is that it may be lxcfs
<stgraber> or a firewall/proxy change in Canonical CI
<hallyn> oh yeah, if i can clear other things i need to track downthat lxcfs issue
<valavanisalex> Hi there, can someone please advise on why/when packages in main should use dh_translations?  I implemented in in the Inkscape package ages ago as a replacement for some much older translations handling code http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/vivid/inkscape/vivid/revision/6 although I've never fully understood why we needed it
<tkamppeter> pitti, I got the notification but did not set up VPN access yet here. I never had a triggering of this kind of test. What happened exactly.
<pitti> tkamppeter: you don't need VPN access, the jenkins.qa.ubuntu.com URL is public
<pitti> tkamppeter: latest cups upload fails its autopkgtest, while the previous versions succeeded; so it's a regression and britney holds it back (http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#cups)
<hallyn> stgraber: tests passed here...
<stokachu> flexiondotorg_: building now, ill ping you once ive tested these 2
<flexiondotorg_> stokachu, Thanks.
<stgraber> hallyn: same here
<stgraber> hallyn: so I'm going to blame the Canonical CI environment and push an override
<stgraber> pitti: FYI ^
<hallyn> stgraber: thx
<hallyn> rbasak: say, in uvtool, have youconsidered tuning the backing store files?
<rbasak> hallyn: tuning how?
<hallyn> i.e. preallocation=metadata,compat=1.1,lazy_refcounts=on is supposed to be a nice speed increase
<rbasak> Oh. I didn't know about that.
<hallyn> also i've tried forcing uvtool to give me 'cache=none' by default, but it doesn't seem to work.  (even wehn i hard-code 'unsafe=true' in the code)
<hallyn> rbasak: i'm not sure how you're creating the files, i.e. if you're using a library that doesn't expose those...
<hallyn> just thought i'd bring it up
<rbasak> I'm downloading the files from the simplestreams source.
<hallyn> since i saw it
<hallyn> since i say my disk is compat-0.10
<rbasak> Is there any downside to this tuning? I wonder if we should be publishing from cloud-images like this already if not.
<rbasak> uvt-kvm has an --unsafe-caching option, which messes with the template XML provided. Maybe that's affecting it?
<hallyn> well, precise couldn't do compat=1.1 i guess, only 1.0
<rbasak> I didn't notice much of a speedup with that though.
<rbasak> I see.
<hallyn> did you look at the xml afte rusing that option?
 * hallyn tries again
<hallyn> you don't actually support precise right?
<pitti> stgraber: for lxc? well, the tests passed before..
<rbasak> So on releases that support it, I could rewrite the image to make it faster? That sounds like it's worth doing - at least as an option, or by default with an option to disable or something.
<Daviey> I've done some qemu testing, and unsafe io has a signficant perf' improvement (obv. with the bad karma attached to it)
<hallyn> rbasak: looks like i messed up before, bc unsafe-caching is working for me, thx
<pitti> hallyn, stgraber: I overrode the lxc failure for cgmanager and dnsmasq already, but for lxc itself it's a real test regression
<rbasak> I do support precise, sort of. Juju uses uvtool on precise for KVM support. But the feature set needed is only a subset of developer CLI usage.
<stgraber> pitti: well, both hallyn and I managed to get LXC to pass fine under adt on our own network
<stgraber> pitti: so in theory, exact same kvm environment as Canonical CI
<stgraber> pitti: since it's hanging on a test which pulls packages and cloud images over the network, I'm tempted to blame a firewall/proxy change
<hallyn> well no mine was just a handbuilt vm
<pitti> stgraber: the host on CI is trusty, i. e. it's trusty's QEMU; and then there's the network proxy; maybe it's related to either of that?
<stgraber> ah, ok, well, mine was proper adt-run using a vivid kvm
<pitti> stgraber: ah, so proxy then?
<pitti> so what changed in the test or in LXC wrt. proxy handling?
<stgraber> yeah, that's my guess. Since I can't reproduce it here it's hard to tell, but my best guess is that it's hanging on the wget of the cloud image, passes the timeout and gets killed
<stgraber> nothing, the tests haven't changed since rc1
<hallyn> Daviey: yeah especially on apt-get dist-upgrades (especially with kernel updates) cache=none or cache=unsafe is a huge difference
<stgraber> and I also need to use a proxy in my home environment so that part sure is working
<stgraber> my guess is that what changed is Canonical's network/proxy
<rbasak> hallyn: I filed https://bugs.launchpad.net/uvtool/+bug/1421690 for your optimisation suggestion - thanks.
<hallyn> rbasak: might be worth finding time to do some perf measurements with some of those tunables
<ubottu> Launchpad bug 1421690 in uvtool "Images could be more optimised for better performance" [Wishlist,Confirmed]
<hallyn> rbasak: cool, thanks
<hallyn> btw http://sevennet.org/2015/01/08/how-to-incredibly-slow-kvm-disk-performance-qcow2-disk-files-virtio-programming-dev-development/ was one example reference
<pitti> stgraber: hm, doesn't work very well on my host either (vivid, no proxy): http://paste.ubuntu.com/10206330/
<stgraber> odd
<stgraber> oh, I see one problem with my manual test at least, let me rerun that
<pitti> that's different than the timeout on CI, though; so it could certainly be that the proxy in the DC changed in some way
<Daviey> hallyn: I also experimented with using eatmydata within the guest and saw *some* improvement (so lie about fsync's within the guest and outside), but it was inconsistent.. probably just skew that would averaged out if watched long enough
<pitti> stgraber: the above error happens in vivid too, though (~rc4)
<stgraber> pitti: I wrongly assumed that adt-run would use -proposed... how do I tell it to run using vivid-proposed?
<rbasak> stgraber: --apt-pocket=proposed -U
<pitti> stgraber: --apt-pocket=proposed -U
<pitti> stgraber: well, if you don't specify anything it will use whatever is configured in the VM
<pitti> stgraber: but if you just used adt-buildvm-ubuntu-cloud, that doesn't have -proposed enabled by default
<stgraber> right, that's what I used
<stgraber> ok, so rc4 was clean here, retrying with 1.1.0 now
<stgraber> hmm, the VM fails to upgrade
<hallyn> Daviey: oh, on btrfs eatmydata is the difference between 1 min and 20 mins
<pitti> stgraber: are "/usr/sbin/deluser: The user `lxcunpriv' does not exist." and "ERROR: Unable to fetch GPG key from keyserver." expected, or causes for the failure that  I see?
<hallyn> stgraber: fwiw i did use proposed in my test
<Daviey> hallyn: in tandem with unsafe cache or alone?
<pitti> but for sure "container creation template for tmp.fc9zKfXCVv failed" is a hard fail
<stgraber> pitti: the GPG error is fatal
<stgraber> pitti: http://paste.ubuntu.com/10206408/
<cjwatson> bdmurray: The Contents publisher race should be fixed now, so I expect it to be reliably updated as of tomorrow morning's run.  Please let me know if you see it falling behind again.
<pitti> stgraber: uh, how old is that VM? that bug was fixed ages ago
<flexiondotorg_> stokachu, This would be next I guess - https://bugs.launchpad.net/ubuntu/+bug/1421694
<stgraber> pitti: about 30min old
<ubottu> Launchpad bug 1421694 in Ubuntu "[needs-packaging] grub2-themes-ubuntu-mate" [Undecided,New]
<pitti> stgraber: ok, which autopkgtest version do you have?
<stgraber> pitti: whatever's in trusty
<pitti> this was fixed in 2.17
<stgraber> got 2.14
<pitti> during utopic when we merged the new sysvinit, which now requires LSB headers
<pitti> ok, so that explains that bit
<stgraber> is there a more recent version of autopkgtest I can use on trusty? (also, please SRU)
<pitti> stgraber: http://archive.ubuntu.com/ubuntu/pool/main/a/autopkgtest/autopkgtest_3.9.5git1_all.deb will work fine on trusty
<stgraber> pitti: I guess I've got to rebuild the VM image after installing that right?
<pitti> stgraber: happy to upload current vivid to trusty, but it's a helluva change
<stokachu> flexiondotorg_: cool will build those next
<pitti> stokachu: right
<stokachu> pitti: \o/
<pitti> err, stgraber: right
<pitti> stokachu: sorry :) sometimes weechat's tab completion is too clever :)
<stokachu> pitti: haha no worries
<seb128> shell question
<seb128> if used [ ... -o ... ]
<seb128> is the second condition evaluated even if the first one is true?
<pitti> I don't think shell can even have a concept of short-circuiting, as it replaces variables and substitutions first
<seb128> pitti, well, if you do [ ... ] || [ ... ] it seems to be different?
<pitti> seb128: it depends on what you put there really
<seb128> pitti, context is https://code.launchpad.net/~mathieu-tl/mtp/lp1421664/+merge/249669
<seb128> so it's
<seb128>  if [ -z "$disconnected" ] || [ "$disconnected" -ge 1 ];
<stgraber> I'd expect test to return immediately after the first, but as pitti said, if you're using command output or similar, those are parsed before anything else so will run anyway
<seb128> vs
<seb128>  if [ -z "$disconnected" -o "$disconnected" -ge 1 ];
<seb128> the second version returns an illegal argument in case the variable is emptyu
<seb128> illegal argument +error
<seb128> the first one works
<ogra_> because you call -o "" -ge 1
<stgraber> right, because: "test -z "" -o "" -ge 1" isn't valid
<seb128> ogra_, right, and in the other case as well?
<seb128> is [ "" -ge 1 ] valid?
<ogra_> yeah
<seb128> but "" is not a number?
<pitti> no, it's not numeric
<ogra_> -o expects some content
<stgraber> in the other case you call 'test -z "" || test "" -ge 1' so you never call the second's test argument parser
<ogra_> tthat too
<stokachu> flexiondotorg_: hate to ask this but do you mind creating another needs-packaging but for just ubuntu-mate-settings
<pitti> seb128: how about [ "${disconnected:-0}" -ge 1 ] ?
<stokachu> flexiondotorg_: im finishing up ubuntu-mate-artwork now
<flexiondotorg_> stokachu, Sure thing.
<hallyn> Daviey: oh, sorry - this was in containers actually
<stokachu> bug*
<hallyn> (eatmydata on btrfs)
<seb128> pitti, well, the [ ] || [ ] version works, I was just trying to understand the difference
<stokachu> flexiondotorg_: awesome thank you
<pitti> seb128: yeah, [ -o ] is one test command which is syntactially invalid
<pitti> seb128: while the || are two commands, and the second isn't evaluated at all if it's empty
<pitti> seb128: so that will also do what you want indeed
<seb128> pitti, ok, makes sense
<seb128> stgraber, ogra_, pitti, thanks
<pitti> seb128: although using a default value might be more concise
<ogra_> but even "" -ge 1 should work without error
<pitti> no, it  shouldn't
<stgraber> seb128: [ blah ] is a shell convenience syntax for "test blah" so the difference is in the first case, the test built-in command does the parsing of the whole condition, in the second, you do two calls to shell with the second conditional on the first passing
<pitti> an empty string isn't a number
<pitti> $ test "" -ge 1
<pitti> bash: test: : Ganzzahliger Ausdruck erwartet.
<pitti> (bah, German FTW!)
<ogra_> oh, k
 * ogra_ fires up google translate 
<ogra_> :P
<seb128> lol
<flexiondotorg_> stokachu, https://bugs.launchpad.net/ubuntu/+bug/1421703
<ubottu> Launchpad bug 1421703 in Ubuntu " [needs-packaging] ubuntu-mate-settings" [Undecided,New]
<stokachu> flexiondotorg_: thank you!
<bdmurray> cjwatson: will do, thanks for fixing that!
<flexiondotorg_> stokachu, I need to run some errands. I'll be back later.
<stokachu> flexiondotorg_: np ill ping you when ive done the 2 and reviewed that 3rd one
<stokachu> if the 3rd package are easy fix ill go ahead and make the changes
<flexiondotorg_> stokachu, Thanks!
<stokachu> flexiondotorg_: thank you :)
<flexiondotorg_> stokachu, I've got a couple more packages, one is the meta package and one is a theme.
<flexiondotorg_> The theme is a bit busted. Should be fixed by Monday.
<flexiondotorg_> As for the meta package, it is currently hooked up to my PPAs. Which I assume need unpicking?
<rbasak> pitti: how much RAM does the adt-virt-qemu get in our infrastructure, please? I'm hitting a failure that only affects me locally, and we suspect RAM size. But I just tried 2G, and that didn't seem to fix it.
<stokachu> flexiondotorg_: is the meta package ready for some review?
<flexiondotorg_> stokachu, Sure - https://code.launchpad.net/~ubuntu-mate-dev/ubuntu-mate/ubuntu-mate-meta
<stokachu> flexiondotorg_: cool, please file a needs packaging bug on that one and ill review it as well today
<flexiondotorg_> stokachu, Nice one!
<stokachu> i can at least get that one started if there are changes to be made
<stgraber> pitti: adt really doesn't like me today... http://paste.ubuntu.com/10206702/
<tkamppeter> piti, how can I test this before upload and where do I find the autopkgtest so that I can perhaps adapt it to newer features of CUPS?
<flexiondotorg_> stokachu, https://bugs.launchpad.net/ubuntu/+bug/1421711
<ubottu> Launchpad bug 1421711 in Ubuntu "[needs-packaging] ubuntu-mate-meta" [Undecided,New]
<stokachu> flexiondotorg_: perfect, thanks!
<stokachu> bdmurray: mind flipping the bit on https://bugs.launchpad.net/ubuntu/+source/python-netaddr/+bug/1421375?
<ubottu> Launchpad bug 1421375 in python-netaddr (Ubuntu Trusty) "AttributeError when attempting to access _sys.maxint" [High,Fix committed]
<flexiondotorg_> cyphermox, stokachu Is on a roll. Anything else I need to do for the build system?
<stokachu> flexiondotorg_: nah man you good, ill ping you if i need anything else
<flexiondotorg_> Cool.
<stokachu> thanks again
<cyphermox> flexiondotorg_: the artwork, setiings, meta and yuyo packages are the main things i believe
<flexiondotorg_> cyphermox, Well MATE Tweak is really important. But we might get that in via Debian.
<flexiondotorg_> cyphermox, If not then hopefully we can get an exception in Ubuntu.
<flexiondotorg_> I'll check in irc later and over the weekend.
<tkamppeter> pitti, how can I test this before upload and where do I find the autopkgtest so that I can perhaps adapt it to newer features of CUPS?
<flexiondotorg_> I'll assess where we are on Monday to see how if using Debian is an option.
<cyphermox> flexiondotorg_: tweak is just a utility no?
<flexiondotorg_> cyphermox, It is but it is actually the big ticket item for Ubuntu MATE 15.04 ð
<flexiondotorg_> It make Compiz and the Interface switcher come to life.
<flexiondotorg_> For mere mortals.
<cyphermox> tbh as long as the metapackages are installable, you should be good to build images
<cyphermox> ah
<cyphermox> well, we'll nsee
<flexiondotorg_> cyphermox, It would be an option to drop it and any other packages that don't make the cut and host them in a PPA with user post-install instructions.
<flexiondotorg_> But, I'd really like to land MATE Tweak.
<cyphermox> no worries
<cyphermox> if you really need to, it can land in ubuntu first, but it would be best if not
<flexiondotorg_> Must dash. Thanks cyphermox stokachu dholbach and others.
<cyphermox> ttyl
<dholbach> bye flexiondotorg_
<bdmurray> stokachu: if you mean releasing the package it needs to wait 7 days and its Friday
<stokachu> bdmurray: ok
<pitti> tkamppeter: it's in the source package in debian/tests; see http://packaging.ubuntu.com/html/auto-pkg-test.html how to run it
<pitti> tkamppeter: since that seems to be the first time that you see it, I take it OdyX wrote that? :-)
<pitti> rbasak: 1 GiB by default; we have some overrides for packages which need more
<pitti> stgraber: oh, wow -- I've been trying for a year or so to reproduce that locally
<rbasak> pitti: do you happen to have an override for mysql-5.6? :)
<stgraber> pitti: well, I had it happen 3 times in a row :)
<pitti> we occasionally hit that on our infrastructure (I suppose some qemu 9p weirdness), but I never got it here
<pitti> stgraber: heh; I guess I want ssh access to your machine then :)
<rbasak> pitti, stgraber: oooh, I hit that about five minutes ago.
<pitti> rbasak: no, neither for 5.5
<rbasak> I just tried again.
<rbasak> pitti: thanks
<pitti> rbasak: are you on trusty as well?
<pitti> perhaps trusty's qemu makes that more likely for some reason
<rbasak> pitti: yes, with a custom backported autopkgtest
<rbasak> Of some random version that fixed an issue I had months ago.
<rbasak> I'd never actually seen this one before.
<rbasak> Just coincidence that you mentioned here just now I guess.
 * stgraber runs adt-run in a while loop...
<stgraber> pitti: well, here it just won't ever succeed... 10 times in a row now
<stgraber> pitti: "adt-run -s --apt-pocket=proposed -U lxc --- qemu adt-vivid-amd64-cloud.img" <- that's valid right?
<pitti> stgraber: eww; I guess I do want ssh on your machine next week..
<pitti> stgraber: correct
<pitti> stgraber: CI machines are pretty clogged right now, but I confirm that at least one machine now can't access the proxy any more
<flexiondotorg_> stokachu, OK, Yuyo theme is fixed ð
<tkamppeter> pitti, yes OdyX must have done it.
<smoser> stgraber, since you're acdtive... could you archive-admin move python3-httpretty to main for me ? depencency for cloud-init (python-httpretty is already in main).
<smoser> https://launchpad.net/ubuntu/+source/cloud-init/0.7.7~bzr1055-0ubuntu1/+build/6969483
<pitti> stgraber: RT sent to fix albali's proxy access (but the recent runs happened on other machines, so that still doesn't explain the whole story)
<stgraber> smoser: done
<stgraber> pitti: can you try connectivity to https://cloud-images.ubuntu.com from the CI lab?
<pitti> stgraber: running
<stgraber> pitti: since it's https, it may be bypassing the proxy or confusing it somehow
<pitti> I'm running https_proxy=http://squid.internal:3128 wget -O- https://cloud-images.ubuntu.com
<pitti> works on alderamin and aldebaran (where the last run happened)
<pitti> albali is known broken, and wazn doesn't respond at all (it's overloaded)
 * pitti restarts the LXC test, just to be sure
<stgraber> ok
<flexiondotorg_> stokachu, cyphermox https://bugs.launchpad.net/ubuntu/+bug/1421734
<ubottu> Launchpad bug 1421734 in Ubuntu " [needs-packaging] yuyo-gtk-theme" [Undecided,New]
<pitti> wazn works, too
<stgraber> pitti: so both lxc-test-apparmor-mount and lxc-autostart use the proxy to access GPG and images.linuxcontainers.org, lxc-test-ubuntu does a regular debootstrap using archive.u.c and creates a container using the cloud image, one of those two must be failing
<stgraber> ok, 20 times and still stuck on the same adt issue, time to boot a vivid box...
<stgraber> pitti: if it's reasonably easy for you, can you start a VM on one of those hosts, then install lxc-tests from vivid-proposed, do the two exports (http_proxy and https_proxy) and then "sudo sh -x /usr/bin/lxc-test-ubuntu" and see where it gets stuck
<stokachu> flexiondotorg_: thanks, i commented on the ubuntu-mate-meta one
<pitti> stokachu: it is; but I need to run now, I'm afraid; I'll do that Monday morning
<pitti> bah!
<stgraber> :)
<pitti> stgraber: it is; but I need to run now, I'm afraid; I'll do that Monday morning
<stgraber> pitti: ok. I'm getting ready to run adt on a vivid machine here so I can make sure that they pass fine
<stgraber> (lxc-test-ubuntu is run for every commit upstream so I see no reason why it wouldn't work...)
<pitti> cheers
<flexiondotorg_> stokachu, Regarding germinate I copied what the Ubuntu and the other flavours do.
<stokachu> cyphermox: ^ im not familiar on the use of germinate in debian packaging
<cyphermox> for ubuntu-mate-meta?
<stokachu> yea
<cyphermox> the update script writes to the relevant files for you based on what is on the seeds
<stokachu> ah ok
<cyphermox> these files get used to generate the list of Depends for the packages
<cyphermox> (and Recommends)
<stokachu> gotcha
<stokachu> flexiondotorg_: with that settled do you want me to update the other recommendations i made?
<stokachu> i can make the changes myself if you want
<flexiondotorg_> stokachu, If you could that would be great.
<cyphermox> stokachu: as I recall you'll see there is one of the files which maps packages to the "seed" files, that gets read in to replace $germinate:Depends
<stokachu> flexiondotorg_: yep will do
<flexiondotorg_> stokachu, Cheers.
<smoser> stgraber, thank you
<stokachu> flexiondotorg_: done
<flexiondotorg_> stokachu, Oh oh, what is? ð
<flexiondotorg_> stokachu, meta package. Nice!
<flexiondotorg_> cyphermox, Here comes the breakage right? ð
<stokachu> flexiondotorg_: all of them
<flexiondotorg_> stokachu, Super cool.
<stokachu> flexiondotorg_: thanks man, lemme know if you need anything else
<flexiondotorg_> stokachu, That is absolutely brilliant.
<flexiondotorg_> Thank you so much!
<stokachu> np :)
<flexiondotorg_> stokachu, You've totally made my weekend.
<stokachu> flexiondotorg_: haha, /fingers crossed i didn't break anything
<stokachu> flexiondotorg_: glad to help, thanks for your contributions to Ubuntu :)
<flexiondotorg_> stokachu, My pleasure.
<popey> flexiondotorg_: killed any kittens with your changes yet? :)
<flexiondotorg_> popey, Not yet. cyphermox Will builds "happen" now? popey wants to see some carnage.
<popey> hey dude it's friday evening, friday is best day for carnage
<flexiondotorg_> Right, I'm off then. Everyone have fun with that. I look forward to error logs or something ð
<flexiondotorg_> I'll go back to the Debian guys and try to get the last packages uploaded.
<cyphermox> popey: not quite yet
<flexiondotorg_> cyphermox, What is next?
<cyphermox> but I'll get that shepherded to completion
<flexiondotorg_> cyphermox, When it explodes please point me to error logs so I can help clean up the mess.
<flexiondotorg_> The meta package is requesting caja-actions, mate-tweak and mate-menu that I am trying to get upload via Debian.
<flexiondotorg_> So I imagine it will fail.
<cyphermox> once all the packages have been uploaded and reviewed by the archive team, a ubuntu-cdimage merge to be reviewed by the gods among us, and then kicking off an image.
<cyphermox> yeah, things will fail to install and/or build
<cyphermox> before you get a live cd these packages will need to exist or be removed from the seed.
<cyphermox> I'm hungry
<flexiondotorg_> cyphermox, Enjoy your soup ð
<flexiondotorg_> Bye for now. And thanks to everyone who helped me today. You've been great.
<stgraber> pitti: ok, I think I've found the problem with lxc-test-ubuntu
<stgraber> pitti: it's got to do with the ubuntu-cloud template failing to recognize vivid
<stgraber> I'll upload an updated cloud-image-utils fixing that
<stgraber> hallyn: FYI ^
<hallyn> stgraber: d'oh
<hallyn> then why wouldn't it fail when i ran it locally?
<stgraber> did you run it on vivid?
<hallyn> yup
<stgraber> hmm, then I don't know. Here "lxc-create -t ubuntu-cloud -n test -- -r vivid" was failing immediately with an error saying that vivid is invalid
<hallyn> and lxc-test-ubuntu does that?
<stgraber> it doesn't pass -r but that defaults to current series
<stgraber> root@autopkgtest:~# lxc-create -t ubuntu-cloud -n vivid
<stgraber> ubuntu-cloudimg-query is /usr/bin/ubuntu-cloudimg-query
<stgraber> wget is /usr/bin/wget
<stgraber> confused by argument: vivid
<stgraber> There is no download available for release=vivid, stream=daily, arch=amd64
<stgraber> root@autopkgtest:~#
<stgraber> that's what lxc-test-ubuntu does ^
<hallyn> maybe mine was automatically setup for a differnet stream than daily?
<hallyn> slangasek: stgraber: infinity: so cgmanager 0.36-1 regresses some systemd-shim users bc it can't reach /var/run/nscd/.  trying to think of the cleanest solution
<hallyn> no wait, that cnsa't be it
<hallyn> but it does want /usr available to read libnss
<hallyn> ok think i've got it
<hallyn> i assume pitti is eow so i'll need to bug someone else to sponsor the fix :)
<hallyn> xnox: hm, having a libnih issue - cgmanager --daemon is not causing /run/cgmanager.pid to be created
<hallyn> nih/main.c leads me to believe that should happen
<teward> probably a stupid question, but is there a way to make a build environment for Debian packages against the Debian repository as well as Ubuntu?  For when I set up my own repository, and I build nginx packages, I would like to have packages available for my Debain server on my own net as well in my own repository.
<xnox> hallyn: let me check.
<xnox> hallyn: where is the source code of cgmanager?
<xnox> https://github.com/lxc/cgmanager?
<hallyn> xnox: yeah
<sarnold> teward: ought to be doable via sbuild / schroot ..
<teward> sarnold: so, what, just follow the sbuild guide, but choose a schroot of `unstable`, `testing`, etc.?
<sarnold> teward: I think so, I've got the schroots set up but never tried building in them :) hehe
<teward> heheheh
<teward> sarnold: no time like the present to test XD
<xnox> hallyn: it writes out /var/run/argv[0].pid
<xnox> hallyn: unless e.g. nih_main_set_pidfile() is called to set something else.
<hallyn> xnox: ooooh.
<hallyn> xnox: it's upset bc /var/run/cgmanager is already a directory, maybe?
<hallyn> nah, that would be stupid
<xnox> hallyn: .pid is appended as well.
<hallyn> but anyway /var/run/cgmanager.pid is not being created, and that makes sysvinit stop of cgmanager very slow
<hallyn> xnox: i'll get to the bottom of that, but in th emeantime, do you mind sponsoring http://mentors.debian.net/debian/pool/main/c/cgmanager/cgmanager_0.36-2.dsc ?
<hallyn> i'd ask pitti but i thin khe's out fo rthe week
<xnox> hallyn: i'm on trusty, and cgmanager is spawned with --sigstop, rather than --daemon.
<xnox> hallyn: oh, debian.
<hallyn> yeah, sysvinit
<hallyn> it's fine in upstart
<hallyn> well it's only a pain on restarting in sysvinit.  like i say i'll dig into it, was just wondering whehter you know offhand since for some reason i have this feeling you deal with libnih a bit
<xnox> hallyn: so, on trusty it seems to be fine.
<xnox> hallyn: as in .pid file is created. However debian's libnih might be different here.
<hallyn> xnox: oh.  yeah.  didn't even think of that
<hallyn> you run trusty with sysvinit?
<xnox> hallyn: no, i run trusty with upstart. I've stopped cgmanager and did $ sudo cgmanager --daemon and then check /var/run/cgmanager.pid to be the one that is running.
<hallyn> xnox: d'oh
<hallyn> xnox: ti's not libnih's fault.  the pidfile is being created, but in the new mntns.  (i thought that happened earlier)
<hallyn> i'll have to think about that one.
<hallyn> so /run on host is a tmpfs, and /run/cgmanager.pid is being created on the rootfs /run
<xnox> hallyn: huh? is /run mounted as tmpf _after_ cgmanager started?!
<hallyn> no,
<hallyn> cgmanager bind-mounts / (non-recursively) and pivots into that
<hallyn> it needs to somehow shed all mounts it doesn' tneed.  BC otherwise if /foo is mounted on the host, then cgmanager starts, then hos tumount s/foo, then /foo stays mounted in cgmanager's namespace
<hallyn> (starting to feel dirty yet?)
<hallyn> xnox: so in case it got lost in the noise, woul dyou mind sponsoring http://mentors.debian.net/debian/pool/main/c/cgmanager/cgmanager_0.36-2.dsc to sid?
<xnox> hallyn: i'm not quite sure where you shedding the mountpoints, but clearly you want to keep /var/run mountpoint (or anyhow that points to, e.g. usually symlink to -> /run)
<hallyn> why clearly?
<hallyn> i'm shedding the mountpoints by doing a non-recursive bind-mount of / onto NEWROOT, then pivot_root'ing to NEWROOT
<hallyn> I have a /run/cgmanager for my own private (cgroup_ mounts, but I don't need the /run tmpfs, really.  Now that one would be safe, so yeah I could bind-mount that too, and that would probably fix this
<hallyn> really this *should* be a common idiom for any daemons that want to run in MS_PRIVATE
<sarnold> one almost suspects there should be a kernel-provided mechanism to bring only selected mounts into the new namespace..
<hallyn> lemme see if bind-mounting /run fixes the issue
<hallyn> sarnold: agreed - with the caveat that i can't think of a good way to choose 'selected' mounts
<sarnold> hallyn: no, me neither :)
<hallyn> heck,
<hallyn> maybe this is something worth discussing at a conference.  use cgmanager as an example,
<hallyn> ask whether others feel this needs generalization
<hallyn> xnox: oh, there's a bug in the .dsc i was pointing you at anyway
<hallyn> (minor one;  extra arg sent to printf)
<hallyn> ok ,so bind-mounting just /run (no sub-mounts) fixes the sysvinit issue.  i'll push that fix to git and then push a new .dsc
<cjwatson> teward: sbuild is *from* Debian, it works fine *for* Debian :-)
<hallyn> sigh, ok, that's pushed to mentors.  now to take a walk and clear my head
<Unit193> So can I ignore the warning at the top to remove the duplicate 'contents' title on https://wiki.ubuntu.com/UbuntuDevelopment/DeveloperApplicationTemplate ?
<cjwatson> I would think so
<cjwatson> the point is to discourage people from editing their own application text into it
<Unit193> Yes, figured that.  But since it's somewhat of an important page figured I'd ask.  Thanks.
<hallyn> slangasek: hey, would you mind sponsoring http://mentors.debian.net/debian/pool/main/c/cgmanager/cgmanager_0.36-2.dsc into sid?
<stokachu> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: open | 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:
<slangasek> hallyn: so if we're bind mounting the rootfs, what's the purpose of having a separate namespace here?
#ubuntu-devel 2015-02-14
<hallyn> slangasek: the point of the separate ns is so that /run/cgmanager/fs/* mounts get cleaned up when cgmanager exits
<slangasek> ah, ok
<hallyn> yeah i had almost convinced myself to just not do it, but it'll lead in redisual mounts and complicate restart
<ahoneybun> Riddell, I found a wordpress theme making who has a company who makes a few free themes from non profit companies
<hallyn> sigh, i'm really quite bad at remembering to quilt add files to a patch
<kees> xnox: say... can you fix mplayer in trusty? it's really really busted.
<xnox> kees: bug #?
<kees> https://bugs.launchpad.net/ubuntu/+source/mplayer/+bug/1352447
<ubottu> Launchpad bug 1352447 in mplayer (Ubuntu Trusty) "regression: mplayer detects video frame rate as -nan" [High,Confirmed]
<kees> and now it likes to segfault on perfectly valid streams. had to downgrade _another_ machine today :(
<kees> xnox: also, mencoder is needed.
<xnox> kees: =((((
<xnox> kees: i actually hate all of that audio/video stuff, but did do "binNMUs" and patches to get them "fixed" a lot....
<kees> xnox: easy fix! revert to precise's mplayer ;)
<kees> actually, I have no idea. I should see if the current debian mplayer works correctly.
<kees> regardless, mencoder is seriously needed. it's the only thing that does deinterlacing correctly.
<kees> I suppose I should go complain to Reinhard :)
<slangasek> kees: --> siretart ? :)
<aeoril> darkxst I have found out that some init code in vte.c (vte_terminal_init()) which initializes the terminal gtk3 widget uses default values of 80x24 for columns and rows the call to vte_terminal_set_size().  A widget method is set to vte_terminal_set_size() also, so I would think that as the gtk3 widget responds to resizing, it probably "automatically" calls that method I guess?  Somehow
<aeoril> maybe the timing is such between the initial setup of gnome-terminal, the resizing done via the --geometry command line argument and the loading of the vim child process within the gnome terminal sometimes the resize causes all the lines to be shown, sometimes only 24 (the default value hard coded into vte.c).  I could use a little help/direction on where to look next to figure out how
<aeoril> all this stuff works together and where in the code I should be looking - I am thinking of downloading the gnome-terminal code to see how it uses libvte (vte3, the code I am looking at now)
<darkxst> aeoril, but are you getting the default size? I though it was just off by a couple of lines or something?
<aeoril> darkxst no, I am getting the default size - sorry if that was not clear - 24 lines are shown, the rest of vim down to the bottom of the enlarged gnome-terminal is blank lines, or invisible
<aeoril> rows == 24, not sure about columns - I guess I need to test that
<darkxst> if its a race perhaps running something like "sleep 5;vim" might identify it
<darkxst> or you could try and hook into the resize event with gdb and see what is going on
<aeoril> darkxst yahhhoooo!  "sleep 1;vi ..." fixes the problem
<darkxst> aeoril, turn on debug messages that might help
<aeoril> darkxst yes, I have been planning on that
<aeoril> darkxst there do not seem to be command line switches to turn on debugging in gnome-terminal or vim - do I need to compile that in?
<darkxst> aeoril, probably a env var to turn it on
<aeoril> darkxst for gnome-terminal, I have to do both - compile debugging in and set an environment variable:  https://wiki.gnome.org/Apps/Terminal/Debugging  for vim, -g option on compile
<aeoril> darkxst apparently, gnome-terminal has a client-server achitecture.  To debug, you have to start up the server, then hook to it with a client within 10 seconds
<aeoril> using gdb
<aeoril> probably make the timing issue impossible to reliably reproduce
<darkxst> aeoril, vte has a VTE_DEBUG that should turn on debug message
<aeoril> oh, didn't think about vte ... thanks
<aeoril> Actually, I thought about it, but found no manpage and forgot after that
<aeoril> thanks anyway
<darkxst> grep -R getenv
<aeoril> darkxst I was wondering how you found that ...
<darkxst> aeoril, the code is often the best documentation ;)
<aeoril> darkxst yes, I am finding that out ... :)
<aeoril> darkxst I still need to define VTE_DEBUG when I compile, though
<aeoril> (#ifdef)
<darkxst> aeoril, ok
<darkxst> I have never really worked with vte or gnome-terminal
<aeoril> darkxst yes, but we are closer now than two days ago - thanks for the help again.  I'll tell you a secret - I have never worked with them before either ha ha!
<darkxst> I pretty much assumed that
<aeoril> darkxst that was a joke :)
<darkxst> yes
<aeoril> well, afk.  Tomorrow is another day
<darkxst> maybe this was fixed as part of the re-wrap implementation? don't think that was in trusty?
<aeoril> re-wrap?
<darkxst> aeoril, http://blogs.gnome.org/mclasen/2013/12/09/a-terminal-surprise/
<aeoril> Cool, thanks.  Will look into it tomorrow :)
<aeoril> darkxst I think I saw some stuff about wrapping in the latest code on vte maybe?
<darkxst> aeoril, probably
<darkxst> likely in 14.10 also
<aeoril> darkxst 14.10 exhibits this problem too, though much less often (about 5 % of the time as opposed to 60-70%)
<darkxst> aeoril, races will always be tricky
<aeoril> darkxst but races must be wone!
<aeoril> won*
<aeoril> darkxst I wish I could get an audience with chpe!
<darkxst> aeoril, many of the GNOME devs are on US Business Hoursy-ish
<darkxst> some are also EU
<darkxst> very few around on weekends
<aeoril> darkxst good to know - I will post Tuesday earlier my same queries (Monday is a holiday)
<aeoril> I should know the code better by then as well, and have looked at the gnome-terminal code some
<aeoril> darkxst I am not wondering if it has something to do with the client-server architecture of gnome-terminal - server/client hookup timing or something like that
<aeoril> s/hookup/interactions/
<darkxst> no idea
<aeoril> darkxst I may be able to figure some of that out from code
<darkxst> tbh  I don't even know what the client-server split involves (ie which bits do what)
<aeoril> darkxst yes, I was just thinking that to myself, actually - I need to figure that out really
<darkxst> aeoril, can you build trusty gnome-terminal with current vte?
<aeoril> difficult I think - different so name/number/whatever
<aeoril> not really sure
<darkxst> aeoril, thats not actually a problem in itself at build time, however often it means there are incompatible api calls
<aeoril> darkxst wouldn't I have to screw with the build setup though if the library has a different name?
<darkxst> aeoril, no its automatic
<darkxst> the build depend would be libvte3-dev
<aeoril> ahhh ... cool - I can give that a try then tomorrow
<aeoril> darkxst so how do I get the vivid libvte3-dev on a trusty system to replace the old one?
<aeoril> can I do that with apt-get?
<darkxst> no
<darkxst> you will need to rebuild it on trusty
<darkxst> probably in a ppa, so its easy to backout the changes with ppa-purge
<aeoril> ok, so build from a ppa source package?
<darkxst> aeoril, grab the vivid vte, edit changelog and make it target trusty
<darkxst> then build under trusty (or upload to a ppa to build)
<aeoril> ok, I'll try that then
<aeoril> darkxst thanks again!  I should have enough to go on for now, but like I said 20 minutes ago, need to head on ... :P
<darkxst> bye
<aeoril> darkxst thanks! :)  You have again been incredibly helpful!
<darkxst> pitti, why on earth would I get asked for permission to unmount a partition when extracting a file via file-roller?
<hjd> Anyone know or have a suggestion why https://tracker.debian.org/pkg/python-click doesn't seem to have been synced to Ubuntu? I can't find it in the sync blacklist.
<ogra_> hjd, most likely because click is uploaded to ubuntu first ?
<Laney> it's a different 'click'
<Laney> but it was removed due to overlapping binary packages with the other one it seems: https://launchpad.net/ubuntu/+source/python-click/+publishinghistory
<ogra_> oh
<ogra_> heh
<darkxst> pitti, bug 1421938
<ubottu> bug 1421938 in systemd (Ubuntu) "asked for permission to unmount permission while extracting file with file-roller" [Undecided,New] https://launchpad.net/bugs/1421938
<darkxst> that should of course be partition though!
<hjd> ogra_: Laney ah ok. I thought about (ubuntu-)click but didn't know that had packages with conflicting names.
<melodie> hello
<melodie> could someone point me to the page where I can find the filesystem.manifest of Ubuntu 14.04.2 please?
<cjwatson> melodie: Nowhere, because there's no such thing as Ubuntu 14.04.2 yet.  The current builds are at http://cdimage.ubuntu.com/trusty/daily-live/current/ and the .manifest files are alongside them.
<melodie> hi cjwatson thanks, that's what I meant
<melodie> cjwatson what about the other flavors? what would be the link like for them?
<sladen> melodie: http://cdimage.ubuntu.com/kubuntu/trusty/daily-live/current/  etc
<sladen> melodie: (follow up to the top level directory, and then back down again)
<melodie> sladen thank you
<melodie> yes, I get it
<Bl4ckD34tH> why i am banned on ubuntu?
<xnox> pitti: the set of openened lazr/launchpad bugs are fixed. Your move. ;-)
<melodie> good night
#ubuntu-devel 2015-02-15
<siretart> kees: what's wrong with libavfilters yadif filter (accessible via avconv)?
<siretart> kees: it's taken from mplayer/mencoder after all
<siretart> kees: unfortunately, there is no debian mplayer, ubuntu followed debian's removal. ironically, it was me who requested its removal after years of fighting to get it into debian. :(
<darkxst_> stgraber, did you see bug 1408853 ?
<ubottu> bug 1408853 in sbuild-launchpad-chroot (Ubuntu) "Add support for adding ppa's via aliases with a new ppa command" [Undecided,New] https://launchpad.net/bugs/1408853
<Laney> There's a mail in u-d-a moderation if someone passes by
<cjwatson> Laney: .
<dpasqualin> Hello, a simple question. Is the ubuntu-sdk the recommended way to develop for ubuntu desktop too or just for mobile?
<stgraber> darkxst_: I haven't
#ubuntu-devel 2016-02-15
<cpaelzer> good morning
<alexlist> doko_: good morning :)
<alexlist> doko_: we're running into an issue that we found fixed in Debian, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=808205 but it seems it hasn't made it into an SRU for Wily yet...
<ubottu> Debian bug 808205 in libc6-dev "libc6: Unrecognized relocation when compiling" [Serious,Open]
<pitti> Good morning
<pitti> doko_: the rationale is https://lists.ubuntu.com/archives/ubuntu-devel/2015-November/038985.html
<pitti> doko_: i. e. we want to test packages in isolation as otherwise too much stuff got blocked because of unrelated breakage in other packages
<pitti> doko_: if a package from -proposed can't work with a dependency from -release, that normally indicates a missing dependency, or the versioning is not strict enough
<pitti> doko_: so for those cases we need to either fix the dependencies or do a manual run-autopkgtest with *both* packages as the trigger
<Wagaaa> Hello?
<Wagaaa> Hello?
<dholbach> good morning
<seb128> hey dholbach
<dholbach> hi seb128
<Wagaaa> I have a question
<Wagaaa> I'm a developer of a Linux team
<Wagaaa> I would to create a Debian-based System
<Wagaaa> But we don't know how to change OS Name
<mgedmin> Wagaaa, perhaps https://wiki.debian.org/Derivatives/Guidelines#De-.2FRe-branding will be helpful
<rbasak> Caribou: FYI, I just started reviewing your new clamav merge.
<Caribou> rbasak: perfect, let me know if I can help
<rbasak> Caribou: did you push your latest to LP?
<rbasak> I only see stuff based on 0.98.7+dfsg-1 still
<Caribou> rbasak: yes, there is a merge-v2 branch & the old tags points to the new branch
<rbasak> Caribou: https://git.launchpad.net/~louis-bouchard/ubuntu/+source/clamav/refs/ - I see no merge-v2 branch.
<rbasak> Am I looking in the wrong place?
<Caribou> rbasak: let me check
<rbasak> Ah, I found https://git.launchpad.net/~louis-bouchard/test/refs/?h=merge
<rbasak> I guess that's not intentional but I can use that if it's up to date?
<Caribou> rbasak: friday's mistake, I pushed it to a test repo & then forgot to update the main one
<Caribou> it's there : https://git.launchpad.net/~louis-bouchard/test
<Wagaaa> Helloï¼
<Caribou> rbasak: let me push it to the original one
<Caribou> rbasak: I just uploaded it in the right place & forced updated the tags
<Wagaaa> How ti change Debian-installer's head picture?
<rbasak> Caribou: OK, thanks!
<alexlist> doko_: https://bugs.launchpad.net/binutils/+bug/1545653
<ubottu> Launchpad bug 1545653 in binutils (Ubuntu) "Unrecognized relocation when compiling" [Undecided,Confirmed]
<pitti> doko_: I did a mass retry of all regressions against all of -proposed, that should mop up those
<pitti> l
<doko_> alexlist, can't be the issue. 15.10 has binutils 2.25.1
<doko_> pitti, well, then we need to upload every transition with tightened build-depends, introducing thousands more ubuntu deltas. not feasable
<pitti> doko_: not b-deps, binary deps; anyway, of course we don't want that big ubuntu delta, so I guess we'll need to re-try those manually
<pitti> we can't have it both ways, isolated and ignoring sloppy dependencies
<doko_> well, but having to chase this manually isn't a good way either
<pete-woods> pitti: hey, I've got some stuck autopkgtests for one of my landings, that have been running quite some time (https://requests.ci-train.ubuntu.com/static/britney/vivid/landing-070/excuses.html)
<pete-woods> ppc64el on indicator-network seems to be the kicker
<pitti> pete-woods: right, network-mananger is blacklisted on vivid/ppc64el as it keeps killing the instances; I'll add a corresponding hint for it to britney (same as for systemd)
<pitti> err, not "same as", just add it
<pitti> pete-woods: done, next run should pick this up and move to "valid candidate"
<pete-woods> pitti: awesome, thanks
<cjwatson> jamespage: could you revert the bogus changes to https://bugs.launchpad.net/charms/+source/glance/+bug/1496011 ?  I'm warning the user
<ubottu> Launchpad bug 1496011 in glance (Juju Charms Collection) "Glance charm - amqp requires is confusing" [Low,Fix released]
<pete-woods> I assume when you say "next run", this thing is another cronbeast that ticks every so often
<pete-woods> picking up whatever has changed
<pete-woods> as opposed to requiring some input from me?
<jamespage> cjwatson, done
<cjwatson> ta
<Mirv> pete-woods: yes, he means that, it updates more or less hourly
<Mirv> pete-woods: probably within 20 minutes or so. and then the train might take another 0-15 mins to notice it.
<pete-woods> Mirv: sounds good :)
<seb128> dgadomski, pitti, bug #1545302 claims to be a regression from the ifconfig per interface change
<ubottu> bug 1545302 in wpa (Ubuntu) "wpa-roam broken by fix for ifupdown #1337873" [Undecided,Confirmed] https://launchpad.net/bugs/1545302
<pitti> seb128: thanks for pointing out
<seb128> pitti, yw!
<pitti> dgadomski: could you please have a look at that patch, see if it makes sense, and forward it to Debian too?
<pitti> doko_: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#openmpi is valid candidate now, FYI (but still some uninstallability on upate_output)
<doko_> pitti, numpy not considered. please override the remaining tests
<pitti> i. e. we'll leave pyresample broken
<pitti> doko_: hinted
<doko_> I updated to the last upstream, but don't want to investigate
<doko_> pitti, for python-scipy as well?
<pitti> done
<doko_> seb128, did you e-d-s upload trigger a transition?
<Wagaaa> Hello
<Wagaaa> I have a question about make a Debian-based system
<davmor2> Wagaaa: whats the question
<Wagaaa> How to change Debian-installer's head picture
<Wagaaa> I could find live
<Wagaaa> sorry
<Wagaaa> live installer. undeb file
<davmor2> Wagaaa: this won't be the right channel then, if you ask on #ubuntu a dev there might be able to help,  but at a guess you change the image file
<ogra_> probably #ubuntu-installer ?
<Wagaaa> no
<Wagaaa> but the debian channel asked me to find another channel
<ogra_> (i mean you shoudl probably ask in that channel)
<Wagaaa> oh
<Wagaaa> I see
<dgadomski> seb128, pitti: thanks, I'm on it
<doko_> pitti, please override the palabos autopkg tests. don't care about s390x, and fails on all other archs
<kickinz1> rbasak, so I filled the MIR bug: https://bugs.launchpad.net/ubuntu/+source/pps-tools/+bug/1545699
<ubottu> Launchpad bug 1545699 in pps-tools (Ubuntu) "[MIR] pps-tools" [Undecided,New]
<pitti> doko_: done (some minutes ago)
<rbasak> kickinz1: thanks!
<Mirv> pitti: I had a vague idea something like 3 hours runime would autoabort autopkgtest but this one has been running for over 5 hours? http://autopkgtest.ubuntu.com/running.shtml#pkg-dolphin
<Mirv> an always-failed test
<pitti> Mirv: it probably was auto-retried several times due to some cloud failures
<Mirv> pitti: yeah but it claims this particular run has been there for >5h
<pitti> right, it counts the time from the first try
<Mirv> oh...
<Mirv> ok then, nothing to see here
<pitti> if it runs significantly longer, I'll dig into the logs, but for now this can be ignored
<kickinz1> rbasak, doko, is dovecot merge urgent before FF? Or should I take another more urgent merge before?
<Mirv> pitti: what about these VirtSubProc.Timeout:s on armhf that still just stay there - http://autopkgtest.ubuntu.com/running.shtml#pkg-libkscreen and http://autopkgtest.ubuntu.com/running.shtml#pkg-libqapt ?
<Mirv> maybe they'll eventually abort too
<doko> kickinz1, that would be the new upstream version 2.2.21, so not a merge. is squid3 now merged?
<kickinz1> doko, for squid3, I don't know; seems rbasak is working on it.
<pitti> Mirv: no, I need to clean those up, thanks; I thought I already worked around those, but apparently I missed a few sopts
<pitti> spots
<rbasak> doko, kickinz1: I'm switching back to the squid3 merge next. It's non-trivial. I expect to be done by FF still.
<kickinz1> rbasak, thanks for the update.
<pitti> Mirv: hm, they locked up too hard, I can't clean them up without interrupting the other tests; is that blocking you somehow?
<pitti> oh, for Qt
 * pitti reboots the worker, the other tests will then have to restart
<Mirv> pitti: ok, good that all my pings are not useless :)
<Mirv> pitti: those two are blocking qtbase from migrating from xenial-proposed, but it's not in a hurry
<pitti> Mirv: I retried them; the timed out ones are orphaned at running.html due to the way I killed them, so you can ignore them now
<Mirv> ok
<pitti> Mirv: Qt landed
<pitti> jdstrand: can I ask you to do the apparmor merge in my stead? you know the package much better than I do
<Mirv> pitti: ack, I noticed
<Caribou> rbasak: I've just replied to your merge review & would have a few things to discuss when you get a chance
<rbasak> Caribou: I replied. Looks good! Thanks.
<kickinz1> rbasak, Can you create a new/debian branch into amavisd-new on ubuntu-server-dev, so I can rebase my logical delta on this one?
<rbasak> kickinz1: ack
<kickinz1> rbasak, thanks
<doko> pitti, you can remove the unblocks for kblog and ktnef
<pitti> doko: oh? their latest runs still failed
<Caribou> rbasak: FYI, I re-introduced the cast on (unsigned long) & refreshed the patch. I'm sending an email to the pkg-devel mailing list for further details.
<Caribou> rbasak: I'll drop the armhf exception as well & do a test rebuild. It it goes through fine, I'll upload w/o the test
<Caribou> rbasak: & also fix the changelog for more precision
<rbasak> kickinz1: done, along with the standard tags and branches.
<rbasak> Actually import/1_2.10.1-1ubuntu1 is wrong. It should be upload/1_2.10.1-1ubuntu1
 * rbasak fixes
<kickinz1> Thanks!
<kickinz1> rbasak, ^
<rbasak> np
<cpaelzer> hi, I have a package that will drop two conffiles - removing was fine and works like a charm via package.maintscript
<cpaelzer> we discussed and wanted to check in postinst if a .dpkg-bak was created indicating user config might be lost and wanted to e.g. show a debconf info or so
<cpaelzer> eventually the user should be made aware like "sorry, but due to ... you have to convert your old config in X into the new format"
<cpaelzer> is there any packet did something like that in the past that I could refer to when writing that?
<doko> pitti, uploaded kcalcore
<rbasak> cpaelzer: perhaps the "flags" warning in src:mysql-5.6? It's far from a shining example of best practice packaging, but it does demonstrate the mechanics of it I think.
<doko> finally, the whole openmpi/-science mess migrated
<ginggs> \o/
<cpaelzer> rbasak: thanks I'll look into that
<doko> pitti, Laney, seb128, willcooke: aspell-he needs a MIR, or argue four weeks who will do it ... translators or desktop
<Laney> why would a dictionary need MIR?
<doko> ok, you just started day 1 out of 30 arguing ...
<Laney> doko: I would just subscribe the desktop team and promote it, or do you really care for some data files?
<doko> Laney, sure, open a MIR, and just write what you said. is this that difficult?
<doko> I used to maintain all the dicionaries as part of OOo packaging. and these should be looked at by LO packaging now
<Laney> Just promote it and I'll subscribe the team
<Laney> I'm busy doing other things so if you want paperwork you will have to wait a bit
<cjwatson> Wow, way to start a discussion with open hostility
<doko> cjwatson, what? I'm pointing out issues for migration, and every time I'm said I should "trade" in some of the stuff, doing it myself?
<cjwatson> If I got a message like the above then it would go straight to the bottom of my list
<doko> this started on -desktop
<Laney> doko: the team is subscribed now
<doko> Laney, https://bugs.launchpad.net/ubuntu/+source/aspell-he/+bug/1545803 , did stop doing other things, wrote the minimal MIR and promoted it
<ubottu> Launchpad bug 1545803 in aspell-he (Ubuntu) "[MIR] build dependency of hspell" [Undecided,Fix released]
<Laney> cool, thanks!
<flexiondotorg> Laney, the Debian pkg-mate team have taken over maintainership of libwnck
<flexiondotorg> The changes I dicsused with you a few weeks back are now all complete and in Debian unstable.
<flexiondotorg> https://packages.debian.org/source/sid/libwnck
<flexiondotorg> Laney, is this just a matter of 'requestsync' for Ubuntu?
<Laney> flexiondotorg: That's the way to request a sync, if we don't need any delta
<Laney> check the diff against our package to be sure
<flexiondotorg> Laney, Thanks.
<flexiondotorg> I think Ubuntu and Debian had diverged sometime ago.
<mapreri> doko: wow, thanks for making the whole openmpi migrate!
<tkamppeter> Any Debian packaging expert here? I need to give a binary package another version number than its source package has.
<mapreri> now I just need to make the debian release team firing the needed rebuilds in s390x for mpich â openmpi...
<cjwatson> dh_gencontrol -- -vBLAH
<cjwatson> but be careful :)
<tkamppeter> cjwatson, thanks, and how do I direct this only to selected binary packages?
<cjwatson> dh_gencontrol -pPKG -- ...
<tkamppeter> cjwatson, what do I write into the override_dh_gencontrol: rule in the debian/rules file if xxx should get the source's version number and the yyy package the alternative version number?
<cjwatson> tkamppeter: so this should always be in terms of a transformation rule, not a fixed alternative version number, otherwise rebuilds are unnecessarily painful
<cjwatson> tkamppeter: you probably want something like $(shell dpkg-parsechangelog -SVersion | sed ...) to compute the alternative version number
<cjwatson> and substitute that into the dh_gencontrol call
<tkamppeter> cjwatson, what I want to do is the following:
<tkamppeter> cjwatson, the cups-filters package is currently version 1.8.2-1 and all its binary packages which it already had before should have the same version number.
<tkamppeter> cjwatson, I am adding two new binary packages to cups-filters, names cups-filters-lsb and cups-filters-invalid-mta which should make LSB-based printer driver packages keep installable on Ubuntu as Debian has dropped the packages lsb and lsb-invalid-mta.
<flexiondotorg> Laney, comparing the packages there are several keys differences.
<flexiondotorg> Laney, Ubuntu has two patches that are not in the Debian packages.
<tkamppeter> cjwatson, the package cups-filters-lsb should provide lsb and replace the former lsb package, the cups-filters-invalid-mta should replace the lsb-invalid-mta package (providing it).
<flexiondotorg> And the Debian package has has quite a restructure during the update.
<flexiondotorg> How to proceed?
<juliank> tkamppeter: I don't see why you would want different version numbers yet
<cjwatson> tkamppeter: this is sounding like you want versioned provides, not different version numbers
<tkamppeter> cjwatson, problem is that the lsb source package is already at version 4.1.... and cups-filters is version 1.8.2.
<cjwatson> the actual version of the cups-filters-lsb package etc. doesn't matter here
<juliank> Unversioned provides do not match any version comparison
<juliank> So you need provides: lsb (= 4.1)
<juliank> basically
<cjwatson> yeah
<Laney> flexiondotorg: Merge if the patches are still needed
<doko> mapreri, I had some sourceful uploads for these openmpi changes. If you could forward these changes to debian, I would appreciate it. the openmpi transition tracker should have these
<Laney> flexiondotorg: Or get them applied in Debian. :)
<tkamppeter> cjwatson, I simply want to replace the dropped lsb and lsb-invalid-mta packages.
<cjwatson> tkamppeter: version number's still irrelevant
<cjwatson> tkamppeter: if you were actually emitting binary packages called "lsb" and "lsb-invalid-mta", then it would matter
<flexiondotorg> Laney, OK, I can investigate getting them merged in Debian.
<flexiondotorg> But, clearly the packages have diverged anyway.
<flexiondotorg> How exactly does the merging work in this case?
<juliank> tkamppeter: If you don't actually need to satisfy versioned depends, unversioned provides would be OK as well. Then do provides/replaces and possibly breaks
<cjwatson> tkamppeter: but you're saying that's not what you plan to do, you plan to use Provides, so your binary versions don't matter and you can just leave them at the default.  (Are you sure you need Replaces?)
<juliank> breaks being the part to remove old lsb packages
<tkamppeter> cjwatson, LSB-based printer drier packages depend on "lsb" and I am no sure whther there are some which have a versioned dependency like "lsb (>=3.1)".
<Laney> flexiondotorg: A merge is just "take the Debian package and apply this diff on top of it"
<Laney> flexiondotorg: your task is to work out how to preserve the changes on top of the new package structure
<cjwatson> tkamppeter: right, but even so, overriding the version number of cups-filters-lsb will complicate your life and achieve nothing, so don't :-)
<flexiondotorg> Laney, but that would destroy the ubuntu changelog?
<doko> barry, jtaylor, tumbleweed: python3.4 noew removed
<Laney> flexiondotorg: merge-changelog(1) :)
<Laney> (ubuntu-dev-tools)
<flexiondotorg> Laney, thanks.
<barry> doko: gone, gone? :)  even minimal?  \o/
<tumbleweed> doko: \o/
<juliank> tkamppeter: You are probably looking for Provides: lsb (= 4.X+reallycups), Replaces: lsb, Breaks: lsb (<< 4.X+reallycups)
<cjwatson> tkamppeter: unless you plan to call your binary packages literally "lsb" and "lsb-invalid-mta" (which you probably don't need to given that versioned provides exist), then you likely just need versioned provides as juliank says
<flexiondotorg> Laney, I'll try and get started here but I may need some guidance.
<juliank> Replaces & Breaks if you want to replace the old packages
<juliank> and have them removed
<Laney> flexiondotorg: If this is just a matter of keeping some patches then it is easy - merge-changelog, quilt import, write new changelog, done
<flexiondotorg> Laney, maybe easy for someone who has done this before :-)
<Laney> Working out the logical delta is the hard part :)
<tkamppeter> cjwatson, so with a versioned provides I can stisfy the "Depends: lsb (>= 4.0)" in the driver package?
<flexiondotorg> Logical delta?
<juliank> tkamppeter: That's the entire point of versioned provides.
<Laney> Previous changes and what needs to be kept
<flexiondotorg> Well, the source is unchanged.
<cjwatson> tkamppeter: yeah, you can have Package: cups-filters-lsb Version: 1.8.2-2 Provides: lsb (= 4.whatever)
<flexiondotorg> It is the packaging that has changed/diverged.
<juliank> tkamppeter: Without versioned provides, you could not satisfy any versioned dependency on lsb unless your package was literally called "lsb".
<flexiondotorg> And the patches are easily retained.
<Laney> Yeah
<Laney> So you need to work out if the packaging did anything before that it doesn't do now that we need to keep
<Laney> or the converse. :)
<tkamppeter> juliank, what does the "+reallycups" in your example mean?
<Laney> I would guess probably not
<juliank> tkamppeter: Just to differentiate your version from the last lsb package version, if you like to :)
<flexiondotorg> Laney, The Debian packaging can just be used.
<Laney> Luckily I am patch piloting tomrorrow so can look at your diff
<juliank> Could be useful for breaks
<flexiondotorg> Retain 2 ubuntu pactches and merge-changelog.
<flexiondotorg> Laney, no time pressure then ;-)
<Laney> That's likely
<Laney> Better if you could drop even that and sync. :P
<Laney> but I have NFI about those patches
<flexiondotorg> NFI/
<doko> barry, can you upload a python-pip with the added breaks/replaces?
<mapreri> doko: for sure I do try to integrate everything when uploading team maintained stuff and syncing later.  I'm going to try having a better look at all packages the following days.
<Laney> no fine idea
 * flexiondotorg nods
<mapreri> I'm also happy to NMU, so ^^
<doko> barry: (<< 22.1)
<doko> barry: oops, (<< 20.1)
<tkamppeter> cjwatson, juliank, thanks for the help. I will try it.
<barry> doko: sure, i can update it.  thanks
<barry> doko: are you going to upload a new setuptools soon?  if so, thanks, and please ignore my bug follow up
<doko> barry, yes, not building the -whl anymore
<doko> but you need the breaks/replaces
<barry> doko: yep, will upload momentarily.  will you close #814571 or do you want me to with python-pip?
<doko> barry, please do it with python-pip when you add the Breaks/Replaces
<barry> doko: ack
<flexiondotorg> Laney, with changelog version, should I just rev the -0ubuntux suffix and target xenial?
<Laney> flexiondotorg: it's <debianversion>ubuntu1
<flexiondotorg> Laney, The ubuntu package currently has epoch but debian doesn't.
<flexiondotorg> Retain epoch in Ubuntu?
<Laney> Yep
<flexiondotorg> OK
<Laney> Make sure any versions in debian/control (etc) hav eit
<flexiondotorg> The debian version is; 2.30.7-5 and the last ubuntu version is 1:2.30.7-0ubuntu5
<flexiondotorg> Laney, so should the new ubuntu version should be 1:2.30.7-5ubuntu1?
<Laney> Seems OK
<flexiondotorg> Thanks.
<Laney> Got to go now
<Laney> byeeee
<sil2100> Yaay, the libjsoncpp transition got unblocked \o/
<barry> doko: python-pip 8.0.2-7 uploaded
<doko> barry, setuptools was accepted
<doko> barry, what is the plan with libpies? just drop the python2.7 loader?
<barry> doko: i have a patch in debian bts that splits the py2 and py3 loaders into separate binary packages.  the idea was to then adjust dependents to Depend on the correct one.  there are still a few py2 packages iirc.  but there's been zero activity on the debian bug so i think we should just move ahead in ubuntu
<doko> barry, how many rdeps are there?
<barry> doko: i forget.  let me find the bug comment
<barry> doko: https://bugs.launchpad.net/ubuntu/+source/libpeas/+bug/1440504/comments/6
<ubottu> Launchpad bug 1440504 in libpeas (Ubuntu) "libpeas-1.0-0 depends on both libpython2.7 and libpython3.4" [Medium,In progress]
<doko> barry, lets go ahead, so we can finish this before the feature freeze
<barry> doko: +1  it's on my plate for this week
<flexiondotorg> Can someone here give me a hand with updating an existing patch in a package.
<flexiondotorg> I can't figure how to use quilt to achieve this.
<flexiondotorg> First time I've had to do this so would appreciate the help :-)
<doko> tjaalton, llvm now defaults to 3.8 in xenial
<tjaalton> doko: yes, and mesa switched to it last week :)
<doko> now lets see how many version can be demoted ...
<mapreri> can you retry this?  with the mpi-defaults change it works https://launchpad.net/ubuntu/+source/ruby-mpi/0.3.0-1build4/+build/8923547
<ginggs> retrying
<mapreri> ta
<doko> cjwatson, your recent python-cryptography sync ftbfs. looks like a missing b-d. the devscripts ftbfs as well. can you have look at these, or should I?
<doko> cyphermox, mterry: feedback on lp: #1545854 appreciated
<ubottu> Launchpad bug 1545854 in libnftnl (Ubuntu) "[MIR] build dependency of iptables" [Undecided,New] https://launchpad.net/bugs/1545854
<cyphermox> doko: that's something I wish was in collab-maint or something ;)
<robert_ancell_> beuno, https://bugs.launchpad.net/rnr-server/+bug/1540635
<ubottu> Launchpad bug 1540635 in Ratings and Reviews server " The 2 hour limit for review editing should be removed (for .deb apps)" [Undecided,Won't fix]
<Saviq> pitti, if you're still here, any idea about the "In progress" run here http://people.canonical.com/~ubuntu-archive/proposed-migration/xenial/update_excuses.html#unity-api ? it looks stuck - the i386 run completed 2h ago and there's nothing in http://autopkgtest.ubuntu.com/running.shtml
<Saviq> slangasek, maybe you could have a look please â?
<Saviq> infinity, maybe you have an idea â about the stuck autopkgtest?
<robert_ancell> Chipaca, https://bugzilla.gnome.org/show_bug.cgi?id=727563
<ubottu> Gnome bug 727563 in HTTP Transport "no way to use Unix Domain Sockets (AF_UNIX or AF_LOCAL)" [Normal,New]
<Saviq> robert_ancell, hey, I saw you guys reverted nautilus a few days ago, do you know why the icon layout would get screwed a bit? my icons are some 25% smaller by default (Ctrl+0) now, and if I Ctrl+=, the spacing between the bigger ones is just huge
<robert_ancell> Saviq, sorry, I didn't work on that, not sure
<Saviq> robert_ancell, nw, will talk to seb tomorrow
<Saviq> have a good day :)
<robert_ancell> Saviq, will do!
<cjwatson> doko: I'll look at them
<cjwatson> doko: python-cryptography was blocking six
<cjwatson> (due to autopkgtests)
<cjwatson> doko: python-cryptography looks more like python3-pytest being broken, but I thought that was already fixed ...
<cjwatson> hmm
<cjwatson> doko: OK, python-cryptography is https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=814622, not my problem :-)
<ubottu> Debian bug 814622 in python3-pytest "python3-pytest: modifies shipped files: /usr/bin/py.test-3.[45]" [Serious,Fixed]
<cjwatson> (see end of bug log)
<cjwatson> should be fine once that finally gets fixed one way or another
<Saviq> cjwatson, do you have power over autopkgtests? could you help with un-stucking the In progress run here http://people.canonical.com/~ubuntu-archive/proposed-migration/xenial/update_excuses.html#unity-api ? it's been like that for a good 4h now
<cjwatson> Saviq: if I can remember how
<cjwatson> IRC logs to the rescue
<Saviq> cjwatson, maybe https://wiki.ubuntu.com/ProposedMigration/AutopkgtestInfrastructure#Administration will help
<cjwatson> Saviq: yeah, I found it; should unstick in a bit
<Saviq> thanks
#ubuntu-devel 2016-02-16
<robert_ancell> ogasawara, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1498667
<ubottu> Launchpad bug 1498667 in linux (Ubuntu) "[Toshiba P50W-B00F] Touchscreen no longer working" [Low,Confirmed]
<pitti> Good morning
<doko> pitti, promoting the python-systemd source (binaries were already in main), subscribed foundations-bugs
<pitti> doko: ah, thanks; it got split out of the systemd source some time ago
<pitti> doko: I subscribe myself as well
<pitti> doko: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#python-setuptools â python-setuptools-whl still has rdepends, will that now built by another source or will virtualenv and python-pip stop using it?
<pitti> doko: i. e. I wonder whether to NBS-remove it from -proposed to unstick it
<doko> pitti, python-pip builds it on its own now
<pitti> doko: oh! then I guess it's because the current version from -setuptools is higher (20.0-2) than the one now built from -pip (8.0.2-7)
<doko> however virtualenv breaks tox tests and doesn't migrate
<pitti> ah no, setuptools-whl vs. pip-whl
<pitti> so virtualenv needs to drop its python-setuptools-whl dep
<pitti> doko: tox is something for barry, I suppose
<doko> yes
<pitti> doko: I'll look at the apport failure with gdb, apparently it slightly changed behaviour
<doko> ta, just wanted to have the new upstream there before FF
<pitti> apparently a null pointer does not show "Cannot access memory at address 0x0" any more
<doko> http://people.canonical.com/~ubuntu-archive/component-mismatches.svg  looks interesting ...
<doko> so what should we do with php? including the 7.0 transition?
<pitti> doko: server team started too look at it, but no followup to https://lists.ubuntu.com/archives/ubuntu-devel/2016-January/039117.html yet
<cyphermox> good morning pitti, doko :)
<pitti> salut cyphermox, comment Ã§a va ?
<cyphermox> ca va bien
<cyphermox> il est tres tard :)
<cyphermox> (or very early, depends on the viewpoint :)
<highvoltage> late night ubiquity hacking eh? :)
<cyphermox> ja
<cyphermox> I was in the zone.
<highvoltage> ^_^
<cyphermox> except now too many ideas for refactoring that I can't do
<dholbach> good morning
<doko> cyphermox, working in parallel n libnftl?
<doko> hmm, big endian targets fail
<cyphermox> ugh
<cyphermox> doko: want to fix the tests?
<cyphermox> doko: or I'd disable them again and file a bug in debian :/
<doko> cyphermox, who touched the package last? ;) no, just ignore the results on these targets then, if we can't fix it
<cyphermox> ah, that too
<cyphermox> it's not that we couldn't fix it, but that it would take time and I've been awake for too many hours
<mardy> seb128: hi! I need some ubuntu/kde dev to look at bug 1451728, do you have some names handy?
<ubottu> bug 1451728 in ktp-accounts-kcm (Ubuntu Wily) "[master] kde-config-telepathy-accounts package install error" [Critical,Triaged] https://launchpad.net/bugs/1451728
<seb128> mardy, hey, not really, maybe Laney or dholbach can help though
<Laney> #kubuntu-devel ?
<dholbach> yofel, ^ can you suggest somebody?
<seb128> Laney, dholbach, thanks
 * Laney would just go ask in there
<mardy> Laney: good idea
<dholbach> ^ debfx, Quintasan should maybe able to help with that as well - they're in ~kubuntu-dev
<Quintasan> hm
<flexiondotorg> Laney, morning.
<Laney> hello
<flexiondotorg> Laney, I've merged the changes we were discussing.
<flexiondotorg> Laney, But have one issue.
<flexiondotorg> Laney, an existing patch, in both the Debian and Ubuntu packages, is slightly modified in the updated Debian packaging.
<flexiondotorg> I've read how to use quilt to update an existing patch, but I can't get the patch to update.
<flexiondotorg> Laney, some help with that?
<Laney> Can't we use the new version from Debian?
<caribou> rbasak: just uploaded clamav with the (unsigned long) cast added & kept the armhf exception as it doesn't build on armhf w/o it
<rbasak> caribou: OK. Thank you!
<caribou> rbasak: trying to upload the git repo now
<flexiondotorg> Laney, that is what I want to do.
<Laney> Then there's no need to quilt update anything
<Laney> or am I missing something?
<flexiondotorg> But when I just copy the revised patch from Debian building the package says the a new changes.
<flexiondotorg> *there are new changes.
<Laney> did you add it to debian/patches/series?
<Laney> or use quilt import to copy it in
<flexiondotorg> Laney, The patch (by name) already exists in the existing Ubuntu and new Debian packaging. The new Debian package has a revised version of the patch.
<flexiondotorg> I could not get quilt to import it.
<flexiondotorg> I am not sure exactly how to use quilt to import.
<flexiondotorg> I read about using quilt to update an existing patch but it didn't work.
<Laney> Start from the Debian package and import the *Ubuntu* ones from our old package
<Laney> You don't need to touch this new one
<flexiondotorg> Ahhh.
<flexiondotorg> So, I was going the other way. Taking the existing Ubuntu and adding the new bits form Debian.
<flexiondotorg> Right. I'll try what you suggested. Thanks.
<Laney> https://paste.debian.net/391176/
<Laney> flexiondotorg: I would do something like that
<Laney> then at the end you look at the debdiff to see if it is just the things we need to keep from the old package
<Laney> (the version change and the patches?)
<caribou> rbasak: do you think that I got the proper rights to upload to lpusdp: Y
<caribou> ?
<Laney> the epoch thing messes up merge-changelog - that's annoying
<Laney> Maybe don't merge-changelog then
<rbasak> caribou: you should do I think.
<caribou> rbasak: I'll try
<rbasak> caribou: you're a member of ~ubuntu-server-dev by virtue of being a core dev.
<rbasak> cpaelzer: I noticed in your vblade merge that you renamed the Vcs field. This leads me to think - we can also put in our own Vcs field now, poitning to https://git.launchpad.net/~ubuntu-server-dev/ubuntu/+source/vblade?h=ubuntu%2Fdevel for example now, since that's where we're maintaining it.
<rbasak> cpaelzer: I don't think we need to bother until we have some tooling though.
<rbasak> cpaelzer: perhaps we should have something to wrap update-maintainer and also both sets of Vcs-* changes and put that into ubuntu-git-tools?
<cpaelzer> rbasak: I can surely add our VCS field
<cpaelzer> do you want me to do that and resubmit, or just for the next upload?
<rbasak> cpaelzer: next upload is fine.
<rbasak> Not worth redoing
<rbasak> cpaelzer: I'm also fine with delaying until we have tooling. No need to spend extra effort until then IMHO.
<mardy> Laney: sorry to bother you again :-) I've filed bug 1546020 and attached a patch, but AFAIU the package is maintained in debian; how should I proceed?
<ubottu> bug 1546020 in telepathy-mission-control-5 (Ubuntu) "Relax apparmor confinement for KDE account files" [Undecided,New] https://launchpad.net/bugs/1546020
<caribou> rbasak: https://git.launchpad.net/~ubuntu-server-dev/ubuntu/+source/clamav
<caribou> works fine !
<Laney> mardy: You could send the patch to the Debian BTS https://www.debian.org/Bugs/Reporting
<seb128> Laney, mardy, Debian doesn't ship that apparmor profile so it doesn't make sense to forward the patch
<seb128> we could try to get them to include the profile though
<Laney> ok I didn't check
<seb128> urg sorry
<seb128> they do
<Laney> what
<seb128> I looked at the wrong dir
<seb128> http://anonscm.debian.org/cgit/pkg-telepathy/telepathy-mission-control-5.git/tree/debian/apparmor-profile
<Laney> haha
<seb128> bigon added it in decembre
<rbasak> caribou: thanks!
<rbasak> caribou: a couple of notes for next time
<rbasak> caribou: I'm trying to keep the imports clean parent-wise. So "Import version 0.99+dfsg-1" shouldn't have "Import version 0.98.7+dfsg-0ubuntu5" as its parent, since it doesn't have any connection to that.
<rbasak> Instead it should be an orphan commit in this case, or have a parent of the previous Debian import next time.
<rbasak> caribou: with that, I'm trying to keep the "debian/sid" branch pointer pointing to the latest Debian import.
<caribou> rbasak: ok, noted
<caribou> rbasak: another question about your workflow :
<caribou> rbasak: what I just pushed in the ubuntu/devel branch only has one tag; all the working tags are in my lpmep: personal branch
<caribou> how is the next person doing the merge going to get the working environment ?
<mardy> Laney, seb128: so the correct thing to do is to open a bug in the debian BTS?
<rbasak> caribou: please see https://git.launchpad.net/~ubuntu-server-dev/ubuntu/+source/logwatch as an example of what I intend.
<caribou> rbasak: k
<rbasak> caribou: when a new logwatch arrives in sid, either a sponsor or a future automatic importer will dsc-commit the new Debian upload to the debian/sid branch and tag it.
<Laney> mardy: if you want to forward something there then yes
<Laney> mardy: could also be uploaded in ubuntu of course if necessary
<caribou> rbasak: ok, I see
<caribou> rbasak: In my case, I could push a new debian/sid branch that points to the new/debian tag of my git-dsc-commit import ?
<rbasak> caribou: you'd check out the debian/sid branch, git-dsc-commit the new Debian upload, tag it import/<version> instead of just <version> (the tooling needs a bit of tweaking here) then push the branch back with the tag.
<rbasak> caribou: then you'd check out the ubuntu/devel branch, branch that as local "logical" branch or something, and rebase to squash to come up with the logical tag.
<rbasak> caribou: the logical/<version> tag that is.
<rbasak> caribou: you'd be able to push or otherwise share the logical/<version> tag (without pushing the local logical branch) at this stage.
<rbasak> caribou: then you'd branch the logical/<version> tag as a local "merge" branch, and rebase --onto debian/sid.
<rbasak> caribou: then you have the same MP capability as current.
<rbasak> A complication is that others might upload without pushing to ubuntu/devel, so we'd need to dsc-commit to catch that up too if necessary.
<caribou> ok, I'll guess it'll become clearer the next time
<caribou> rbasak: that will happen with SRU since debdiffs are used most of the time
<rbasak> Yeah
<rbasak> Eventually LP will deprecate dput and require a git push instead. Then that'll go away :)
<caribou> Laney: thanks for the backport !
<flexiondotorg> Laney, could you cast an eye over this diff please? - http://paste.ubuntu.com/15090421/
<flexiondotorg> Laney, I haven't used merge-changelog in this diff.
<flexiondotorg> If is looks good to you, is I bug with this debdiff attached the correct way to proceed?
<Laney> flexiondotorg: Fix the versions in the .symbols file to have the epoch
<flexiondotorg> Wilco
<Laney> Say which changes you kept in the changelog (Merge with Debian. Remaining Ubuntu changes - a - b - c)
<Laney> and please give the diff on top of Debian too
<flexiondotorg> OK
<flexiondotorg> I've found another version requiring epoch in debian/control too.
<flexiondotorg> Laney, This the the merge from Debian diff - http://paste.ubuntu.com/15090488/
<Laney> flexiondotorg: lies
<Laney> that's a diff from the old ubuntu version
<Laney> s/old/current/
<flexiondotorg> Ag.
<flexiondotorg> Sec...
<flexiondotorg> Laney, Bad explanation from me.
<flexiondotorg> This is the intended merge - http://paste.ubuntu.com/15090488/
<flexiondotorg> This is the comparison with current Debian - http://paste.ubuntu.com/15090498/
<Laney> flexiondotorg: cool, looks plausible right now
<Laney> toss them on a sponsnoring bug?
<flexiondotorg> Both diff in the bug?
<Laney> ye
 * flexiondotorg is doing it...
<flexiondotorg> Laney, https://bugs.launchpad.net/ubuntu/+source/libwnck/+bug/1546066
<ubottu> Launchpad bug 1546066 in libwnck (Ubuntu) "Request merge with Debian for libwnck" [Undecided,New]
<Laney> ty
<Laney> I am supposed to sponsor later (although I've got to leave early), will try to look
<flexiondotorg> Laney, many thanks for your help and tutoring.
<flexiondotorg> I really appreciate it.
<Laney> flexiondotorg: no worries
<inaddy> slangasek: you mentioned that instead of merging/sync mstflint for trusty we should create a mstflint4 package (probably universe). what is the best procedure for this ? to follow the request for inclusion (as described in [MIR] procedure) ? creating a PPA with full source + bzr branch ?
<inaddy> (LP: #1470167) btw. i was working on SRU instead of a request for inclusion (probably the needed step now)
<ubottu> Launchpad bug 1470167 in mstflint (Ubuntu Wily) "mstflint doesn't support Mellanox ConnectX-4 HCAs" [Low,In progress] https://launchpad.net/bugs/1470167
<inaddy> hum. slangasek is away, if anyone else can help ^
<inaddy> caribou: ^
<rbasak> inaddy: an uploader will be able to upload any source package. I suggest you follow normal SRU procedure and link to a source package upload from the bug somehow. A PPA would be fine.
<rbasak> (and detail the exception in the bug)
<inaddy> rbasak: cool. will do. tks
<rbasak> kickinz1: the merge target is meant to be ubuntu/devel, not debian/sid. Then when the uploader uploads and pushes to ubuntu/devel, the MP conveniently notices.
<kickinz1> rbasak, sorry.
<kickinz1> rbasak, You want me to redo the MP?
<rbasak> No, it's fine.
<rbasak> kickinz1: also, I expect you to have a tag called logical/1_2.10.1-1ubuntu1
<rbasak> kickinz1: is this what you called logical/ubuntu-2.10.1-1?
<kickinz1> rbasak, yes.
<rbasak> OK
<coreycb> bdmurray, I commented on bug 1318721
<ubottu> bug 1318721 in neutron (Ubuntu Trusty) "RPC timeout in all neutron agents" [High,Fix committed] https://launchpad.net/bugs/1318721
<mdeslaur> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Wily (15.10) 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-wily | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: mdeslaur
<pitti> cd
<didrocks> ~
<pitti> didrocks: ~, sweet ~!
 * didrocks hugs pitti
 * pitti hugs didrocks back
<Odd_Bloke> xnox: We just saw "sosreport : Depends: python3.4:any but it is not installable" in a livefs build for s390x cloud images (but other arches seem to be happy); any ideas?
<xnox> Odd_Bloke, it's weird as nothing should depend on python3.4 anymore.
<xnox> Odd_Bloke, yet it clearly is.
<xnox> Odd_Bloke, let me analyze the scope here.
<jdstrand> pitti: re apparmor merge-- sure, we'll figure it out. not sure if I personally will do it, but we can get someone on it
<xnox> Odd_Bloke, we have a few http://paste.ubuntu.com/15091848/
<xnox> doko, pre-mature removal of python3.4 ^
<xnox> actually less.
<xnox> doko, Odd_Bloke: uploaded 7 packages, which should resolve python3.4, or lack of, for good.
<Odd_Bloke> xnox: Thanks. :)
<caribou> Does someone have a few spare cycles to review the mstflint -> mstflint4 package creation for me ? Rather simple leaf package
<caribou> http://paste.ubuntu.com/15092039/
<rharper> rbasak: hoping to wrap up the strongswan stuff today but I've a general question;  as we've been testing the proposed package we've identified a number of fixes and some features that are helpful;  should I leave those to the side of the merge and apply them after the merge or is it OK to bring in the additional bug fixes and ubuntu changes in the merge itself (as part of the new ubuntu delta) ?
<doko> xnox, ta, reverse-depends didn't show any ...
<xnox> doko, yeah, weird. Usually things like that are picked up by the transition tracker, but that too has false positives/negatives.
<xnox> doko, anyway, i've dputed the remaining 7 packages, and will rerun the chdist test ones they migrate, across all 7 arches, to check that we are all good.
<doko> the only one I saw was sigil, but a recommends only
<xnox> at first i have suspected an arch-skew (given that s390x was a bootstrapped one)
<rbasak> rharper: up to you. It's fine to add them to the merge upload if you wish. Or do it later if you think it's unnecessarily blocking the merge. We probably shouldn't regress anything big that is known in the merge upload though.
<rharper> rbasak: ok; I don't think anything is blocking; they've all been easy fixes or updates.
<rbasak> rharper: OK that's fine - just add extra commits and extra top level bullet points in d/changelog for each change.
<ginggs> doko, xnox: one i happened to see on that list is mine, python-ase, FTBFS with new numpy
<rbasak> (d/changelog probably via git-reconstruct-changelog)
<xnox> ginggs, oh.
<xnox> ginggs, well.
 * rbasak wonders if that should be renamed to git-construct-changelog as it's not really redoing anything
<xnox> ginggs, if it's uninstallable and FTBFS we will need to demote it to -proposed, such that it is not uninstallable in release.
<ginggs> xnox: remove it if you must, i'll upload it when it is fixed (waiting for response from upstream)
<xnox> until fixesd.
<ginggs> xnox: ack
<xnox> ginggs, demote to proposed is the new "remove from release"
<xnox> doko, do you have powers to demote-to-proposed python-ase?
<xnox> there is a script to do that in archive-tools repository i think.
<rharper> rbasak: thanks
<mdeslaur> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Wily (15.10) 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-wily | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<doko> xnox, gpaw still depends on it
<xnox> doko, it's python2 only?
<doko> xnox, both demoted
<xnox> doko, i don't see gpaw using python3 at all. So if it's demoted it will probably just migrate back. https://launchpadlibrarian.net/236788889/buildlog_ubuntu-xenial-amd64.gpaw_0.11.0.13004-3build2_BUILDING.txt.gz
<xnox> it build-depends on python3 but i don't see it building python3 anything.
<damascene> hi, this packagefonts-hosny-amiri have been updated but I find the old version in 16.04 https://github.com/khaledhosny/amiri-font/releases
<damascene> fonts-hosny-amiri how to get it in 16.04 before feature freeze?
<rharper> question on FFEs since it's that time and I've never filed one;  if there is an existing merge bug, would I just add the justification to the existing merge bug or file a new bug just for the FFE and reference the merge bug ?
<ginggs> rharper: just change the bug title
<rharper> ginggs: ok
<ginggs> rharper: and edit the bug description to include the justification
<rharper> gotcha; no need for a new bug, update title and include the justification .  Thanks!
<seb128> pitti, can you override the libreoffice-l10n autopkg as well? it seems to still be grumpy about libreoffice which blocks libreoffice itself because they need to go together
<Laney> vila: flexiondotorg: I didn't make it to sponsoring today, sorry - will start with that tomorrow so I don't get on to anything else
 * Laney waves
<vila> Laney: looks like mdeslaur did ! Thanks to both !
<smoser> pitti, around ?
<pitti> seb128: hm, I actually did, but britney doesn't get along with hints with multiple versions apparently; I'll apply a +1 force then :)
<pitti> smoser: Im' back
<smoser> pitti, so the open-iscsi... you thought our delta had all been taken into debian ?
<seb128> pitti, thanks
<pitti> smoser: yes, except the autopkgtest
<smoser> such that we should re-sync with much smaller delta
<smoser> but sync woudl still be necessary, right ? for the auto pkg test
<smoser> annoying that we have to carry package delta for that, but seemingly fairly easiliy synced if that is in fact it
<pitti> smoser: right, "re-merge"
<smoser> ok. i will look to see if i can't get that merged.
<Odd_Bloke> Are there any plans to replace bzr packaging branches (i.e. UDD) with git equivalents?
<cjwatson> Odd_Bloke: https://lists.ubuntu.com/archives/ubuntu-devel/2015-November/039010.html   but not much in the way of updates since then unfortunately
<pitti> Odd_Bloke: note that it's fairly easy to create your own (or better yet, branch from Debian's) for packages you work on often
<pitti> Odd_Bloke: I find that the vast majority of packages I happen to look at in Debian already have a git, and that will always be better than some synthetically imported one
<Odd_Bloke> cjwatson: Aha, cool, I thought I had seen something about it.  Any sense of when it might end up happening, or is it a someday thing for now?
<pitti> it's most convenient to have an ubuntu git branch in the Debian git repo, or at least mirror it in LP
<cjwatson> Odd_Bloke: I really hope to manage it this year but realistically can't promise anything definite
<pitti> but if not, "gbp import-dsc foo.dsc" et voilÃ  :)
<rbasak> Odd_Bloke: the server team is doing it now. We'll have an interim importer for packages we follow soon.
<rbasak> (not using gbp import-dsc as not doing an upstream/debian split)
<Odd_Bloke> cjwatson: Ack; we just didn't want to spend time working on something that would be easier with it if it were right around the corner. :)
<rbasak> Odd_Bloke: once we have the importer, perhaps we can track your packages for you too.
<pitti> Odd_Bloke: so the thing you want to work on has no VCS in debian?
<Odd_Bloke> pitti: The thing we want is livecd-rootfs. :)
<pitti> asrcs-Bzr: http://bazaar.launchpad.net/~ubuntu-core-dev/livecd-rootfs/trunk
<pitti> eek, s/ssrc/V/
<pitti> Odd_Bloke: perhaps it's  time to convert that to git and use that from now on?
<Odd_Bloke> We have been using that.
<pitti> then you have all the history, and not just the coarse-grained one from auto-imports
<Odd_Bloke> But ran in to problems for two reasons: (a) a refactor happened over multiple commits (without a release, so not an actual problem) and we started a build in the middle, breaking our images.
<pitti> I don't want to diminish cjwatson's work, but I've never found such synthetic VCSes particularly useful
<Odd_Bloke> (b) once xenial is released, we will want to track xenial's livecd-rootfs for xenial.
<pitti> Odd_Bloke: right, so for (b) you'd branch off /xenial (instad of /trunk) at some appropriate point, and for (a) you'd use a branch as well
<Odd_Bloke> (The use-case here is building a private livecd-rootfs package which contains private bits for partner clouds; we want to build on top of whatever the latest _released_ version of livecd-rootfs package is in a specific suite)
<pitti> (in both bzr and git)
<cjwatson> pitti: dgit actually looks like it could be a much better compromise there than UDD ever was
<Odd_Bloke> pitti: But /xenial branches weren't created a la cjwatson's email above (right?).
<cjwatson> pitti: because it's easier to stitch in history from different places, and we don't have the file-id problem
<pitti> Odd_Bloke: the above Vcs-Bzr: is a manually maintained "real" branch, it's got nothing to do with UDD or the above Launchpad work
<cjwatson> I tend to agree we should just convert livecd-rootfs to git and be done
<pitti> cjwatson: yeah, true
<pitti> I guess it'd be polite to ask ogra_ if he's okay with git migration
<pitti> as he's working on it a lot, and it's also his birthday :)
<pitti> (so don't make him grumpy today)
<ogra_> eek, git ?!?
<Odd_Bloke> pitti: Ack, but if I s/trunk/wily/ that URL, there isn't anything there.
<pitti> but it's hard to avoid git these days :)
<rbasak> pitti: synthetic VCS is better than no VCS, which is the situation with many Ubuntu-deltified packages right now.
<ogra_> pitti, up to now i managed to :)
<pitti> Odd_Bloke: right, as long as nobody makes those branches they won't :) but easy enough to create it once you need it, by branching off the tag corresponding to the wily version
<pitti> ogra_: wow, congrats
<rbasak> That's why an importer is useful. As long as Ubuntu uploaders aren't required to commit to VCS, we need an importer if we want to use VCS tooling to help us with our work.
<Odd_Bloke> Yeah, this ^
<pitti> rbasak: right, but branching off Debian's VCS is still better IMHO :)
<pitti> right for the "catch up with dput"
<rbasak> pitti: unfortunately that's really tricky to do reliably, _and_ have a single workflow across all the packages we look after.
<ogra_> pitti, i dont really want to be the blocker though ...
<pitti> well, I just wanted to mention gbp import-dsc, which might speed things up until this lands in LP
<cjwatson> rbasak: you could probably use bits of dgit as the importer
<pitti> or that ^
<rbasak> How do we match up the Debian VCS commit with a Debian upload, for example. What if a Debian NMU means that the VCS is missing an upload?
<rbasak> Etc.
<rbasak> nacc: ^
<cjwatson> since its raison d'Ãªtre is doing repeatable imports
<pitti> ogra_: I'm truly amazed that you managed to stay away from git until now :)
<rbasak> Currently we're using https://github.com/basak/ubuntu-git-tools/blob/master/git-dsc-commit, which just blats a .dsc as a commit.
<cjwatson> rbasak: the point of dgit for that is that it doesn't matter, it'll construct an appropriate commit on the fly
<ogra_> pitti, well, beyond git clone indeed ... the majority of stuff i work on is still using bzr ... and upstreams i work with are often enough fine with patches :)
<cjwatson> in a deterministic way so that if different people do it they get the same answer
<rbasak> That sounds neat.
<nacc> dgit does look handy
<smoser> Trevinho, just curious... bug 1521302 is terribly annoying to me.  do you think this is something fixed sometime soon ?
<ubottu> bug 1521302 in unity (Ubuntu) "gnome-terminal maximize than un-maximize behaves odd" [Medium,Confirmed] https://launchpad.net/bugs/1521302
<Trevinho> smoser: yes, but it's something we can delay for now...
<Trevinho> willcooke: can you please add that to our list ^
<smoser> is there some work around ?
<Trevinho> smoser: not that I know, maybe you can force with soemthing like wnckprop or other scripts, but... Nothing inside compiz AFAIK
<willcooke> hrm, odd.  Doesn't do it it 14.04, does in 16.04
<willcooke> I'll add it to the backlog now
<smoser> thanks.
<Odd_Bloke> rbasak: What time frame are you looking at for your importer work?
<rbasak> nacc: ^
<nacc> Odd_Bloke: i'll hopefully get it done/working next week
<Odd_Bloke> OK, nice.
<pitti> stgraber, kees, infinity, mdeslaur: TB meeting now? (or not?)
<mdeslaur> pitti: thanks
<stgraber> cyphermox: hey, how am I supposed to talk to for NM nowadays?
<stgraber> just installed a clean Xenial box and opened the connection editor, I see lxcbr0 in there...
<stgraber> I thought we made it so that NM would stop messing with this...
<stgraber> doesn't look like it actually generated any config in /etc/NetworkManager but it's one click away from breaking lxcbr0 and having confused users waste hours of my team's time again...
<stgraber> (did I mention I hate Network Manager)
<cyphermox> I suppose it's still me
<cyphermox> stgraber: NM will always show the devices in nmcli
<cyphermox> or in the connection editor device list for that matter
<cyphermox> that doesn't mean nm-applet will show anything
<smoser> infinity, around ?
<smoser> we're seeing regressed behavior (tests started failing) https://platform-qa-jenkins.ubuntu.com/user/smoser/my-views/view/trusty%20amd64/job/ubuntu-trusty-server-amd64-smoke-minimal-virtual/
<smoser> that seem to match up time-wise with at least your debian-installer upload https://lists.ubuntu.com/archives/trusty-changes/2016-February/021231.html
<smoser> the point of that test is to install linux-virtual and then verifiy that the installed system is generally smaller (and that it has linux-virtual) installed.
<stgraber> cyphermox: and there's still no magic .d directory I can have lxc dump a file into to make sure our stuff never shows in NM is there?
<infinity> smoser: What log am I looking at?
<cyphermox> sure there is
<stgraber> cyphermox: last I checked there was something close to it, but any key set in there would fully overwrite the previous value
<cyphermox> stgraber: /etc/NetworkManager/conf.d
<stgraber> cyphermox: so if I was to ship one with the lxc and lxd package, the lxd one (alphabetical order) would override the key set by the lxc one, not append to it
<cyphermox> *shrugs(
<stgraber> right, that's the broken thing I looked at last time
<smoser> that test above (platform-qa-jenkins) . tries to seed installation of linux-virtual metapackage via:
<cyphermox> I don't think you can have NM never show the devices
<smoser>  d-i base-installer/kernel/override-image string linux-virtual
<cyphermox> it's doing what it's supposed to do, let you handle network devices. we already go out of our way to make sure people can't break lxc by clicking in nm-applet
<smoser> and then basically verifiesd that it got installed. it did not when that test ran with media
<smoser>  Ubuntu-Server 14.04.4 LTS Trusty Tahr - Beta amd64 (20160212)
<smoser> err.. ^ it passed
<cyphermox> stgraber: but it should still show devices, just like ifconfig should.
<smoser> failed with: Ubuntu-Server 14.04.4 LTS Trusty Tahr - Beta amd64 (20160212)
<cyphermox> stgraber: ie. if someone goes out of their way to do something stupid, too bad.
<stgraber> cyphermox: I seem to remember I tried using keyfile with unmanaged-devices and it kinda worked except that it couldn't be appended to, just overriden
<cyphermox> it's already unmanaged
<cyphermox> we patched that in
<stgraber> ok, kinda weird that unmanaged means that NM still lets you manage it though :)
<cyphermox> stgraber: unmanaged means NM won't touch it automatically
<stgraber> anyway, I guess we'll see how things turn out with 16.04, but I'm getting 2-3 reports of broken lxcbr0 a day due to NM and I'm getting sick of it
<cyphermox> stgraber: you can still poke things if you really wanted to
<stgraber> most of them get fixed by asking the user to "grep -r lxcbr0 /etc/NetworkManager" and remove any file that turns up
<infinity> smoser: Okay, but I'm not seeing a log that tells me what happened.
<cyphermox> I think we should take another look at the reports, and make sure it's not people doing something that should be pretty obvious one shouldn't do
<smoser> infinity, well, yeah, they're burried in the artifcats
<cyphermox> stgraber: that sounds a lot like someone going in to edit random things without knowing what they're for
<stgraber> there's also still a race somewhere in there where NM yanks the IPv4 address from our bridge at cration time. We fixed the most obvious one of those back in Wily (was hitting 90% of the time) but there still seems to be one (hits < 1%), still trying to get some kind of reproducer though...
<stgraber> cyphermox: my best guess so far si: connection editor -> edit lxcbr0 -> don't change anything -> save
<cyphermox> stgraber: I'm not against apply a patch to hide things if the patch makes sense and isn't going to break stuff, but people can already break things by editing random files
<stgraber> which isn't obviously wrong, they didn't change anything, they just went to look at it clicked save instead of close
<cyphermox> right
<cyphermox> I would suggest filing bugs upstream for some of these
<infinity> smoser: Right, can you tell me what bug you're reporting?  "I have a test that does a thing and my test fails" isn't a bug, unless you can tell me *why* your test is failing.
<stgraber> yeah, will look into that at some point after FF I guess, or just distro patch nm-connection-editor and the gnome control center components to hide unmanaged devices too (so they match nm-applet)
<smoser> infinity, well, we pre-seed installation of linux-virtual with:
<cyphermox> stgraber: well, that won't work
<smoser> infinity, well, we pre-seed installation of linux-virtual with:
<smoser>  d-i base-installer/kernel/override-image string linux-virtual
<stgraber> cyphermox: btw, any chance of getting 1.1 in xenial? I'd really like the 1.1 openvpn plugin, seems to fix a ton of stuff compared to our broken 0.9* version
<cyphermox> stgraber: connections are separate from devices
<stgraber> cyphermox: how was it done in the applet then?
<smoser> that used to result in installation of linux-virtual and then durint a stable release, that behavior changed.
<cyphermox> stgraber: per-device, not connections
<cyphermox> stgraber: I suppose what could be done is to explicitly hide connections that start in /lxc.*/
<smoser> i'm not 100% certain that the 'base-installer/kernel/override-image' actually did anything (rather than something realizing we're "virtual" and installing -virtual magically) , but even without that... we changed behavior in a stable release.
<xnox> cyphermox, couldn't udev rules, or some such set variables on the NIC to hint to network manager "don't touch this"?
<cyphermox> but even that is bound to fail at some point, people might actually want to create a connection named "lxc" for some other reason
<cyphermox> xnox: devices are already being unmanaged, that is already fine.
<cyphermox> xnox: I think there is a udev rule, but this isn't the problem
<xnox> cyphermox, that way, e.g. autocreated/managed things can do "NETWORK_MANAGER_HIDE_ME_HARDER=1" =)
<cyphermox> stgraber: I suppose we could probably already update the VPN plugins
<smoser> i dont really understand how the change i'm pointing to there could have caused this by looking at its diff, but something worked on the 20160212 and started failing on 20160215.
<cyphermox> stgraber: as for NM 1.1, it's always a huge thing to update... I'll look a bit see if that could go with a FFE
<cyphermox> morphis: did you look at updating NM yet?
<stgraber> cyphermox: I did try building the 1.1 openvpn plugin last night against current xenial and it wasn't very happy with our NM version. May be doable with more work though.
<cyphermox> err
<cyphermox> there isn't a 1.1
<cyphermox> 1.0.8?
<stgraber> Debian has NM 1.1.90-6 and nm-openvpn 1.1.90-3
<stgraber> I tried building the latter against Ubuntu's NM 1.0.4
<cyphermox> ok that might be 1.2-beta1 I suppose
<cyphermox> yup
<cyphermox> *sigh*
<stgraber> oh, why didn't they call it that? kinda confusing when looking at the version number :)
<cyphermox> yeah
<cyphermox> that was upstream's doing
<cyphermox> I think the minimum version is wrong, this should already build
 * cyphermox tries updating n-m-openvpn
<Odd_Bloke> nacc: rbasak: Would your importer give us a trusty tag/branch that would point at what's released in trusty?  (Or s/trusty/trusty-updates/g maybe)
<nacc> Odd_Bloke: initially it's only targetted at merges, but it'd be relatively easy to do that, i think
<Odd_Bloke> nacc: OK, cool.
<cyphermox> stgraber: ok, yeah, we'll need to update just about everything for it to work
<infinity> smoser: The difference between the working one and the failing one is that the failing one doesn't have archive.ubuntu.com available.
<smoser> where'd you see that infinity  ?
<xnox> doko, python3.4 rebuilds appear to have all migrated and/or you demoted borked things, so release is looking good now.
<doko> ta
<infinity> smoser: Search both syslogs for configure_apt and see the update there hits archive *and* the CD on the working one, and only the CD on the failing one.
<infinity> Now to sort out why that might be...
<smoser> hm.. so possibly related, i started seeing very bad network performance on a system we use for qa tests.
<smoser> where download of a 18M kernel package would take > 180 seconds
<infinity> smoser: Probably doesn't relate, but I can't see why this would break either.  We didn't change any of these bits.
 * infinity runs a test here.
<smoser> infinity, thanks. i'll leave you to poke at it
<rbasak> Odd_Bloke: yeah, our scheme will allow us to do that when the importer can support it. Not an initial goal, but I don't imagine it'll be particularly hard to get the importer to do that too when it's ready, since it'd use mostly the same code and logic.
<Odd_Bloke> rbasak: Ack.  Thanks for all the info!  (You too, nacc :)
<Emanuel> Hi
<Emanuel> There are only 2 days left https://wiki.ubuntu.com/XenialXerus/ReleaseSchedule until https://wiki.ubuntu.com/FeatureFreeze
<Emanuel> And no one step up to solve the lz4 situation.
<Emanuel> bug 1531923
<ubottu> bug 1531923 in lz4 (Ubuntu) "[MIR] lz4" [Undecided,Confirmed] https://launchpad.net/bugs/1531923
<rbasak> Emanuel: MIRs aren't dependent on FF. A new apt release might be though.
<xnox> tedg, you did read the docs prior to like hacking your own unique solution right?
<xnox> tedg, looks like https://wiki.ubuntu.com/citrain/LandingProcess#Dual-landing_and_handling_symbols documents how to do dual-landing symbols et.al.
<tedg> xnox: Eh, I just went with shlibs for everything. After I found the Debian docs for C++ and symbols that basically said "give up and use shlibs"
<Emanuel> rbasak: lz4 is in debian, how hard cant it be to import ?
<juliank> Emanuel: It's waiting for sarnold's security review
<tedg> After the abigail stuff is done for scopes-api I'll probably steal that as a in tree test.
<juliank> It's not only APT that is affected, squashfs-tools has not been updated since October
<rbasak> Emanuel: it is imported. It's just not in main.
<dasjoe> cking: cmiller tries to fix grub not finding a zpool's devices by adding some script to search for pools. I proposed to parse zdb's output, this may be of interest to you: https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1527727/comments/15
<ubottu> Launchpad bug 1527727 in grub2 (Ubuntu) "grub-probe for zfs assumes all devices prefix with /dev, ignoring /dev/disk/..." [Medium,In progress]
<juliank> It's hilarious that the inclusion of lz4 takes such a long time, given the modified copy/copies swirling around in main already (at least one in Linux)
<dasjoe> (zfs comes with lz4, too)
<juliank> mvo: It's feature freeze and the lz4 MIR request is still not through, meaning APT 1.2 continues to wait in proposed :(
<juliank> 1.2.3 now detects I/O errors in rred
<mvo> juliank: nice!
<mvo> juliank: I'm at a sprint right now, but I will poke some people about the lz4 MIR request
<Emanuel> https://github.com/fjserna/CVE-2015-7547/pull/1
<ubottu> ** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem.  When the candidate has been publicized, the details for this candidate will be provided. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-7547)
<Emanuel> https://github.com/fjserna/CVE-2015-7547/pull/1
<ubottu> ** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem.  When the candidate has been publicized, the details for this candidate will be provided. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-7547)
<sladen> CVEs are going to need 5 digits shortly
<Emanuel> https://twitter.com/RichFelker
<sarnold> in fact mitre plans on issuing a CVE with five digits potentially before it's needed just to ensure that tooling has adapted
<Emanuel> just read it
<sladen> https://googleonlinesecurity.blogspot.com/2016/02/cve-2015-7547-glibc-getaddrinfo-stack.html  was what I read earlier in the day
<ubottu> ** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem.  When the candidate has been publicized, the details for this candidate will be provided. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-7547)
<sladen> CVE-2015-12345
<sladen> sarnold: I think we can start with ubottu...
<sarnold> hehe
<kirkland> okay, I'm at a loss...  can someone help me identify why this keeps failing to build?  https://launchpadlibrarian.net/239090418/buildlog_ubuntu-xenial-amd64.ssh-import-id_5.2-0ubuntu1_BUILDING.txt.gz
<nacc> kirkland: "file ssh_import_id.py (for module ssh_import_id) not found" ?
<nacc> kirkland: just a guess
<kirkland> nacc: hmm
<sarnold> __version__ = pkg_resources.get_distribution('ssh_import_id').version   -- you've got an odd one on your hands, that's for sure :)
<kirkland> sarnold: is there a better way to print the current version a python package, from within the code of the package itself?
<sarnold> kirkland: no idea :/
<nacc> infinity: would you ahve time after (my) lunch to go over the php7 stuff?
<barry> kirkland: there are several approaches that won't require pkg_resources, but it depends on whether you want to do an import to get the version number or not.  for a lot of simple packages, they put the __version__ in a separate module (or mypkg/__init__.py) and you can just import it from there.  another popular non-import alternative is to put the version number in a .txt file and parse it out of there.  i have a common helper for
<barry> that, but it's also fairly easy to write.  to avoid putting a version number in multiple places, you'd use the same parse-or-import scheme in your setup.py and in whatever prints --version
<kirkland> barry: I think I might have found it...
<barry> kirkland: cool
<kirkland> barry: maybe :-)  new build sent
<kirkland> barry: what's odd is it builds fine here, on my xenial desktop, in a clean sandbox
<kirkland> barry: but not on LP
<barry> kirkland: in an sbuild?
<kirkland> barry: no, a pristine lxd container :-)
<kirkland> barry: the new sbuild :-)
<barry> kirkland: neat!  unfortunately lp is still the old sbuild :)
<kirkland> barry: :-D
<infinity> nacc: Possibly, I'm in the middle of a sprint right now, so it depends on if I can get away.
<smoser> pitti, if your'e still around. would you do the merge of open-iscsi?
<smoser> i'm quite loaded before thursday and would like to see that land before FF rather htan after.
<nacc> infinity: ok, so maybe it's best for you to ping me if/when you're free
 * tsimonq2 still can't figure out what sprint infinity is at :)
<nacc> jamespage: how do correclty update, e.g., eclipse's dependencyManifests directory? to point at the tomcat8 versions of the jars, etc.
<nacc> how do *I*, rather :)
#ubuntu-devel 2016-02-17
<twb> I'm interested in the packaging history of dnsmasq in ubuntu, in EOLd releases.  Is there something like git.debian.org or snaspshot.debian.org that'll let me look at the debian/ for dnsmasq?  There's no X-VCS- header, so I guess I need each .diff.gz...
<sarnold> twb: I thin kyou'd want to grab the .debian.tar.gz from each of the linked packages https://launchpad.net/ubuntu/+source/dnsmasq/+publishinghistory
<twb> Thanks
<sarnold> twb: there may be a scriptable solution around pull-lp-source but i'm less sure about that
<twb> I was checking old-releases.u.c and packages.u.c, I didn't think to try launchpad (herp derp)
<sarnold> (and that's liable to pull down all the .orig tarballs too, even thought you may not need them here)
<twb> I can probably ad-hoc script enough for my needs :-)
<sarnold> fun party trick, launchpad may also be the easiest way to answer the question for debian, too: https://launchpad.net/debian/+source/dnsmasq/+publishinghistory
<twb> Yeah for most stuff I can cheat and git clone git://git.debian.org/collab-maint/foo, or svn equivalent.
<twb> Although I guess not for really old releases
<kirkland> barry: okay, I'm still outta luck
<twb> Argh, curl auto-ungzipped the .diff.gz so now the checksums don't match in dpkg-source -x
<twb> Commenting "compressed" out in ~/.curlrc fixes that (and breaks some other sites)
<xnox> twb, http://old-releases.ubuntu.com/
<twb> xnox: I think that's only the install media
<xnox> twb, it has the full archieves.
<xnox> twb, wee ubuntu subdir.
<twb> Oh, OK.  I suck at reading, then :/
<xnox> twb, note that intermediate builds maybe garbagge collected. so typically the "final" released version is available in $adjective suite, and then latest per pocket e.g. $adjective-security.
<xnox> (including in launchpad)
<xnox> twb, you might get lucky with a bzr branch too.
<xnox> twb, http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/wily/dnsmasq/wily/changes
<xnox> appears to go back to 2005
<sarnold> is the bzr branch exhaustive? or does it only reflect when people used the UDD thing?
<mdeslaur> it's supposed to auto-import packages, but it doesn't work properly
<xnox> sarnold, it's off for xenial, and hit and miss in history, there are a bunch of unimportable stuff/revisions. but when it was started it was comprehensive. it went back and imported as much as possible.
<xnox> omg https://www.youtube.com/watch?v=GUlk1ssXJYk&feature=iv&src_vid=C2THq4UG_Eg&annotation_id=annotation_3271641833 is amazing
<sarnold> I wonder if this includes the suse guys dancing along..
<doko> kirkland, instead of disabling the tests, please can you just set a correct PYTHONPATH so that the tests find the just built module?
<kirkland> doko: hmm, a hint as to what that PYTHONPATH should be?
<doko> kirkland, I didn't look. will do tomorrow, it's 2am here. but in general just ask, others like barry or me might be able to help
<kirkland> doko: okay, thanks, I'd love some help with this;  I've been struggling with it for a while now
<doko> just saw the series of uploads
<kirkland> doko: I asked barry earlier today
<kirkland> doko: :-)  thanks for noticing and pinging me here
<kirkland> doko: i did see where barry's advice in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=803310 was to disable the tests
<ubottu> Debian bug 803310 in dh-python "dh-python lets the python3.4 test in sphinx-patchqueue succeed" [Important,Open]
<pitti> Good morning
<pitti> $1$.*+
<infinity> Guest54153: That's an awfully short password.
<Guest54153> it's not -- it's weechat's prompt for a password :)
<Unit193> infinity: You're not identified either, fwiw.
<infinity> Unit193: MAYBE I'M BEING A REBEL.
 * infinity goes to fix it.
<Unit193> infinity: THEN WE SUPPORT YOUR DECISION!
<infinity> Unit193: ;)
<Unit193> (Yes there is something wrong in my head, I know.)
<pitti> yay glibc and all those server reboots :)
<infinity> I'm so undecided on the media's reporting of nasty vulns over the last few years.
<infinity> On the one hand, I guess the press is helpful for getting people to actually act on it and upgrade.
<infinity> On the other hand, it's all rather alarmist and annoying.
<infinity> THE WORLD IS ENDING, UNPLUG ALL YOUR COMPUTERS AND BUY A GUN.
<ScottK> Wouldn't I need a computer to do that because it's not safe to leave my basement?
<infinity> ScottK: Buy a gun, THEN turn off your computer?
<ScottK> Fair enough.
<Unit193> What if I already have a gun?  Buy a handgun too?
<infinity> Unit193: You can never have too many on hand to defend against the machines.
<infinity> Unit193: Start by shooting your own computers, just in case.
<Unit193> Will do!
 * pitti suggests an EMP gun instead
<ScottK> The machines are probably their own Faraday cage, so as long as they are on the ground, not sure that'll do it.
<dholbach> good morning
<Mirv> slangase`: if you have time, the python package rename went through Debian NEW queue so debdiff would be ok to upload to Ubuntu https://launchpadlibrarian.net/240160130/debdiff_4.0.1-2ubuntu1_4.0.1-3ubuntu1.txt
<infinity> Mirv: Steve's on paternity leave for a month, sponsored it for you.
<Mirv> infinity: oh! great, to both of the mentioned things!
<ginggs> any archive-admins able to look at removal of python-support please? LP: #1535318 only 3 packages remain that directly depend on python-support
<ubottu> Launchpad bug 1535318 in python-support (Ubuntu) "deprecation of python-support" [Undecided,New] https://launchpad.net/bugs/1535318
<Laney> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Wily (15.10) 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-wily | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: Laney
<doko> LocutusOfBorg, dholbach: please follow-up on https://bugs.launchpad.net/ubuntu/+source/fonts-android/+bug/1536547  this is stuck in -proposed
<ubottu> Launchpad bug 1536547 in fonts-android (Ubuntu) "Sync fonts-android 1:6.0.1r3-2 (main) from Debian unstable (main)" [Wishlist,Fix released]
<dholbach> LocutusOfBorg, if you need sponsoring for a solution, let me know: ^
<doko> see http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt or look at the rdepends of the removed packages
<zhangchao> seb128, about new package request: https://bugs.launchpad.net/ubuntukylin/+bug/1536886,according to your proposal, the issues have been solved. Can you help upload this new package to archive ?
<ubottu> Launchpad bug 1536886 in Ubuntu Kylin "[needs-packaging] kylin-greeter" [High,Triaged]
<doko> seb128, did the last e-d-s upload trigger a transition?
<LocutusOfBorg> doko, dholbach I asked on mail list and all affected maintainers, nobody seems to care
<LocutusOfBorg> https://lists.ubuntu.com/archives/ubuntu-devel/2016-February/039159.html
<LocutusOfBorg> e.g.
<LocutusOfBorg> I don't want to make untested changes, so I would appreciate some help, at least from teams
<seb128> doko, no
<dholbach> LocutusOfBorg, can you send a followup mail to the list again?
<seb128> doko, it's a bugfix update, no packaging change
<LocutusOfBorg> sure dholbach
<seb128> zhangchao, I can try to but I'm quite busy this week, maybe Laney can help since he's patch piloting?
<seb128> doko, why?
<doko> seb128, ahh, no, libopenobex ...
<dholbach> LocutusOfBorg, awesome - thanks
<seb128> doko, k
<LocutusOfBorg> dholbach, actually reverse-recommends shouldn't be a big issue, maybe we can use the new noto font, and live happy
<LocutusOfBorg> assuming they didn't hardcode some font name (grep is needed)
<LocutusOfBorg> for reverse-depends debian packages should be fixed
<seb128> LocutusOfBorg, doko, dholbach, https://code.launchpad.net/~happyaron/ubuntu-seeds/lp-1468027/+merge/282265
<seb128> we got noto MIRed and changed the seed
<seb128> so that's the preferred solution
<zhangchao> Laney,about new package request: https://bugs.launchpad.net/ubuntukylin/+bug/1536886 . Can you help upload this new package to archive ?
<ubottu> Launchpad bug 1536886 in Ubuntu Kylin "[needs-packaging] kylin-greeter" [High,Triaged]
<seb128> (sorry I don't have full context, just read https://lists.ubuntu.com/archives/ubuntu-devel/2016-February/039159.html again and the 2 options=
<LocutusOfBorg> seb128, <3
<Laney> ...
<Laney> this will take most of the patch pilot shift
<seb128> Laney, I did review it in my previous shift and had just nitpicks, it should be easy
<seb128> Laney, I already pre-reviewed for NEW as well so if you upload I can NEW
<seb128> well, that's assuming that you are not pickier than me on packaging for the upload :p
<Laney> ok, but I don't like it, patch piloting is meant to help the community and this is a Canonical commitment which is bypassing the rest of the things in the queue now
<seb128> Laney, well, it's in the queue and community but feel free to not do it it's fine
<seb128> I'm going to have a look later or tomorrow if you don't get to it
<Laney> vila: bzr is stuck in -proposed because of bzr-upload and loggerhead
<Laney> seb128: it's okay I will do, just thinking that normal work sponsorship should be done out of patch pilot time
<Laney> vila: they both seem to have << 2.7.0 dependencies
<vila> Laney: ungh, where do you see that ? /o\
<Laney> vila: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html shows that it is a Valid Candidate but it didn't migrate yet
<seb128> Laney, I'm unsure to see the distinction you are making, it's a new package from a contributor who is going through sponsoring and sponsoring contributor work is what we do in patch pilot shifts?
<Laney> so look on http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html and see it there
<zhangchao> seb128, Laney, Thank you so much for your help :)
<LocutusOfBorg> does anybody have some sort of guide for understanding update_output in a human way?
<LocutusOfBorg> trying: fonts-android
<LocutusOfBorg> skipped: fonts-android (6 <- 56)
<LocutusOfBorg>     got: 250+0: a-138:a-18:a-17:i-16:p-19:p-19:s-23
<LocutusOfBorg> I don't remember exactly what does it mean
<LocutusOfBorg> britney britney, y u no verbose?
<doko> LocutusOfBorg, just look apt-cache rdepends <removed packages>
<LocutusOfBorg> mmm recommends aren't important?
<vila> Laney: hmm, can't find loggerhead or bzr-upload in http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html, bzr-upload is a bit of a mess but I know what is going on and have a wip for that (though it doesn't show up in excuses), but loggerhead I can't see.
<doko> apt-cache rdepends fonts-droid fonts-roboto
<doko> seb128, what do I have to do with the merge?
<Laney> seb128: I suppose I mean that I don't sponsor things for the general community super often, but there is some kind of work arrangement to do things for Kylin so it's easier to do this at any time? Not sure
<seb128> doko, that I don't know
<Laney> vila: look in update_output.txt - it says that your new bzr package makes the existing bzr-upload and loggerhead ones uninstallable
<Laney> vila and LocutusOfBorg: https://wiki.ubuntu.com/ProposedMigration
<seb128> Laney, right, I guess you can see it like that, I just see it as contributor work in the queue ... anyway I didn't want to start a big discussion and distract you from doing actual patch piloting, enjoy your shift! ;-)
<Laney> kylin-greeter looks forked from unity-greeter so I guess the packaging is probably close to okay ;-)
<LocutusOfBorg> Laney, thanks, I was reading that one :)
<vila> Laney: ha right ;-) Thanks for the subtitles ;-D
<Laney> vila: same is happening here https://release.debian.org/migration/testing.pl?package=bzr :-)
<vila> Laney: I'm in touch with jelmer for the debian side, bzr-pipeline and bzrtools already have the same patches as ubuntu, waiting for upload
<vila> Laney: bzr-upload has two issues, one already fixed (bzr deps), the other in the work (0 tests are run :-), I'll fix later via debian, and for the former here is https://bugs.launchpad.net/ubuntu/+source/bzr-upload/+bug/1546470
<ubottu> Launchpad bug 1546470 in bzr-upload (Ubuntu) "bz-upload blocking bzr-2.7.0 promotion" [Undecided,New]
<Laney> vila: thx
<Laney> seb128: zhangchao: I uploaded that, thx for the work
<vila> Laney: and https://bugs.launchpad.net/ubuntu/+source/loggerhead/+bug/1546482 should be good (I'll followup with debian)
<ubottu> Launchpad bug 1546482 in loggerhead (Ubuntu) "logerhead blocking bzr-2.7.0 promotion" [Undecided,New]
<seb128> Laney, thanks
<rbasak> rharper: strongswan git imports pushed. Please check they're OK. {old,new}/{debian,ubuntu} I'm not pushing to lpusd because those tags will change per-merge, and we don't (presumably) want to publish tags that change. I intended those really just for local use (and to push to your own repo for review if you want).
<Laney> vila: I saw, I will get it soon
<highvoltage> 3/win 30
<flexiondotorg> Laney, Any chance you'll be able to look at libwnck merge? LP: #1546066
<ubottu> Launchpad bug 1546066 in libwnck (Ubuntu) "Request merge with Debian for libwnck" [Wishlist,New] https://launchpad.net/bugs/1546066
<Laney> flexiondotorg: I did it already
<Laney> should be in t'NEW queue
<flexiondotorg> Laney, Thany you very much. That's great :-)
<Laney> yeehaw
<Laney> rbasak: don't suppose you know about all these php-* sponsoring requests do you? :)
<Laney> also, hi!
<rbasak> Laney: o/
<rbasak> Laney: nacc is taking care of them, with slangasek and infinity
<Laney> rbasak: ok - they look a bit daunting on the list
<rbasak> I am sort of sponsoring nacc, but for the PHP transition I thought it be best that an AA handled it directly.
<rbasak> (since there are bootstrapping coordinations needed)
<rbasak> And to my knowledge, I haven't been asked to sponsor anything yet.
<rbasak> I'm not sure if nacc intended them to actually be in the sponsorship queue to be sponsored by a patch pilot, or if he subscribed ~ubuntu-sponsors because the process said he should.
<Laney> 'k, I'll wait for a reply and then we can deal with it
<Laney> unsubscribe + tag is one option
<Laney> rharper: hey, I see you subscribed the sponsors to bug #1539634 - what action are you looking for there?
<ubottu> bug 1539634 in network-manager (Ubuntu Trusty) "network-manager crashes when using libnl-3-200-3.21.1-1ubuntu1" [High,Fix committed] https://launchpad.net/bugs/1539634
<cyphermox> good morning!
<caribou> when a packages is overrided by an SRU, is there a place where we can find the package with previous versions ?
<ogra_> on launchpad
<teward> i was about to say that too heh
<ogra_> :)
<Laney> @pilout out
<udevbot> Error: "pilout" is not a valid command.
<Laney> @pilot out
<caribou> ogra_: ah, true. thanks!
* udevbot changed the topic of #ubuntu-devel to: Wily (15.10) 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-wily | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<Laney> hmm
<rbasak> caribou: pull-lp-source takes an optional second version string parameter, too.
<caribou> rbasak: yeah, but I'm after the binary package
<rbasak> caribou: (and rmadison will tell you the release pocket version; LP can also give you every previously published version in a particular pocket)
<rbasak> Ah
<Son_Goku> rbasak: is there a chance thereâs something wrong with libpam-systemd in trusty?
<caribou> rbasak: lp is the solution I was after
<Son_Goku> I canât seem to build anything in a chroot that brings in that package as a dependency
<Son_Goku> either directly or indirectly
<rbasak> Son_Goku: there could well be. Trusty doesn't use systemd, so it presumably didn't get looked after back then.
<caribou> we need the previous version that was in trusty-updates to confiirm that cyphermox recent upload fixes a problem in multipath-tools-boot
<rbasak> caribou: I see. That makes sense. I don't know of an easier way other than manually hitting the Launchpad UI and dpkg directly.
<Son_Goku> rbasak: polkit-1 drags in libpam-systemd, which broke my debootstrap chroot for building libvirt packages (testing patches to libvirt for upstreaming)
<rbasak> (I'm sure that can be automated but I'm not aware of any tooling)
<caribou> rbasak: that's good enough
<Son_Goku> it also apparently breaks the OBSâ ability to even build packages the drag in polkit-1 as a dependency: https://build.opensuse.org/build/home:Pharaoh_Atem:u1404_libvirt/xUbuntu_14.04/x86_64/libvirt/_log
<Son_Goku> that one is building an Ubuntu VM to do builds, and that fails too
<cyphermox> caribou: yeah, lp
<cyphermox> caribou: could be easy to adapt this to pick the right version too : http://paste.ubuntu.com/15100153/
<caribou> cyphermox: funny my colleague couldn't figure out why his test system was no longer reproducing the bug
<cyphermox> I suppose that's goodish news
<rbasak> Son_Goku: I'm not sure, sorry. But if upstreaming, it might be easier to use Wily or Xenial. Trusty is pretty old now.
<rbasak> You'd effectively be backporting latest libvirt to Trusty otherwise, and that is non-trivial.
<Son_Goku> yeah, I know
<Son_Goku> my company wants us to do it because they want new libvirt on our fleet of 14.04 servers
<Son_Goku> and I can build it from source by hand on a regular Ubuntu system
<Son_Goku> but I canât do any clean builds at all :(
<caribou> I'm looking for a Debian Dev with a few spare cycles to create a project for me on alioth.debian.org/collab-maint. Anyone able to volunteer ?
<rbasak> Son_Goku: looks like Canonical already provide libvirt backports through UCA, though that's for use with Ubuntu's Openstack only (other uses unsupported).
<rbasak> You could base your work off that perhaps.
<rbasak> 1.3 not backported yet it seems.
<rbasak> Whatever you do, please publish it.
<rbasak> jamespage and/or coreycb might be interested in your work too if you end up backporting libvirt 1.3 to Trusty.
<caribou> cyphermox: FYI, going back to multipath-tools 7.7 does reproduce the problem so you last upload does fix the problem \o/
<Son_Goku> rbasak: sure, I just wish the chroots worked :(
<Son_Goku> Iâll poke and prod at it a bit more
<Son_Goku> rbasak: apparently, Iâm not the only one bitten: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1325142
<ubottu> Launchpad bug 1325142 in systemd (Ubuntu Utopic) "failure to update libpam-systemd in 14.04 due to missing logind init script" [High,Fix released]
<xnox> doko, should libdfp cpu target be bumped from power7 -> power8? or not yet?
<jtaylor> is there anything in a 14.04 -> 16.04 upgrade that could cause a kernel panic?
<nneul> Is there a set time in the release schedule at which point it would be safe to rely on apt-get upgrade getting you to the same state as a fresh install of the release? In particular, at what point will that apply for alphas/betas/etc. of 16.04?
<xnox> nneul, it's always the case... since the devel release got split into devel and devel-proposed.
<xnox> nneul, and well full-upgrade/dist-upgrade.
<xnox> sans bugs/errors that is.
<nneul> oh? I thought that there were still points during the early alphas where changes to the install infrastructure could result in the final install being different?
<nneul> Asked another way - I'm wanting to get some devel/test boxes up and running/deployed, but would rather not have to reinstall them again later.
<xnox> nneul, ..... support for xenial is at #ubuntu+1 channel
<nneul> thank you, will ask there!
<doko> xnox, sure, we don't need 7 anymore
<xnox> doko, ack will bump. updating to new upstream release for s390x here.
<spm_draget> I am testing Xenial right now. If I got this right, feature-freeze was 14th, correct? Installed the daily image from the 12th and upgraded today. Libvirt is not responding anymore. 'virsh list' does not return anymore. Not sure if this is related, but I see 'kernel: audit: type=1400 audit(1455716426.684:23): apparmor="DENIED" operation="open" profile="/usr/lib/libvirt/virt-a * Documentation:  https://help.ubuntu.com/mm="virt-aa-
<spm_draget> helper" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 ' in dmesg
<spm_draget> Any ideas how I should debug this?
<spm_draget> * Xenail Server
<LocutusOfBorg> jtaylor, which trusty kernel?
<LocutusOfBorg> if you try linux-lts-wily the bump is from 4.2 to 4.4
<LocutusOfBorg> otherwise 3.13 to 4.4 or so
<LocutusOfBorg> quite huge
<coreycb> arges, we have a few uploads in trusty/wily queues that could use a review if you or another sru team member could take a look when you get a chance
<rharper> Laney: I wanted to see about getting the libnl and the related network-manager SRU going;  I've done just about as much verification that I can; I should go ahead and mark them verification done; but I did want to check about phasing;   I've updated network-manager to include a breaks which should force dpkg to install the network-manager update before installing the libnl package;  but interested to know if there is
<rharper> anything else to do before marking verification-done and getting both of those into updates
<Laney> rharper: Nope, not if you're happy that they should go in - seems sensible to me
<rharper> Laney: excellent; thanks for the help
<jtaylor> LocutusOfBorg: 4.2
<jtaylor> I'm not clear how an upgrade could cause a panic
<jtaylor> does e.g. lvm change something in the disklayout during upgrade?
<jtaylor> maybe some changes in the network could cause it?
<jtaylor> the trace incldues vfs_write so network is probably not the cause
<arges> coreycb: sure
<coreycb> arges, thanks
<caribou> Q: When applying a debdiff on a source package that deletes a  patch, should a "quilt pop -a" be done beforehand ?
<caribou> deletes a QUILT patch btw
<arges> caribou: you mean debian/patched/blah.patch
<arges> patches
<caribou> arges: yes
<caribou> arges: what I see is that if I don't quilt pop -a in my source, debuild -S complains that the pristine file has been touched
<caribou> arges: which is coherent since quilt push -a has applied the patch that is removed in the debdiff
<arges> caribou: that could make sense if you delete the patch, when quilt pop -a is done it doesn't know about unapplying that patch anymore perhaps
<caribou> arges: actually sponsor-patch does it
<arges> caribou: another approach would be to extract the original sources and copy the debian directory in : ) but I think 'quilt pop -a' would be cleaner
<caribou> it pull-lp-source {package}, get the debdiff & applies it then bulk out since the patch has been applied to the source & then removed
<rbasak> caribou: things tend to be cleaner if debdiffs are always generated with all quilt patches popped and no .pc directory.
<rbasak> IMHO
<rbasak> bzr UDD doesn't do this, and ties itself up in knots as a result (again, IMHO)
<caribou> rbasak: yeah, I was first puzzled at .pc appearing in debdiffs
<caribou> rbasak: in that case, there is no other way than to pop out the patches in order to delete one
<caribou> rbasak: to build the debdiff. It is applying the debdiff afterward that causes  problem if the target source package still has the patches applied
<rharper> rbasak: I have an existing merge.xx branch locally, I'm creating a new 'merge' branch based on debian/sid; I need to git rebase -i <stuff from my merge.xx branch> onto this new merge branch;  but I've not figured out the right syntax
<rbasak> git branch merge merge.xx  # to create the new one that you'll rebase, assuming it doesn't exist already
<rbasak> git rebase --onto debian/sid old merge
<rbasak> Where "old" is your old new/debian commit hash. You can find this by looking at "git log merge" to see what commit it's based on (the previous Debian import) if the tags aren't clear.
<rbasak> (and to check, "git log old..merge" should show you only your Ubuntu delta)
<rharper> rbasak: ok, that makes sense; I was setting my merge branch to debian/sid and then merge had conflicts;
<rbasak> The general form is "git rebase --onto <new place you're replaying onto> <a> <b>" where "git log <a>..<b>" is the set of commits you're replaying.
<rbasak> (and <b> is the branch tip you're moving; it'll move, so branch <b> off first if you want to keep the old <b>)
<rbasak> (also note that old should be the last commit you _don't_ want to reply, not the first one you do)
<rharper> ah, the a..b helps; what set of commits to apply to the onto branch
<rbasak> Right
<rharper> rbasak: yes;  in particular for me 'old' is the import/5.3.5-1
<rbasak> Right
<rharper> cool!
<rharper> \o/
<rharper> sweet
<rbasak> Just wanted to check that you wouldn't accidentally drop the first commit in your Ubuntu delta, that makes it clear you won't :)
<rharper> yep
 * rbasak goes afk for a bit
<rharper> rbasak: thanks again!
<barry> pitti: planet-venus is holding up html5lib because it's Regression on armhf, but Always failed on all the other plats.  looks like we got unlucky (wink) in that planet-venus passed once on armhf and now we're forever blocked on it.  can/should we just pretend armhf is Always failed and let this one through?
<arges> coreycb: does the latest neutron/trusty upload also include the fixes for bug 1318721?
<ubottu> bug 1318721 in neutron (Ubuntu Trusty) "RPC timeout in all neutron agents" [High,Fix committed] https://launchpad.net/bugs/1318721
<coreycb> arges, yes it does, and the latest upload should fix up the dep8 issues that the prior upload was hitting
<arges> coreycb: ok
 * arges loves seeing random 'sleep 5' lines thrown into bash script
<coreycb> arges, it's pretty isn't it?
<arges> coreycb: i guess the worst case is your run this on a really overloaded/slow system and the sleep isn't long enough
<arges> probably should loop and check for pid a finite amount of times
<coreycb> arges, right.  it's not a pretty fix but we've done it before.  agreed that would be better.
<arges> coreycb: ack, yea i guess you'll be cleaning up any messes this causes
<coreycb> arges, good point
<arges> My View
<rharper> nacc: thanks for the help; along with rbasak;  I've pushed a merge branch into my repo; now looking to do a launchpad MP,  what do I put in for the target repo and target ref path ?
<nacc> rharper: target repo should the be the usd path for where you got the debian/sid commits from
<nacc> rharper: and target ref should be ubuntu/devel
<rharper> nacc: thanks!
<jdstrand> sbeattie: hey, is it just me or is this denial weird looking: audit: type=1400 audit(1455703199.526:434): apparmor="DENIED" operation="create" profile="/usr/sbin/ntpd" pid=15139 comm="ntpd" family="unspec" sock_type="dgram" protocol=0
<tyhicks> jdstrand: AF_UNSPEC is a valid socket family for some syscalls
<tyhicks> jdstrand: I didn't think it was valid for socket(), though. Is that the syscall that is triggering the denial?
<jdstrand> I don't know. I was looking at https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/1546455
<ubottu> Launchpad bug 1546455 in ntp (Ubuntu) "Many instances of 'apparmor="DENIED" operation="create" profile="/usr/sbin/ntpd" pid=15139 comm="ntpd" family="unspec" sock_type="dgram" protocol=0' in syslog" [Undecided,Confirmed]
<jdstrand> it's a new denial with yesterday's upload
<sbeattie> hunh, weird.
<tyhicks> jdstrand: was the family="unspec" the part that looked odd to you?
<jdstrand> yeah
<jdstrand> looking at the diff, I see code that using AF_UNSPEC
<tyhicks> jdstrand: have a link handy to the diff?
<jdstrand> http://launchpadlibrarian.net/237992992/ntp_1%3A4.2.6.p5+dfsg-3ubuntu9_1%3A4.2.8p4+dfsg-3ubuntu1.diff.gz
<jdstrand> line 316878
<jdstrand> it sets the family to that, the socktype to dgram and the protocol to udp
<robert_ancell> sarnold, thanks for revieweing bug 1475021 - regarding the zalloc fix, you haven't filed that anywhere right? I should do that?
<ubottu> bug 1475021 in gcab (Ubuntu) "[MIR] gcab" [High,Triaged] https://launchpad.net/bugs/1475021
<jdstrand> so I guess we can add 'network dgram udp, network stream tcp,' (I saw AF_UNSPEC later in the diff)
<jdstrand> (with tcp)
<jdstrand> oh those aren't valid
<tyhicks> udp == dgram and tcp == stream
<jdstrand> sure
<jdstrand> this is what I am thinking it should be changed to:
<jdstrand>   # ntp uses AF_INET, AF_INET6 and AF_UNSPEC
<jdstrand>   network dgram,
<jdstrand>   network stream,
<jdstrand> it was:
<jdstrand>   network inet dgram,
<jdstrand>   network inet6 dgram,
<jdstrand>   network inet stream,
<jdstrand>   network inet6 stream,
<tyhicks> I think that should be fine
 * jdstrand nods
<jdstrand> tyhicks: thanks!
<pitti> barry: that is already the case, see "Should wait for planet-venus 0~git9de2109-3ubuntu1 test, but forced by pitti"
<jdstrand> huh
<pitti> barry: see http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt search for "trying: html5lib"
<jdstrand> those rules aren't working
<barry> pitti: i don't really understand that output, but also, i uploaded a planet-venus that should at least pass its dep-8 (albeit perhaps bogusly but i think it's a mostly unmaintained package anyway)
<jdstrand> hrmm
<barry> pitti: but also, i trust you :)
<tyhicks> jdstrand: they aren't compiling or the kernel is still denying ntpd?
<jdstrand> tyhicks: we have a problem
<jdstrand> the kernel is still denying
<pitti> barry: it means that the new html5lib version makes that list of packages uninstallable: dh-virtualenv, python-pip-whl, python-tox, python-virtualenv, python3-venv, python3-virtualenv, python3.5-venv, tox, virtualenv, virtualenvwrapper
<barry> pitti: i also merged the ubuntu delta so i can just syncpackage it
<jdstrand>   network udp,
<jdstrand>   network tcp,
<jdstrand>   network dgram,
<jdstrand>   network stream,
<jdstrand>   network inet,
<jdstrand>   network inet6,
<jdstrand>   network,
<jdstrand> tyhicks: none of those work ^
<tyhicks> jdstrand: so the kernel isn't properly handling AF_UNSPEC?
<jdstrand> seems like it
<tyhicks> :/
<pitti> barry: seem's it's caught in that -whl transition?
<pitti> barry: and http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#python-pip does not promote because it breaks virtualenv
<tyhicks> jdstrand: I'll give it a look after I finish sorting something else out
<pitti> barry: and http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#python-virtualenv breaks tox
<pitti> barry: I'll try to run all those tests from -proposed, but I already did that some days ago
<barry> pitti: yes.  tox 2.3.1-2 should fix python-virtualenv, which should let them all pass
<jdstrand> tyhicks: all you have to do is apt-get install ntp on an up to date xenial system. you need 1:4.2.8p4+dfsg-3ubuntu1
<pitti> barry: ah, that landed 3 hours ago, so time for some retries indeed
<barry> pitti: yep.  will you poke at them?
<jdstrand> tyhicks: I'm going to upload with the new rules and add an apparmor task. does that sound reasonable?
<pitti> barry: yes
<barry> pitti: awesome, thanks!
<tyhicks> jdstrand: thanks - I'll see if I can spot the kernel issue
<tyhicks> jdstrand: yes
<barry> pitti: i'll keep an eye on things too, but if something gets caught up, do ping me
<pitti> barry: eek, we just got Qt'ed again, so that'll take a while, sorry (see http://autopkgtest.ubuntu.com/running.shtml)
<barry> pitti: that's okay, it's lunch time here :)
<ogra_> woah !
<ogra_> ogra@anubis:~/datengrab/generic-initrd$ dput ppa:ogra/ppa initramfs-tools-ubuntu-core_0.7.17_source.changes
<ogra_> ...
<ogra_> RuntimeError: Failed to read %zi bytes from /dev/urandom
<ogra_> ogra@anubis:~/datengrab/generic-initrd$
<ogra_> (this is trusty)
<pitti> barry: ah, I see you already queued retries; I also queued some with using all of -proposed (as they don't seem to have versioned deps)
<barry> pitti: +1
<pitti> barry: ah, stuff is green on s390x again, so the other arches should go green too (once they ever catch up..)
<pitti> I'm still not sure what http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#python-setuptools is supposed to mean
<mterry> pitti, are there logs for the generation of touch langpacks?  I wanna see if I can tell where the pam inclusion went wrong
<mterry> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Wily (15.10) 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-wily | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: mterry
<pitti> mterry: yes, http://macquarie.canonical.com/~langpack/logs/xenial-touch.log -- indeed no trace of them
<pitti> mterry: can you please check if http://launchpadlibrarian.net/240166862/ubuntu-rtm-15.04-translations.tar.gz actually contains "pam"? (sorry, about to have a meeting)
<mterry> pitti, sure
<pitti> mterry: curiously there is a locale named "pam" too :)
<mterry> pitti, no it doesn't seem to be in that tarball.  The actual gettext domain is Linux-PAM, didn't see it in expected places (like es or fr)
<mterry> Wonder where the 'pam' locale is
<rbasak> nacc: http://reqorts.qa.ubuntu.com/reports/sponsoring/index.html
<swt2c> Hello all.  A package I maintain in Debian failed to build in Xenial due to a broken dependency.  That dependency has been fixed, so I was wondering if there is some way to request the autobuilder try to build it again (besides bumping the package revision)?
<pitti> mterry: oh, I just saw http://bazaar.launchpad.net/~ubuntu-langpack/langpack-o-matic/main/view/head:/cron.daily.rtm
<pitti> mterry: it seems it actually merges together the distro and the RTM "overlay" tarballs, so Linux-PAM ought to come from that
<pitti> mterry: (sorry, not very familiar with that, this is sil2100's domain)
<sil2100> uh oh
 * sil2100 hides
<mterry> sil2100, :)
<kickinz1> rbasak, did you get any chances to review amavisd-new? Can you prepare ubuntu-server-dev git for me to rebase moin and urgrabber merges?
<mterry> sil2100, I'm trying to get pam's translations (domain Linux-PAM) in touch
<pitti> mterry: but the log actually has lots of "Copying cs/Linux-PAM into package ../xenial/sources-touch/language-pack-touch-cs
<pitti> sil2100: nevermind
<pitti> mterry: so they ought to be there?
<pitti> mterry: I grepped for "pam" thus I didn't see the all-caps name
<mterry> pitti, right, I see it too
<ogra_> heh
<ogra_> ogra@anubis:~$ apt-cache search realpath
<ogra_> realpath - Gibt den kanonisierten absoluten Pfadnamen zurÃ¼ck
<ogra_> sometimes there are words you shouldnt translate ...
<pitti> mterry: sorry, wrong log -- so the *xenial* touch packages have it
<mterry> hm
 * ogra_ never heard "kanonisiert"
<pitti> mterry: but what you are looking at is http://macquarie.canonical.com/~langpack/logs/15.04-touch.log
<pitti> mterry: that's from the cron.daily.rtm cronjob
<mterry> pitti, uh oh...  did I not update the 15.04 map in that MP?
<pitti> mterry: ooh! your latest commit into langpack-o-matic (r552) did only add it to pkglist-touch-{vivid,xenial}
<pitti> mterry: but not the 15.04 map
<pitti> voilÃ  :)
<mterry> pitti, duh
<pitti> mterry: it's still a bit unclear how these can be auto-generated
<rbasak> kickinz1: sorry otp
<pitti> sil2100: ah btw, thanks for explaining the -meta issue for RTM
<mterry> pitti, ok I can propose a new branch for that
<pitti> mterry: but with that ^ it means we don't actually have a seed branch which we can check out
<sil2100> pitti: no worries, it's a bit confusing, we know - not the cleanest approach but works
<mterry> pitti, but I'd have to do it manually
<pitti> mterry: so I guess we can sync this up with xenial once, or make it identical to xenial if that's the right thing to do, or maintain it manually just like the -meta package in the overlay PPA?
<sil2100> (at least worked so far)
<mterry> pitti, what's that about seeds?
<pitti> mterry: so TL;DR: to unblock this, let's just add it to these map files manually for now
<rbasak> nacc: https://bugs.launchpad.net/~nacc/+reportedbugs
<pitti> mterry: nevermind, I just commit it, it's trivial
<mterry> pitti, heh ok
<mterry> pitti, is it possible to remake langpacks?  I want to make sure that we actually end up using the translations correctly too, once they're in place
<pitti> mterry: done and rolled out, so without further ado next Tuesday's cronjob will pick that up
<pitti> mterry: with a bit of fiddling, as they will normally get the same version number
<pitti> mterry: I'll make a note (I need to run off for some hours), I'll do the surgery later tonight
<mterry> pitti, ah maybe not important.  I can test manually by putting some mo files in place
<pitti> mterry: it's not that difficult, just more than running a cronjob and doing it with only half of my attentino
 * pitti -> out for some hours
 * doko looks at eight running unity8 builds on s390x ... great platform for unity
<ogra_> does it support gestures ?
<sarnold> robert_ancell: please do, I mailed the upstream author about the g_malloc_n() issue (and the other minor things), but that's it
<damascene> guys, how can a package ask for exception of feature freeze?
<rbasak> damascene: https://wiki.ubuntu.com/FreezeExceptionProcess
<teward> heh i was about to link that
<damascene> thank you both âº
<rbasak> teward: oh you had a question for me.
<rbasak> Sorry. I'll look back at that now.
<teward> rbasak: no super super rush, but i'd ideally like to get 1.9.11 in before FF so I don't have to go through the exception process, heh.  But yeah, it's really just figuring out which is the lesser of two options to fix a fail-to-build :P
<jderose> pitti: i believe i was just hit by lp:1252121 for the first time... it consistently happens on hardware with Killer E2400 Ethernet controllers (Ethernet is disconnected after resume, wont reconnect even if you unplug/re-plug the cable)
<jderose> pitti: one horrible, hacky work-around i've found that works is to use a /etc/pm/sleep.d/ script to restart network-manager upon resume. any ideas?
<hallyn> pitti: pam-auth-update: Local modifications to /etc/pam.d/common-*, not updating.
<hallyn> (updating systemd)
<hallyn> oh, nm
<hallyn> i misread :)
<hallyn> uh, what is "inheritable capabilities management" pam module?
<hallyn> huh
<hallyn> anyway, pitti, if you're actually around (i assume you're sleeping), some hints about systemd-machined would be very much appreciated.  (comment #33 in bug 1529079)
<ubottu> bug 1529079 in systemd (Ubuntu) "Can't start virtual machines after upgrade to Xenial" [High,Confirmed] https://launchpad.net/bugs/1529079
<barry> pitti: i messed up the upload of tox 2.3.1-2.  just uploaded 2.3.1-3 so once that winds through the system i think we'll be okay
<mterry> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Wily (15.10) 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-wily | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<superm1> robert_ancell: i uploaded the fix that sarnold recommended that was blocking the gcab MIR, mterry promoted gcab to main and then I uploaded all the stuff to undo disabling firmware on appstream-glib
<robert_ancell> superm1, I saw that, thanks!
<superm1> sure thing
<superm1> so i guess the only stuff blocking firmware still on gnome-software is fwupd and fwupdate need updated security reviews
<robert_ancell> yes
<robert_ancell> Then we should re-enable in GNOME Software I guess.
<infinity> superm1: Is anyone testing mythbuntu for 14.04.4?
<superm1> tgm4883: ^
<superm1> he's closer in the loop on that right now
<infinity> superm1: At this point, *anyone* would do, just to boot/install/reboot smoketest.  The time for deep testing is passed anyway. :P
<superm1> he had some folks lined up that did testing the last go around, but i'm not sure where they are now
<superm1> robert_ancell: will fwupd end up a recommends of gnome-software or will it be seeded in ubuntu-desktop meta?  i noticed in debian it's only suggests
<robert_ancell> superm1, I think it will be a recommends / or seeded. It seems like it will be a popular feature. I'm not driving the adoption though.
<superm1> well so far only my company has published any real firmware that can be used by it, but i'm hoping it does get popular and used widely :)
<robert_ancell> superm1, now I'm regretting my switch to Toshiba :)
<xnox> doko, forced synced golang-pty to get us to the same as the newer debian upstream release. if it lacks architecture supports, i'll resurect patches.
<tgm4883> superm1: I'll do one when I get home. Leaving work now
<xnox> doko, actually ppc types are missing =(
#ubuntu-devel 2016-02-18
<tgm4883> infinity: downloading the isos now
<tgm4883> infinity: sorry meant to do it a few days ago when you pinged me
<hallyn> pitti: i've only run adt_run with --source.  How do I tell it to use the .debs in my cwd ?
<nacc> hallyn: the order of params matters, iirc, if you pass it properly as the first param ("filename" in the manpage) and then specify -B, it won't build the source
<hallyn> nacc: as it turns out pkg doesn 'thave tests anyway :)  but still curious.  thanks
<smoser> pitti, around ?
<tjaalton> any hope getting libpng16 (in experimental) to xenial?
<tjaalton> a migration to it might be out of the question, but having this even in universe should be ok?
<smoser> pitti, well, when you come in, if you could look at my debdiff for open-iscsi and see if it is in line with yours and then just upload .. i'd appreciate it.
<smoser> https://bugs.launchpad.net/ubuntu/+source/open-iscsi/+bug/1546877
<ubottu> Launchpad bug 1546877 in open-iscsi (Ubuntu) "sync with debian testing (2.0.873+git0.3b4b4500-13)" [Medium,Confirmed]
<RAOF> doko: Is https://gcc.gnu.org/bugzilla really the gcc bugzilla? I've run into a clear bug with gcc-6 compilation in Mir, but none of my searches seem to find anything there.
<RAOF> (Specifically, âdelete this;â triggers -Wnonnull-compare, which is clearly bollocks)
<RAOF> Oh, hah. Missed https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69850
<ubottu> gcc.gnu.org bug 69850 in c++ "[6 Regression] unnecessary -Wnonnull-compare warning" [Normal,Resolved: fixed]
<RAOF> doko: Unping.
<cpaelzer> good morning
<Pharaoh_Atem> argh
<Pharaoh_Atem> I'm rather frazzled trying to figure out why the php7.0 autopkgtests are failing...
<Pharaoh_Atem> I see it here that every test except cli fails
<Pharaoh_Atem> ugh, I'm tired
<pitti> Good morning
<pitti> hallyn: adt-run with .debs> adt-run *.deb -B *.dsc ...  -- it's one of the cases in https://people.debian.org/~mpitt/autopkgtest/README.running-tests.html
<pitti> hallyn: queued the libvirt bug, but adding a proper reproducer to the bug would be appreciated
<pitti> hallyn: i. e. starting from a blank install
<pitti> smoser: yes, will do
<hallyn> pitti: if you have any VMs defined, just apt-get install systemd-container will make them break.  is that enough of a reproducer?
<hallyn> if not i'll post soemthing in th emorning
<hallyn> thanks, will store that adt-run exacmple cmd for next time ^
<cyphermox> good morning pitti!
<hallyn> (btw, for starting from clean install it'll basically be https://wiki.ubuntu.com/SergeHallyn_libvirtnest, but i'l post details in the monring)
 * hallyn out
<pitti> hallyn: adding them with virt-manager?
<pitti> hey cyphermox
<pitti> I'll try that
<seb128> barry, thanks for the libpeas depends fixed but can you commit your changes to the packaging vcses as well?
<seb128> barry, gedit/rhythmbox at least have one
<dholbach> good morning
<pitti> smoser: we still need the debian/net-interface-handler? can't we teach those images to either not write an interfaces.d/ stanza or set a "manual" one at least?
<pitti> smoser: that seems much cleaner than doing the wrong thing in the install and then hacking around it
<ginggs> morning! any archive admins around to look at removing the last 3 packages that directly depend on python-support LP: #1535318 ?
<ubottu> Launchpad bug 1535318 in python-support (Ubuntu) "deprecation of python-support" [Undecided,New] https://launchpad.net/bugs/1535318
<doko> sil2100, could you still merge python-pysaml2?
<sil2100> doko: hey, sure, adding it for my today's todo list
<Laney> juliank: hi, any idea if there's a way we can make appstream download its files the first time it is installed instead of requiring a second apt update?
<juliank> Laney: Hmm, maybe you could install an APT config file somewhere else (in an unsynced package, not apt...) that adds a script in DPkg::Post-Invoke that checks whether appstream was installed and runs update, but apart from that, no.
<juliank> Laney: You could of course also add an identical appstream config file to a base package.
<doko> tjaalton, xorg gained two new deps, needs a MIR, or be dropped
<tjaalton> doko: which ones?
<doko> tjaalton, http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg
<pitti> smoser: but otherwise LGTM, so I'll upload this for now; I hope we clean this up further at some point; thanks for the merge!
<doko> cjwatson, stgraber, cyphermox: casper wants to pull in lzma (since 2011). wondering why we didn't care until now, or is this a false positive?
<tjaalton> doko: -void is for s390, and freedreno for arm, guess we want both
<jtaylor> anyone tried open-iscisi on xenial?
<jtaylor> seems we have bug 1444555 again
<ubottu> bug 1444555 in ifupdown (Ubuntu) "open-iscsi init script causing ordering cycle with systemd" [High,Fix released] https://launchpad.net/bugs/1444555
<jtaylor> not fun when it randomly decides to not start networkmanager
<doko> tjaalton, looks like so
<jtaylor> bug 1465196, pitti if you need help testing I have a system that can be used
<ubottu> bug 1465196 in open-iscsi (Ubuntu) "open-iscsi init script creates dependency cycle with NetworkManager" [High,Triaged] https://launchpad.net/bugs/1465196
<doko> seb128, Laney: appstream needs a MIR (dependency of gnome-software)
<Laney> you mean https://bugs.launchpad.net/ubuntu/+source/appstream/+bug/1538293 ?
<ubottu> Launchpad bug 1538293 in appstream (Ubuntu) "[MIR] appstream" [Undecided,Fix released]
<jtaylor> doko: can we have a vim built with python2 in xenial? switching to python3 breaks evverything
<jtaylor> ok maybe not everything, but a lot ._.
<doko> jtaylor, well, there's one bug report, and apparently upstream is working on it
<doko> I'd rather grant exceptions to fix things
<jtaylor> doko: which upstream? there are hundreds of scripts in python2
<jtaylor> almost none of them are packaged
<doko> jtaylor, sure, but then can you point out a way forward? these scripts will be still there in years
<jtaylor> stick with python2?
<jtaylor> provide a new vim-py3 for the few who actually have py3 only scripts
<doko> no, python2 is a dead end. I mean, you could package it separately.
<doko> no, our default vim is linked with python. if you want that, then do a vim-py2
<jtaylor> a vim-py2 would be fine too
<jtaylor> but given that probably 100% of all plugins are python2 I think the other way round is better
<jtaylor> there is no distro that ships py3 vim, so zero plugins support it
<doko> not even arch?
<jtaylor> maybe arch
<doko> https://github.com/Valloric/YouCompleteMe/issues/1940
<doko> that's one packaged I know about
<jtaylor> actually they have a vim-python3 package
<jtaylor> yes in a version thats old and doesn't work
<jtaylor> though I didn't check if it changed since vivid
<jtaylor> imo switching vim is a larger problem than switching gdb was and that was a catastrophy
<jtaylor> basically gdb from repo was unusable for years for many people
<doko> ugh, years == 2, you seem to exxagerate ;)
<doko> so which variants should be provided for python2, nox and gtk?
<doko> or all?
<jtaylor> I'd say all, though I only use terminal vim
<jtaylor> other people might use the guis
<jtaylor> 2 > 1 = years ;) still a very long time
<jtaylor> gdb has the advantage that its a dev tool so its no problem for users to rebuild gdb yourself, vim is not only a dev tool so I think its more problematic
<doko> lets see how easy these loops would be ...
<cjwatson> swt2c: I didn't see anyone answer you; we can certainly retry such things.  Which package are you talking about?
<cjwatson> doko: When you say "since 2011" ... lzma was in main in vivid, and then for some reason demoted in wily despite casper's dependency
<doko> cjwatson, ok, just promoting then
<cjwatson> thanks
<doko> Laney, seb128: texlive-extra-fonts (owned by desktop) wants to promote 20 font packages ... I assume we just don't care about all those maintained by the debian fonts task force, however there are two maintained by individal maintainers
<doko> fonts-cabin fonts-comfortaa fonts-crosextra-caladea fonts-crosextra-carlito fonts-dejavu fonts-ebgaramond fonts-font-awesome fonts-freefont fonts-gfs-artemisia fonts-gfs-complutum fonts-gfs-didot fonts-gfs-neohellenic fonts-gfs-olga fonts-gfs-solomos fonts-junicode fonts-lato fonts-linuxlibertine fonts-lobstertwo fonts-oflb-asana-math fonts-roboto fonts-sil-gentium fonts-sil-gentium-basic fonts-sil-gentiumplus fonts-stix ttf-adf
<doko> these are fonts-stix ttf-adf
<doko> could you have a look at these?
<doko> writing a MIR for the others
<xnox> slangasek, cjwatson, pitti - is lp:~ubuntu-release/britney/britney2-ubuntu up to date? e.g. s390x is not listed as an Architecture in britney.conf
<xnox> ADT_ARCHES don't look to be up to date either.
<pitti> xnox: britney1-ubuntu adds it for xenial only
<pitti> xnox: yes, it's up to date, and snakefruit pulls that branch before every run
<pitti> xnox: search for s390x in http://bazaar.launchpad.net/~ubuntu-release/britney/britney1-ubuntu/view/head:/britney
<pitti> xnox: this part munges the default config to release-specific settings, such as "no ppc64el on precise" or "s390 on xenial only"
<pitti> xnox: arguably this could be swapped around, e. g. add s390 to the default and remove it from all earlier series
<xnox> pitti, gotcha. it's all good, just looking about.
<carldani> Hi!
<carldani> Is this the right channel to ask about updating packages before the freeze?
<ogra_> pitti, cjwatson, what happened to livecd-rootfs now, did you already do the git switch (i have some changes to make and it would be good to know the proposed new workflow (bzr branch/make changes as UNRELEASED/commit/bump version/debcommit/push was my old flow)
<ogra_> (might probably be good to have that on the https://wiki.ubuntu.com/ReleaseTeam/CDImageSetup wikipage
<ogra_> )
<pitti> ogra_: I don't know if it already got coverted, I didn't hear about updates either
<pitti> ogra_: dch -r / debcommit -ar etc. work with git branches too, FTR
<ogra_> good
<ogra_> still, it would be nice to have it documented if there is new workflow :)
<xnox> pitti, cjwatson - in our ogre model, do universe packages allowed to depend on restricted packages?
<ogra_> shouldnt restricted be solely for HW enablement ?
<ogra_> (would anything depend on such stuff at all ?)
<pitti> xnox: they certainly shouldn't
<pitti> however, I'm not entirely sure how buildds etc. implement that
<xnox> pitti, i'm making britney component aware and i was hoping to make it a simple <= integer comparison. main is 0, multiverse is 3, and things can depend on stuff which is <= of their number =)
<xnox> pitti, i guess the buildlog for a universe package would tell me, e.g. if restricted is enabled or not.
<cpaelzer> Hi, I try to reproduce an dependent autopkgtest failure of an upload - so I have package A (the trigger) and B (the dependent one which fails its test)
<cpaelzer> I try to puzzle to gether the equivalent adt-run invokation, so far I'm assuming it is using the triggers "--source A.dsc" (to build and test) and the dependent from the archive as is like "--no-built-binaries --apt-source B"
<cpaelzer> So overall "adt-run --source A.dsc --no-built-binaries --apt-source B  ..." does that make sense?
<pitti> xnox: indeed, it's main and universe  only
<wgrant> xnox: No, free can only depend on free.
<xnox> wgrant, darn =)
<xnox> wgrant, ok.
<pitti> cpaelzer: no, we don't test two different source pacakges
<pitti> cpaelzer: the trigger just defines that we take the trigger's binaries from -proposed, and the rest (as much as possible) from -release
<wgrant> xnox: https://git.launchpad.net/launchpad/tree/lib/lp/soyuz/adapters/archivedependencies.py#n60
<pitti> cpaelzer: if you look at the build log, the full adt-run invocation is printed there
<xnox> wgrant, omg partner...
<cpaelzer> pitti: in the build not the test log, thanks I'll take a look
<pitti> cpaelzer: that has some extra stuff which you don't need, and it uses ssh nova instead of qemu, but you should get the idea
<xnox> wgrant, wait how does that work? partner manages to build without main?!
<pitti> cpaelzer: sorry, yes, test log; what's teh URL?
<cpaelzer> pitti: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/o/openvswitch-dpdk/20160217_200054@/log.gz yeah its right at the top
<cpaelzer> pitti: I focussed so much on the issue at the end to overlook that - great thank you a lot
<cpaelzer> I can derive my invokation from there I think
<pitti> cpaelzer: right, so: adt-run --apt-pocket=proposed=src:dpdk --apt-upgrade openvswitch-dpdk --- qemu ...
<pitti> (or --- lxd or whatever suits you)
<cpaelzer> pitti: thanks
<wgrant> xnox: Parter is a separate archive, and that archive has a separate dependency on the primary archive.
<wgrant> That dependency includes all components.
<cpaelzer> I must thank all of the channel in general at least once, I try to keep questions rare to not annoy, but whenever I get here with a question you are all so full of help - even with FF around
<xnox> wgrant, ack.
 * xnox grabs coffee
<cjwatson> ogra_: I haven't done any conversion as yet.
<ogra_> cjwatson, ok, thanks
<doko> smoser, http://autopkgtest.ubuntu.com/packages/o/open-iscsi/xenial/amd64/
<flexiondotorg_> I new package has just landed in Debian unstable that I would like to use in Ubuntu MATE 16.04.
<flexiondotorg_> When will the sync with Debian be halted?
<flexiondotorg_> Is there time for this to flow into the Xenial automatically?
<cjwatson> I was planning to halt it after I get back from the pub tonight.
<cjwatson> i.e. after the 23:00 UTC run finishes
<cjwatson> So a package that just hit unstable will probably just about make it automatically
<jamesh> would anyone be able to help me with a problem in the new sqlite3 upload?
<jamesh> It has broken mediascanner, and I've left the information I've gathered at https://bugs.launchpad.net/ubuntu/+source/sqlite3/+bug/1546911
<ubottu> Launchpad bug 1546911 in mediascanner2 (Ubuntu) "Please recompile sqlite 3.11 with -DSQLITE_ENABLE_FTS3_TOKENIZER" [Critical,Confirmed]
<flexiondotorg_> cjwatson, Thanks. If it does make it in time I'll file a requestsync.
<flexiondotorg_> *doesn't
<ogra_> pitti, oh, and before i forget about it *again* ... there is bug 1547033 for you
<ubottu> bug 1547033 in systemd (Ubuntu) "please allow /etc/mtab to be a pre-existing link on readonly filesystems" [Undecided,New] https://launchpad.net/bugs/1547033
<doko> xnox, looks like s390x only: https://bugs.launchpad.net/bugs/1546987
<ogra_> (purely cosmetic though)
<ubottu> Launchpad bug 1546987 in libica (Ubuntu) "[MIR] libica, runtime and build dependency of opencryptoki" [High,New]
<xnox> doko, it is s390x only.
<mterry> I'm seeing an odd test failure only on arm64: inside the standard python lib, tempfile.TemporaryFile() fails with "No such file or directory" when it's trying to open a file with O_CREAT...  Am I crazy or does that seem crazy...?
<mterry> Oh... I guess that would happen if the directory it's trying to create in doesn't exist
<xnox> pitti, cjwatson - i have a patch for britney... how does one run britney locally?
<xnox> (teaching exuses unsatisfyable dependency about components)
<Unit193> mitya57: Know anything about Qt5 not showing the icon in the indicator?  indicator icons of Qt5 applications in Xenial are getting the "broken icon", or little x.
<mdeslaur> cjwatson: I'm stealing your cpio merge
<pitti> xnox: tests/test_autopkgtest.py works straight out of a checkout
<pitti> xnox: and sets up necessary bits; for running manually, see https://wiki.ubuntu.com/ProposedMigration/LocalSetup
<cjwatson> mdeslaur: go for it
<doko> jtaylor, new vim in -release
<mitya57> Unit193, do you have an example of such application?
<Unit193> mitya57: Dropbox (which ships its own stuff), cmst.  Using Xfce.
<xnox> pitti, maybe that britney-indexes script should be simply committed into britney2-ubuntu branch.
<pitti> xnox: it's more like a PoC, I'm afraid, far from production ready
<pitti> xnox: robru has a better implementation in the CI train, if anything we should rather take his'
<pitti> xnox: but, just write a test case and the tests will set up stuff or you :)
<xnox> =))))
<barry> seb128: yes, let me look into it
<seb128> barry, thanks
<seb128> barry, also unsure if you noticed, but software-center&co are off the iso today
<barry> seb128: i haven't, but YAY!
<seb128> :-)
<barry> seb128: thank everyone who worked on this.  i'll grab a daily later today and see what's left of py2, though i suspect it'll be samba-libs
<_hc> hey all, I checked in here last week about the Android SDK packages.  We just did a big push to get lots of it done in time for the xenial freeze, so I wanted to make sure it all gets smoothly imported before that freeze happens.  There are a couple still outstanding, like android-platfrom-frameworks-base
<_hc> and android-sdk-meta
<doko> barry, I started adding packages for talloc, tdb and ldb
<barry> doko: oh!  anything i can look at or help with?  that's the next thing to attack i think
<_hc> I'm a DD, so I can trade Debian work for Ubuntu work :)
<seb128> barry, right, seems mostly samba-libs
<doko> mdeslaur, just saw your cpio upload. maybe we should just promote mingw64, it's easier to let these packages drop to universe than to change everything. and there is no fear that pitti will be able to run autopkg tests on these binaries ;)
<_hc> I spoke with cjwatson before ^^
<seb128> but also deja-dup-backend-gvfs which depends on python-gi, but that might just be a packaging error
<seb128> mterry, ^ do you know?
<pitti> doko: lol
<barry> seb128, doko i traded some emails w/a fedora guy.  he made it seem like samba-libs was a long way off, but i haven't really started looking at it in detail
<doko> barry, I'll upload talloc
<barry> (he said it wasn't as easy as splitting the packaging because some stuff does imports at the c level)
<barry> doko: cool, thanks
<mterry> seb128, hrm...  right...
<seb128> mterry, deja-dup-backend-gvfs seems empty, is that wanted?
<mterry> seb128, it's not a packaging error...
<cjwatson> _hc: looking
<seb128> mterry, if so maybe the description should state it's a transitional package?
<mterry> seb128, it's a metapackage meant to pull in the python dependencies that duplicity will need to support gvfs backends
<xnox> pitti, winning! it found maas -> probably built elsewhere, main package depends on a universe one.
<mterry> seb128, but now that we pull in duplicity on the fly...
<cjwatson> _hc: I think the main problem is that android-platform-system-core is failing to install its build-dependencies, but it's a little hard to tell since it's running into a build daemon crash that we're working on separately
<mitya57> Unit193, dropbox is Qt 4, isn't it? Will look at cmst a bit later
<_hc> hmm
<cjwatson> that might just work now if I cancel and retry, so I'll give that a go
<Unit193> mitya57: Not as of recently.
<mterry> seb128, it's not transitional
<_hc> something related to GCC6? That's the only one I'm aware of
<seb128> mterry, yeah, sorry I was typing before reading your previous comment
<cjwatson> _hc: no, https://anonscm.debian.org/cgit/buildd-tools/sbuild.git/commit/?id=e2d63ebc20c8d2ef5d96db83828087505928895f
<mterry> seb128, but I guess deja-dup should pull it in at the same time it pulls in duplicity
<seb128> right
<cjwatson> _hc: I don't know what you're referring to about GCC6
<barry> seb128: gedit & rhythmbox pushed
<mterry> seb128, let me look at a quick patch
<seb128> mterry, thanks!
<mitya57> Unit193, didn't know about that, nice!
<Unit193> Not if they've bundled half the stack still. :P
<Unit193> mitya57: Oh bah, while those two don't, vlc does show fine.
<_hc> this is the GCC6 FTBFS that we haven't had a chance to look at, gcc6 seems far off https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=811716
<ubottu> Debian bug 811716 in android-platform-system-core "libutils: FTBFS with GCC 6: redeclaration of C++" [Important,Open]
<cjwatson> _hc: no, nothing to do with that, like I say this is in build-dep installation
<cjwatson> _hc: BTW there isn't really a freeze concern here, since it's already in -proposed, but we certainly ought to get it finished off
<_hc> (sorry, I bit slow, since I'm sick)
<_hc> ok, good to know about proposed
<xnox> pitti, cjwatson: so https://code.launchpad.net/~xnox/britney/deps-components/+merge/286511 is good to go imho =) tested it as best as possible outside of production infrastructure.
<_hc> cjwatson: there are a couple less critical ones just hitting Debian/unstable now, will those make it automatically? for example android-platform-tools-base
<cjwatson> _hc: marginal
<cjwatson> _hc: you may have to ask for those, either using requestsync(1) or by asking an Ubuntu developer
<_hc> shall I check in on those tomorrow, or later today?
<cjwatson> xnox: (I'm quite unlikely to have time to review this, at least not today - been procrastinating the thing I'm actually supposed to be doing badly enough as it is)
<_hc> just trying to figure out when the best time to ask is
<xnox> cjwatson, no worries. it's mostly my knee-jerk reaction to rebute doko on the archive reorg proposal =)
<_hc> we're going to be uploading a couple more packages since we have them done, but we don't expect those to make it.  But we're happy to help if y'all want them in
<_hc> ubuntu
<cjwatson> xnox: I don't see anything immediately odd but would be nice to spell "available" and "component-mismatches" correctly :)
<cjwatson> (yes, most useless review ever, sorry)
<cjwatson> _hc: it depends on dinstall cycles and such, so I think probably tomorrow
<xnox> cjwatson, ^_^ thanks =)
<xnox> will fix.
<_hc> thanks!
<kickinz1> caribou, can you review two quick package merges for me?
<caribou> kickinz1: if they'r not overly complex, sure
<kickinz1> caribou, thanks!
<seb128> https://launchpad.net/ubuntu/+source/graphite2/1.3.3-1ubuntu1/+build/8214089 seems stucked, can somebody kill/restart it?
<seb128> it's " Started 18 hours ago " but should take some minutes to build
<cjwatson> seb128: known problem with dep-wait builds, fix in progress
<seb128> cjwatson, ok, thanks
<jgrimm> thanks caribou!
<cjwatson> seb128: I've cancelled it and will retry in a bit, but will have to wait for buildd-manager to time out as launchpad-buildd will have crashed
<seb128> ok
<cjwatson> pitti: please could you pre-emptively bump the sbuild force-badtest to 0.67.0-2ubuntu3, same reason as before (or if you have any ideas on why armhf and s390x are failing, that would be good too)?
<cjwatson> pitti: this is to fix the issue seb128 points out above, I want to be able to install that new sbuild on the s390x builders ASAP
<pitti> cjwatson: at first sight it seems my custom apparmor policy to allow mounts (for chroot-in-lxc) has stopped working; perhaps lxc 2.0 has a stricter default policy
<pitti> cjwatson: anyway, hint bumped
<mitya57> Unit193, can you test if the official example (/usr/lib/x86_64-linux-gnu/qt5/examples/widgets/desktop/systray/systray from qtbase5-examples) works for you?
<cjwatson> thanks
<Unit193> mitya57: The application icon does not, hit 'Show' and the icon appears.
<mitya57> Unit193, where do you click Show? Show icon or Show message?
<Unit193> Sorry, yes. 'Show Message'
<Unit193> Eg, critical/warning/informational icons work.
<mitya57> Well, those are not tray icons, those are notifications
<mitya57> Unit193, do you have $QT_QPA_PLATFORMTHEME set?
<mitya57> I.e. if you have appmenu-qt5 installed, it should set it
<Unit193> I do not have this set, no.
<mitya57> Ok, so D-Bus tray won't work for you :)
<mitya57> Do you have a classic systray on your panel then?
<Unit193> Yes.
<mitya57> That's quite strange â the X11 tray implementation in Qt hasn't got any significant changes recently.
<mitya57> Ok, looks like I understand what's going on.
<mitya57> It uses the upstream D-Bus systray implementation, which is broken in Qt 5.5
<mitya57> Unit193, can you try to install appmenu-qt5, and run some app with QT_QPA_PLATFORMTHEME=appmenu-qt5?
<mitya57> I suppose the issue may be fixed in Qt 5.6 branch, but for now the code in appmenu-qt5 is better than upstream code.
<mitya57> (because I wrote it :P)
<Unit193> mitya57: Installed, logged out and back in and now it is fixed.
<mitya57> Mirv, ^^^ do you think it will be possible to get http://code.qt.io/cgit/qt/qtbase.git/commit/?id=9c7f37e648024a8c http://code.qt.io/cgit/qt/qtbase.git/commit/?id=7ad930987da7bb1d http://code.qt.io/cgit/qt/qtbase.git/commit/?id=a4fac65938fdee74 in for Xenial?
<mitya57> This should make Qt's own dbustray implementation much less broken.
<caribou> rbasak : I've just reviewed the MP for moin & urlgrabber. Do you want me to proceed with accepting the merges ?
<Unit193> mitya57: Would that have been in a Qt update?
<Unit193> I don't suppose there's a way to force it to fallback to trayicon either?
<mitya57> Unit193, the patches I linked will be only in Qt 5.6.1. And there is no easy way to force it to X11, unfortunately.
<Unit193> mitya57: Bummer.  Thanks for all the help!
<mitya57> You are welcome!
<mitya57> Maybe if Mirv thinks that these patches are too big, we'll add a recommends on appmenu-qt5 or something like that.
<Mirv> mitya57: if those apply cleanly to our 5.5.1, I think they would be nice to get a better solution than appmenu-qt5. do you think Debian would accept them to their 5.5 too, so that we'd sync from there?
<Mirv> now that 5.6 is really quite clearly no-go, getting 5.5 as good as possible is the plan b
<mitya57> Mirv, yes, they should apply to 5.5. I'll commit them to Debian (will ask Lisandro first, but I'm sure he's ok with this).
<Mirv> ok, sounds good
<caribou> kickinz1: just saw one thing about your MP : shoudn't they be against ~ubuntu-server-dev/ubuntu/+source/urlgrabber:ubuntu/devel and not ~ubuntu-server-dev/ubuntu/+source/urlgrabber:debian/sid ???
<caribou> (ubuntu/devel and not debian/sid) Not sure of the process here
<kickinz1> caribou, yes but I got OOPs when doing so.
<kickinz1> caribou, maybe I did it wrong, I'll forward you the launchpad reply.
<superm1> sarnold: just wanted to double check, fwupd and fwupdate updated security checks for their MIR's are on you and tyler's list at some point still right?
<tyhicks> superm1: they are
<superm1> ok thanks
<tyhicks> superm1: we have one in from of them right now
<tyhicks> superm1: sarnold will be starting on that one today
<doko> barry, python3.5-venv still depends on python-pip-whl. is this correct?
<barry> doko: oh, thanks for reminding me.  i need to make sure that python3 -m venv still works.  but yes, it should dep on python-pip-whl
<doko> ok
<willcooke> barry, u-s-c is gone
<barry> willcooke: i saw that in today's daily and seb128 mentioned it earlier.  \
<barry> willcooke: \o/
<barry> thanks very much
<willcooke> glad to be of service.  kudos to seb128, Laney and robert_ancell (amongst others)
<doko> barry:
<doko> Trying easy from autohinter: python-pip/8.0.2-7 six/1.10.0-3 distlib/0.2.2-1 python-colorama/0.3.6-1 requests/2.9.1-3 python-urllib3/1.13.1-2 html5lib/0.999-4
<doko> start: 139+0: a-31:a-18:a-17:i-16:p-19:p-19:s-19
<doko> orig: 139+0: a-31:a-18:a-17:i-16:p-19:p-19:s-19
<doko> easy: 160+0: a-40:a-20:a-19:i-18:p-21:p-21:s-21
<doko>     * amd64: dh-virtualenv, python-tox, python-virtualenv, python3-venv, python3-virtualenv, python3.5-venv, tox, virtualenv, virtualenvwrapper
<barry> doko: it hasn't picked up tox 2.3.1-3 yet
<doko> ahh, ok
<doko> toxic
<barry> that would be a good name :)
 * doko shouldn't test build on i386 to fix 64bit issues ...
<bartolo> hi, (disclaimer I'm not sure that this is the right channel) I'm trying to build libunity on fedora I've set --prefix=some_install_path during the autogen phase but when I run make install it's trying to install some python modules under /usr http://pastebin.com/HjW1mtq0
<bartolo> do I have to set something else?
<hallyn> xnox: https://code.launchpad.net/~xnox/britney/deps-components/+merge/286511  oh, nice
<hallyn> would be really nice if we had a locally runnable tool that ppl doing merges could use :)
<hallyn> or if ppas did that check
<xnox> hallyn, it only deals at escuse level. E.g. missmatched things in release pocket already are not considered bad.
<xnox> hallyn, there is $ check-mir tool for local usage in unpacked package.
<xnox> hallyn, for PPAs, you should change the PPA settings to "use components as in Ubuntu release", instead of "use all available components"
<hallyn> rharper: ^ check-mir, the good man says
<frafu> Hi, We just released a new minor version of Onboard, the default on-screen keyboard in Ubuntu. This release is targeted at xenial. I also prepared the debianisation based on the Onboard package currently in xenial. Could anybody please have a look at it before feature freeze kicks in? Thanks in advance.
<frafu> https://bugs.launchpad.net/ubuntu/+source/onboard/+bug/1547054
<ubottu> Launchpad bug 1547054 in onboard (Ubuntu) "Request for sponsorship for new upstream release (xenial deb provided)" [Undecided,New]
<caribou> kickinz1: then I'm not too confortable with merging it as is, I'll put a note in the MPs
<cjwatson> _hc: where's etc1tool meant to come from?
<_hc> cjwatson: android-platform-development, I'm wrestling with that one now
<cjwatson> _hc: also, i386 binaries in android-sdk-meta depend on dexdump, dmtracedump, and hprof-conv, which only seem to be available on amd64
<_hc> odd
<cjwatson> _hc: those two things are your current xenial blockers
<_hc> thanks
<cjwatson> _hc: in fact, they seem to block migration to Debian testing as well, basically the same output
<_hc> yeah, we've been focused on getting this whole chunk in place, now we're circling back and checking in on all the issues
<amorphous> hello, do you know if it's possible to add a i386 lib as a dependency to a amd64 metapackage that also includes the amd64 version of the same library?
<frafu> seb128: Could you please have a look at the new upstream release of onboard, before feature freeze gets active, for it to make it into xenial? Thanks in advance.
<frafu> https://bugs.launchpad.net/ubuntu/+source/onboard/+bug/1547054
<ubottu> Launchpad bug 1547054 in onboard (Ubuntu) "Request for sponsorship for new upstream release (xenial deb provided)" [Undecided,New]
<rharper> hallyn: nice!  thanks!
<rharper> hallyn: and I suppose I could also change the apt sources in sbuild to only pull from  main
<nacc> jamespage: look at the possible demotion/sync of fop, which makes more sense: xmlto not recommending fop, or moving the recommendation to suggests? And would i move the entire (dblatex | fop) to suggests? in order to maintain that semantic (of dblatex being preferred)
<hallyn> rharper: true
<stgraber> pitti: any known problem with self-retries on autopkgtest?
<stgraber> pitti: I requested a retry of LXD a couple of hours ago and it's not showing up in the queue or anywhere
<stgraber> I'll go trigger one by hand from snakefruit now because I really want it to migrate
<seb128> barry, just saw your font email, try downgrading/upgrade freetype, that had a non trivial update yesterday
<stgraber> pitti: worked immediately when requesting from snakefruit, so I guess there's something wrong with the webapp somehow
<mterry> stgraber, I have problems too -- I get "Log in with SSO" button, but that doesn't seem to take, or doesn't rebuild it anyway
<seb128> mterry, just asking because I'm too lazy to check by myself, but does your deja-dup "install on demand" enable universe if needed?
<stgraber> mterry: yup, exact same behavior here
<mterry> seb128, aw crap no
<jdstrand> tyhicks: I think we need to get the unpec patch into ubuntu rather quickly. the ntp bug is going to be quite annoying for people
<seb128> mterry, k, because duplicity wants to go to universe according to component mismatch
<seb128> mterry, we could seed it to supported to avoid that
<mterry> seb128, yeah I think we should -- conceptually it's just as supported as before
<tyhicks> jdstrand: ack - let me finish up some things and prepare a debdiff
<mterry> seb128, I can do that
<jdstrand> tyhicks: ah, ok, even better. I could do it too if you prefer
<seb128> mterry, thanks
<tyhicks> jdstrand: I was planning on doing it today so I can do it now
<mterry> seb128, didn't even consider needing to enable universe, in case python-gi gets dropped eventually too...
<mterry> seb128, but that seems to still have plenty of rdeps
<seb128> mterry, good that I mentioned it then ;-) I think it's safe to seed them for this cycle, depending if you want to spend more time on the code or not
<mterry> seb128, seeding makes sense -- I want them to remain in main
<seb128> mterry, wfm
<carldani> Hi!
<carldani> I'm one of the upstream maintainers of flashrom, and I'd like to have a non-ancient version of flashrom in Ubuntu. Upstream has flashrom 0.9.9-rc1, and Ubuntu is still using some source snapshot shortly after on 0.9.7.
<carldani> Our debian package maintainer is currently busy, so updating the debian package in time for the import freeze unfortunately won't work out.
<jamespage> nacc, one sec - have my head in a debug
<nacc> jamespage: np, would be good to sync with you when you're free
<jamespage> nacc, fop is now listing for demotion - doko just let me know
<jamespage> it was being help by other things trying to get into main
<carldani> Is there a process of pushing current flashrom from our ppa to Ubuntu instead of relying on a debian import?
<carldani> Or am I totally in the wrong IRC channel and should ask elsewhere?
<nacc> jamespage: ah ok, good to know -- i think the sync will require one other merge, though, which i've documented in that bug
<rbasak> carldani: yes, you can ask for sponsorship directly for this kind of case.
<rbasak> carldani: it needs to land today though :-/
<doko> nacc, needs demotion first
<carldani> rbasak: ok, so whom can I aks for sponsorship?
<rbasak> carldani: you can create a bug with a reference to the source package you want uploaded and subscribe ~ubuntu-sponsors to it
<nacc> doko: right, demotion first then sync makes sense to me ... i wasn't aware of the ongoing demotion and it seemed like a few other packages would be affected by component-mismatches after demotion
<rbasak> carldani: that will place it in the sponsorship queue. However it's a bit late for sponsorship requests given today is feature freeze. Do it anyway though, the release team may allow it to be late.
<rbasak> I would look, but I'm working through a queue of sponsorship requests for my team right now.
<carldani> rbasak: our debian packager had told us he'd have the debian package ready yesterday, so I thought I could just use the automatic debian import... that's why I'm late
<carldani> rbasak: thanks for the hint, will do the sponsorship request
<dasjoe> cking: #zfsonlinux is a bit stirred up due to mjg59's tweet about Canonical breaking CDDL/GPL by shipping ZFS with xenial, either as binary modules or as source. Maybe somebody could clarify Canonical's position here
<barry> seb128: cool, let me try that, thanks!
<cking> dasjoe, http://blog.dustinkirkland.com/
<dasjoe> cking: oh right, kirkland to the rescue once again
<seb128> barry, mdeslaur replied the same on the list but pointing an actual change
<barry> seb128: i see that now.  i'll respond there, thanks
<seb128> yw!
<dasjoe> cking: I was not aware of you guys shipping zfs.ko, I assumed it would still be built at the customer's box by DKMS
<mdeslaur> barry: does it look _bad_, or just different?
<barry> mdeslaur: that's a difficult question.  it's readable, but i had it finely tuned for my desktops and it definitely looks worse now
<cking> dasjoe,  spl + zfs
<seb128> barry, mdeslaur, that's probably the same as https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=636776
<ubottu> Debian bug 636776 in libfreetype6 "libfreetype6: Line height squeezed in GNU Emacs" [Normal,Open]
<barry> seb128, mdeslaur could be.  i don't see it in emacs, but i use different fonts there
<dasjoe> cking: right, just found /lib/modules/4.4.0-4-generic/kernel/zfs/zfs/zfs.ko
<seb128> barry, that's the bug related to the commit we were reverting and stopped doing so
 * barry reads the bug more closely
<tjaalton> anyone else seeing sbuild-update creating empty temp files in /tmp, roughly two per chroot?
<tjaalton> no exactly two per chroot
<tjaalton> though this is wily.. time to upgrade I guess :)
<robert_ancell> jsalisbury, How many kernels do you have for bug 1498667? Happy to bisect if I have a list of .debs to try
<ubottu> bug 1498667 in linux (Ubuntu Xenial) "[Toshiba P50W-B00F] Touchscreen no longer working" [Medium,In progress] https://launchpad.net/bugs/1498667
<jsalisbury> robert_ancell, since v4.2-rc1 does not have the bug, we need to test some additional release candidates to find the first one that does.  They can all be downloaded from:
<jsalisbury> http://kernel.ubuntu.com/~kernel-ppa/mainline/
<jsalisbury> robert_ancell, Once we know the first bad kernel and last good kernel, we can then bisect between them.
<robert_ancell> jsalisbury, cool, I'll run through those
<jsalisbury> robert_ancell, great, thanks
<barry> mdeslaur: was there a launchpad bug related to the removal of the freetype  patch?
<mdeslaur> barry: no, I just wondered if it was still needed since I couldn't reproduce the original use-cases and it never went anywhere
<mdeslaur> barry: cleary you've found something that broke with it gone
<mdeslaur> barry: put it back?
 * mdeslaur doesn't care
<seb128> upstream report the issue maybe
<seb128> also different doesn't mean less good
<barry> if it was up to me, i'd put it back. :)
<seb128> we should probably not carry a distro change to the rendering if it's just different and not buggy in an obvious way
<xnox> barry, screenshot? or it didn't happen =)
<mdeslaur> heh
<xnox> barry, is that thing still using gtk2 by the way?
<mdeslaur> barry: you can include private stuff in those screenshots, we don't care
<Pharaoh_Atem> rbasak: I'm a bit puzzled why the php7.0 package tests are failing
<barry> i can definitely appreciate not wanting to carry a delta from upstream, so dropping the patch is "better" in that case, but does it look better or worse?  well, that's subjective of course, and to me, it does look worse, but it's not *unreadably* so
<Pharaoh_Atem> I run the pkgtest commands manually and they work
<seb128> barry, it's probably worth opening an upstream bug and see what they say
<Pharaoh_Atem> is it because not all the a2* commands have "|| true" for the return code stuff?
<barry> xnox: yes, it looks like claws depends on libgtk2.0-0
<barry> mdeslaur: yeah :)
<barry> seb128: would that be: http://freetype.org/developer.html#bug-report ?
<barry> xnox, mdeslaur i can probably sanitize some screenshots
<mdeslaur> barry: I think he meant upstream claws
<barry> mdeslaur: ah, yes
<barry> mdeslaur, seb128: i'm tempted to open a lp bug for tracking purposes, even if eventually it gets closed.
<mdeslaur> sure
<barry> (on freetype)
<Pharaoh_Atem> grr
<seb128> barry, mdeslaur, depends if it's only that program
<Pharaoh_Atem> pdebuilder makes me want to stab someone :/
<seb128> barry, also I guess nobody is ever going to read your bug on launchpad
<seb128> we don't really have a maintainer for freetype
<barry> sucks to be me :)
<barry> mdeslaur: do you happen to have a link handy to the patch that was removed?
<mdeslaur> barry: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/wily/freetype/wily/view/head:/debian/patches-freetype/revert_scalable_fonts_metric.patch
<barry> mdeslaur: thanks
<barry> mdeslaur, seb128 LP: #1547196 FTR
<ubottu> Launchpad bug 1547196 in freetype (Ubuntu) "Removal of revert_scalable_fonts_metric.patch causes ugliness in Claws-Mail" [Undecided,New] https://launchpad.net/bugs/1547196
<mdeslaur> barry: thanks
<doko> barry, talloc, tdb, ldb in the archive
<barry> doko: thanks
<nacc_> rbasak: any guidance on why `pull-lp-source -d cakephp-instaweb` is failing?
<nacc_> it seems to not be finding the source package in launchpad?
<rbasak> nacc_: looks like it doesn't exist in Xenial.
<rbasak> nacc_: https://launchpad.net/ubuntu/+source/cakephp-instaweb/+publishinghistory top entry
<ericdc> I have a embedded board (armhf) running kernel 2.6.32. I would like to use the Ubuntu Core 14.04 as my root filesystem. When booting I get the following errors "Mount failed for selinuxfs on /sys/fs/selinux:  No such file or directory", "init: plymouth-upstart-bridge main process (434) terminated with status 1". How can I get it working?
<nacc_> rbasak: ah ha! that's what i was looking for
<nacc_> ok, so can drop it from the list
<nacc_> rbasak: thanks!
<sarnold> ericdc: a kernel that ancient is unlikely to work well with a more modern userspace. You'll probably play whackamole with a dozen more of those sorts of things
<rbasak> nacc_: np
<ericdc> sarnold: Yes I know but unfortunately that is my only option. Do you think 12.04 would be better?
<sarnold> ericdc: maybe; 12.04 was on 3.2, it seems closer..
<Pharaoh_Atem> rbasak: do I need to do something to make it so I can build the php7.0 package from pbuilder? I get this error which stops the builder: http://fpaste.org/325105/58266731/
<nacc_> Pharaoh_Atem: does your env have universe?
<rbasak> Pharaoh_Atem: I use sbuild usually, which is closer to what Launchpad buildds do AIUI. sbuild needs --resolve-alternatives to build php5.6. Maybe pbuilder also needs something similar with php7.0?
<Pharaoh_Atem> I didn't know there's a different tool
<Pharaoh_Atem> I've been fighting pbuilder for an hour and a half now
 * Pharaoh_Atem hopes sbuild is as nice as mock
<Pharaoh_Atem> at this point, I'm trying to figure out what is causing the autopkgtests for php7.0 to fail
<Pharaoh_Atem> because by all rights, they should be passing
<Pharaoh_Atem> running the actions manually succeeds in my VMs
<Pharaoh_Atem> rbasak: how do I use sbuild?
<rbasak> Don't expect sbuild to be much better.
<sarnold> sbuild's just as cranky, it'sjust closer to what the bujilders do..
<sarnold> https://wiki.ubuntu.com/SimpleSbuild
<rbasak> sarnold beat me to it :)
<jamespage> nacc_, hey - looking through junit4 merge you proposed - its showing alot of merge conflicts?
<nacc_> jamespage: hrm, i only see 3 files with conflicts? changelog ones are expected (I think), as we're fastforwarding the debian versions. control is due to the variables changing, and d/p/series is because they added some patches in debian
<nacc_> sorry, i should have clarified that in the merge request
<nacc_> jamespage: do you see somethig different?
<rbasak> jamespage: LP invents MP conflicts because it thinks we'll be merging rather than rebasing, if that's what you're seeing. Effectively LP's web UI diff is useless, unfortunately :-/
<nacc_> rbasak: they are helpful to me, to make sure what i'm suggesting makes sense, but yeah
<rbasak> Oh, OK. I couldn't make sense of them :-(
<nacc_> e.g., https://code.launchpad.net/~nacc/ubuntu/+source/junit4/+git/junit4/+merge/286553
<nacc_> it *sort of* makes sense :)
<nacc_> and it matches what happens if i try to merge locally, which is a good check that the trees match
<rbasak> Hmm.
<rbasak> I think I see, yes.
<nacc_> jamespage: it might help to see the bit at https://github.com/basak/ubuntu-git-tools/blob/master/SPECIFICATION#L144
<nacc_> as to what you'd actually be doing to the usd git tree in response to accepting the merge
<Pharaoh_Atem> rbasak: I'm just wondering if I should just make a git patch and have someone test it while I try to figure out this weird stuff
<rbasak> Let me update that spec with more information for sponsors.
<rbasak> Done - note that broke line numbers
<nacc_> rbasak: yep, nice
<rbasak> jamespage: nacc_'s line is now https://github.com/basak/ubuntu-git-tools/blob/master/SPECIFICATION#L154
<cjwatson> rbasak: Makes perfect sense :-)  You can always rebase and push the results first.
<rbasak> jamespage: general information for sponsors starts at https://github.com/basak/ubuntu-git-tools/blob/master/SPECIFICATION#L144
<cjwatson> (Which is useful anyway because then merge detection will work)
<rbasak> cjwatson: what do you mean by "first"? Before sending the MP?
<cjwatson> rbasak: LP isn't "inventing" the MP conflicts, they're what git gives us when trying to merge.
<rbasak> cjwatson: sure, except that that's not exactly what we're using the MP for. We're filing a merge proposal because Launchpad doesn't do "rebase proposals" :)
<nacc_> cjwatson: right, but the process doesn't actually use merges
<cjwatson> rbasak: Well, drop "first".  I mean that if one were to rebase that branch and push the result to the source of that MP, then the conflicts would go away (but it would likely entail resolving the very same conflicts when rebasing, so I really don't see the complaint here)
<rbasak> cjwatson: I'm not sure that applies here. What we want is an "--onto" type rebase proposal.
<cjwatson> rbasak: Oh, no, I see what you mean now, you are intentionally not including the Ubuntu commits in this
<rbasak> Right
<cjwatson> I have to say I would just not do it that way.  The Ubuntu branch is a published branch and should therefore be fast-forwarding.
<cjwatson> Otherwise it's painful for people following that branch.
<cjwatson> Non-fast-forwarding branches are OK for work in progress and such, but a bad idea for long-lived published branches.
<rbasak> I would argue that when we do an Ubuntu "merge", and document the changelog as we do, then what we're doing is exactly an --onto debian/sid rebase .
<cjwatson> I can see how you get there, but it's going to be painful.
<rbasak> I suppose we could artificially make the old ubuntu/devel tip a parent of the final commit though.
<cjwatson> I would do something like that, yes.
<cjwatson> It will not only work better with LP, but it will be less confusing for misc people following the branch.
<rbasak> I'll mull over this. I do want to keep the "rebase" workflow, but we can maintain that by artificially constructing the merge commit over the top I think.
<cjwatson> The "artificially ..." bit you suggest is similar in some ways to what git-dpm does.
<rbasak> Yes, I see the similarity.
<cjwatson> I've called it "pseudo-fast-forwarding" in the past; I don't know if that terminology makes sense to anyone other than me
<rbasak> pretend-fast-forwarding maybe :)
<cjwatson> I can see why a rebase-type workflow is worthwhile, for pretty much exactly the same reasons they're worthwhile in git-dpm.
<rbasak> tbh, I don't see the benefit right now. I understand that it makes it difficult for others to follow ubuntu/devel automatically, but that doesn't bother me so much. OTOH, I see no harm in this as a solution.
<rbasak> (doens't bother me so much because we don't really have a need to do it)
<rbasak> I appreciate the suggestion though.
<cjwatson> I think it's something best solved early before it gets too baked into everyone's tools to be fixable
<rbasak> With some tooling sorted out, it would be relatively trivial.
<rbasak> Agreed - we definitely want to resolve this before writing tooling.
<rbasak> And I'm in favour right now unless I think of some reason to object.
<rbasak> (or someone else does)
<rbasak> nacc_: any opinion?
 * doko hates d-shlibs
<Pharaoh_Atem> doko: I can commiserate
<nacc_> rbasak: i think having an ubuntu/devel that can be a reasonable 'master' to follow is probably a good goal
<nacc_> rbasak: so i'd be ok with an artifical merge
<doko> rbasak, online? please see https://bugs.launchpad.net/ubuntu/+source/ruby-net-http-persistent/+bug/1546948
<ubottu> Launchpad bug 1546948 in ruby-net-http-persistent (Ubuntu) "[MIR] b-d's of bundler: ruby-molinillo, ruby-net-http-persistent" [Undecided,Incomplete]
<doko> the requesting package bundler is unowned, however anything-ruby  else is subscribed by server. would you mind to subscribe=
<doko> ?
<rbasak> Looking
<rbasak> doko: how come bundler has no team subscriber, or am I missing something?
<rbasak> And I don't immediately see what seed is causing bundler to be pulled into main.
<doko> rbasak, ENOCLUE, however how can we resolve this?
<doko> no seed, just ruby
<rbasak> (is there any easy way of doing that? http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.xenial/rdepends/bundler/bundler doesn't seem to recurse on reverse b-ds)
<rbasak> doko: we seed ruby but I didn't think we wanted to seed rails.
<rbasak> (and I don't understand how ruby would pull in rails)
 * rbasak wonders if he's going backwards
<doko> rbasak, this is not rails, but the ruby build system
<doko> to some extent we just have to support these external build systems
<doko> for python, barry even encourages this
<rbasak> For the Ruby world, our (server team) perception is that users want the interpreter in main, but get all their deps from rubygems.org directly, so no need for us to maintain them.
<rbasak> So I'd prefer to break the dependency tree where possible
<doko> rbasak, feel free to demote the others. I looked, and I think it's not possible unless you disable all tests
<rbasak> doko: OK. I think I want to understand the dependency tree a little better before I can give you an answer.
<doko> rbasak, thanks for looking. I'll read scroll back, but I'm afk now
<rbasak> OK
<slangasek> nacc_: hi, do you want to have a look over the new components-mismatches on http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed that reference php7.0, and handle the MIRs for them please?
<slangasek> nacc_: (or, if appropriate, drop the build-dependencies from php7.0)
<nacc_> slangasek: yes, i will take a look
<slangasek> nacc_: cheers :)
<nacc_> slangasek: is it just me or are many of the links on https://wiki.ubuntu.com/MainInclusionProcess dead?
<slangasek> not that I was aware of, let's see
<slangasek> which ones?
<nacc_> i guess it's jsut https://wiki.ubuntu.com/UbuntuMainInclusionRequirements
<nacc_> actually throwing an error
<nacc_> 500
<teward> who do i prod about package removals, if i've had such a request sitting for a while?  it's not in main, though, it's a Universe package...
<slangasek> nacc_: ok - that page loaded for me, so the problem is intermittent
<slangasek> teward: ~ubuntu-archive; have you subscribed them to the bug report? we may be behind on processing
<slangasek> teward: if you want to point me at it, though, I don't mind queue jumping for removals :)
<teward> slangasek: yeah i've had them subbed for a while
<teward> slangasek: it may need considered given that it's the .deb LetsEncrypt client, which is still under development I think (and I would NOT say is ready for inclusion in an LTS if it's still under active / rapid development)
 * teward grabs the bug number
<teward> though it encompasses the removal of two source packages and binaries from Xenial and a blacklist
<slangasek> ah, that kind of removal, hmm
<teward> slangasek: https://bugs.launchpad.net/ubuntu/+source/python-letsencrypt/+bug/1535101
<ubottu> Launchpad bug 1535101 in python-letsencrypt-apache (Ubuntu) "Please remove python-letsencrypt and python-letsencrypt-apache from the archive." [Wishlist,New]
<teward> slangasek: indeed.  not related to the images/spins, hence the question
<slangasek> teward: does the package have a blocker bug in Debian preventing it from reaching testing, also?
<teward> though been in there since... wow, exactly one month ago
<TheMuso> Is there an archive admin I can bribe to approve a new package for me in the new queue so I can get a MIR filed for it? a11y-profile-manager is the source package, there are a few versions, 0.1.3 is the newest.
<teward> slangasek: no, not that I can tell, but judging that it is ONLY in unstable and testing, i'm not sure if it impacts anything
<nacc_> slangasek: ha, wasn't on the vpn :)
<slangasek> teward: if it's in testing, that means Debian has not judged it unfit for release at this point; so I would prefer to see discussion about such a blacklist on ubuntu-devel first
<teward> the thought in my mind, though, is if they release 0.5.0 and it has enough changes to obsolete 0.4.0, then it's stuck in our level of being supported and dead
<teward> slangasek: ACK, i'll take it there
<teward> or just close it as "Invalid" until people start whining later, and watch the packages
<teward> which is infact what I did heh
<jamespage> rbasak, sorry - I missing something - can I just build the source package directly from the git repo?
<jamespage> all of the stuff I do in git is based around gbp so includes pristine-tar and upstream branches...
<jamespage> this appears to diff from that
<nacc_> slangasek: that page mentions allowing one MIR bug and tasks for the various packages. Does that need the full Availability/Rationale/etc for each such package? Just in a comment for each one?
<nacc_> slangasek: another question, it seems like basically the php5.6 and php7.0 deps are the same -- is that a suitable rationale package wise? Or do I need to go through each and figure it out? that is, did some packages possibly move to universe because php5 went to universe just now?
<nacc_> ah, nm, i think i figure that out
<rbasak> jamespage: yes, just build a source package from the git tree and you can pretend there is no new process. You'll need to grab the orig tarball using pull-debian-source -d <package> (for example) for a merge though, because there is no pristine-tar branch.
<kees> xnox: got a weird question for you -- why would the surprise appearance of dm-0 during upstart boot cause upstart to shut down they system?
<slangasek> nacc_: there were no packages demoted yet related to php5; so the things shown on components-mismatches now (as opposed to before I promoted php-defaults and php7.0) are new dependencies relative to php5.
<slangasek> nacc_: oh, mind you, there may be newer versions of packages in -proposed that I haven't promoted yet, oops.  So http://people.canonical.com/~ubuntu-archive/component-mismatches is fairly accurate, Phttp://people.canonical.com/~ubuntu-archive/component-mismatches-proposed has noise that I need to fix
<nacc_> slangasek: ok, thanks!
<nacc_> slangasek: ok cool, testing it now, but i think i've got a build that just drops all the deps that are not in main ... similar to what was done for php5
<nacc_> slangasek: will work on the MIR request correspondingly
<slangasek> ah, great :)
<slangasek> if you're dropping the deps not currently in main, then no MIR needed
<nacc_> ok, should i just file a bug and post a debdiff? or how will that work?
<slangasek> yes
<nacc_> ok
<nacc_> i should say all but dh-php can be dropped
<nacc_> dh-php should be promoted to main too, though
<nacc_> as it replaces dh-php5, currently in main
 * slangasek nods
<nacc_> so no MIR necessary? just make it clear in the bug that the outstanding dep is going to be promoted as well? or should I do a MIR for dh-php?
<slangasek> nacc_: I will promote dh-php and demote dh-php5, no MIR needed
<nacc_> slangasek: ok thanks
<slangasek> nacc_: basically, MIRs are only needed for new code, not for new upstream versions of existing code under a new name - *unless* you're asking for two versions to be carried in main in parallel
<slangasek> you just have to get an AA with enough context to make the swap for you
<slangasek> now, how long should it take to build pkg-php-tools?
<nacc_> slangasek: ah i see, that makes total sense
<nacc_> slangasek: i don't think it should take long, iirc
<slangasek> ok then something got stuck on the buildd
<nacc_> hrm, let me run it again now to be sure
<slangasek> nah, definitely a buildd problem
<sarnold> (note that almost no one wants two versions of something to be in main in one release at once. so have a good reason before asking for that. :)
<slangasek> it's gone from pointlessly spinning on 'building' to pointlessly spinning on 'cancelling build'
<nacc_> sarnold: fair enough :)
<nacc_> slangasek: ok :)
#ubuntu-devel 2016-02-19
<rbasak> roaksoax: do you want to upload that?
<rbasak> roaksoax: I was about to go to bed.
<slangasek> nacc_: and the php7.0-cli dependency on libqdbm14 (universe) needs to be resolved before pkg-php-tools is buildable
<nacc_> slangasek: ok, the build of php7.0 takes a while, so i'm waiting for it to finish before submitting the debdiff
<nacc_> slangasek: i'm fairly confident it is right now that it's going properly (they changed the way extenions were compiled in, so had to adjust the php5 delta)
<slangasek> nacc_: ok.  please do point me at the debdiff once you've uploaded it
<nacc_> slangasek: will do -- also, i'm finally looking at LP: #cobbler 1543820
<nacc_> gah
<nacc_> LP: #1543820
<ubottu> Launchpad bug 1543820 in jmespath.php (Ubuntu) "jmespath.php: add nocheck and stage1 build profiles" [Wishlist,New] https://launchpad.net/bugs/1543820
<slangasek> excellent
<nacc_> i understand the test: target issue
<nacc_> but i don't know how to fixup the coverage: one?
<nacc_> and test: is a dependency for all:
<nacc_> actually
<nacc_> so would i remove that dependency in the makefile and then just add a dh_override_auto_test? coverage i think won't get invoked during the build
<nacc_> slangasek: urgh, sorry, was confusing that and LP #1543817
<ubottu> Launchpad bug 1543817 in php-guzzlehttp-psr7 (Ubuntu) "php-guzzlehttp-psr7: add nocheck and stage1 build profiles" [Wishlist,Incomplete] https://launchpad.net/bugs/1543817
<nacc_> it feels like they will have the same answer, though
<nacc_> is it ok for me to change the all: target to not run tests by default? so i can override it in debian/rules? or should that work?
<nacc_> slangasek: fyi, build just finished, works w/ debdiff from LP: #1547245
<ubottu> Launchpad bug 1547245 in php7.0 (Ubuntu) "php7.0: remove dependencies that come from universe" [Undecided,New] https://launchpad.net/bugs/1547245
<slangasek> nacc_: php5-xmlrpc is in main and doesn't depend on xmlrpc-epi; is this maybe an optional dependency?
<slangasek> nacc_: interbase and imap packages were built for php5, but came from separate source packages in that version.  So this is probably ok for here and now (until we finish the main build-depends discussion)
<nacc_> slangasek: i think the xmlrpc-epi dependency is altogether new in 7.0 and the xmlrpc module (it's makefile) uses xmlrpc-epi explicitly (http://anonscm.debian.org/cgit/pkg-php/php.git/commit/?h=master-7.0&id=1ae43adc9057c3911d1ada8e3a1231d456f6f20f)
<slangasek> ok
<slangasek> nacc_: so, that's probably something that should get an MIR rather than just being dropped; but I'm ok with applying this patch now and uploading, to unblock us
<nacc_> slangasek: well, here's the really confusing part with php5
<nacc_> well, maybe a side discussion
<nacc_> php5 and php5.6 are different src pckages
<nacc_> :)
<nacc_> it leads to some weirdness and i don't know why it's that way, tbh
<nacc_> but i can do the MIR for packages that now won't exist
<nacc_> slangasek: so far that's php-xmlrpc, php-interbase and php-imap (with their corresponding 7.0 names)
<slangasek> hmm yes
<slangasek> I don't know why that is
<sarnold> which of those packages will exist when xenial is released? php5? php5.6? php7?
<nacc_> only php7
<nacc_> is the plan
<nacc_> sarnold: --^
<sarnold> nacc_: no php 5.x in xenial, even in universe?
<nacc_> sarnold: correct
<nacc_> sarnold: if you want php5 stay on 14.04 LTS
<sarnold> wow, feels ambitious :) woo. thanks.
<Pharaoh_Atem> nacc_: so we're doing the php7 move?
<Pharaoh_Atem> awesome
<Pharaoh_Atem> meanwhile, I'm about to break down and cry in the amount of effort I've expended to try to build this package in a sane fashion
<robert_ancell> jsalisbury, that dir you sent me for the kernel to test is empty
<slangasek> nacc_: btw do you know anything about the autopkgtest failures on http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#php7.0 ? it doesn't look like a false positive to me
<Pharaoh_Atem> slangasek: I'm actually trying to fix them
<Pharaoh_Atem> the weird thing is, I can run them manually (i.e., run the commands in the scripts in order) and everything is fine in my Xenial VM
<Pharaoh_Atem> however, autopkgtest is failing for whatever reason
<nacc_> slangasek: Pharaoh_Atem: i'll try and take a look
<Pharaoh_Atem> nacc_: my theory is that all the a2* commands need to be guarded to redirect their output to /dev/null and set to OR with true
<Pharaoh_Atem> but I've been having a hell of a time trying to prove that
<nacc_> Pharaoh_Atem: hrm
<Pharaoh_Atem> pbuilder and sbuild make me want to hurt people
<Pharaoh_Atem> I've never encountered a more obnoxious chroot builder tool
<Pharaoh_Atem> err, package builder tool using chroots
<sarnold> i'm suriously surprised no one's replaced them with lbuild for lxc or kbuild for kvm..
<nacc_> Pharaoh_Atem: trying it locally, will let you know
<Pharaoh_Atem> nacc_: awesome
<Pharaoh_Atem> thanks
<Pharaoh_Atem> sarnold: this is the first time I've attempted to build debian packages using pbuilder and the like in quite a while
<Pharaoh_Atem> most of the time, I just use open build service
<nacc_> slangasek: for those packages that need MIR, is the general strategy to start with basically php7.0 as the source and just strip them down to the point where they just have the bits needed for say php7.0-xmlrpc? and then that source and binary would be in universe?
<Pharaoh_Atem> nacc_: if you need my patch diff, I can send it to you
<nacc_> slangasek: do we, to enforce the break from php5 to php7 have the php7 packages break their php5 counterparts? i'm noticing that the bootstrap may not be necessary anymore (!) because the deps are versioned, e.g. php7.0-cli php7.0_7.0.3-5ubuntu1.dsc
<nacc_> err
<nacc_> php7.0-cli Breaks: php5-cli (<< 5.6.16+dfsg-4~)
<nacc_> slangasek: i *think* those exist because in debian they are coinstallable
<Pharaoh_Atem> nacc_: I'm also going through and ensuring that every test turns off stuff that could potentially conflict that was turned on by other tests
<slangasek> nacc_: MIR> the process is, you identify the build-dependency that's needed for php7.0-xmlrpc (xmlrpc-epi), you go through the checklist for that package to see what it needs in order to be in main; then you look at any dependencies /that/ package has which aren't in main and do the same
<nacc_> slangasek: ah ok, so sort of the same process, but for each of these
<nacc_> got it
<Pharaoh_Atem> sarnold: is there anything that's as simple as RH/Fedora's mock for Debian packages?
<slangasek> nacc_: regarding the breaks, if the package is policy-compliant then that's because php7.0-cli took over some file previously provided by php5-cli
<slangasek> if they're coinstallable and no bootstrap is needed, then that's peachy :)
<nacc_> slangasek: well, they are possibly now :/ frustrating given how much time i spent on it, but yeah, much easier
<nacc_> i think that means we can just start building stuff once we have the updated pkg-php-tools and php-pear
<Pharaoh_Atem> neat
<slangasek> very possible
<nacc_> although i'm not sure if they'll automatically pull in the php7 deps
<sarnold> Pharaoh_Atem: sorry, I've never heard of mock; what does it do?
<nacc_> i'll need to test that with the current archive
<slangasek> that depends how their build-depends are listed
<slangasek> anything that was on your list for "rebuild only" should pull in the php7 versions of packages, yes
<Pharaoh_Atem> sarnold: http://linuxmanpages.net/manpages/fedora21/man1/mock.1.html
<Pharaoh_Atem> it takes Source RPMs and can rebuild them for any arbitrary target
<Pharaoh_Atem> into binary packages
<Pharaoh_Atem> it can also create generic chroots that you can use for arbitrary purposes
<nacc_> slangasek: right, but i'm worried that with the coinstallable version, what's happening is that sbuild right now is installing php5-cli for phpunit and php7.0-cli for the package and possibly running under php5 ... i'm not sure
<slangasek> ah
<Pharaoh_Atem> sarnold: it's actually available in Ubuntu, too :P ( http://manpages.ubuntu.com/manpages/wily/en/man1/mock.1.html )
<sarnold> hah
<Pharaoh_Atem> the version in Ubuntu is a tad bit old, but it works
<nacc_> slangasek: does that make sense? i'm just worried that the world we're building in now is different than the one i did the builds with (and i know produced the right result)
<sarnold> Pharaoh_Atem: schroot manges the chroot bits.. sbuild uses them to build packages..
<sarnold> Pharaoh_Atem: debootstrap can populate a directory with a debian / ubuntu install
<slangasek> nacc_: well, to date the only things we're building are php-pear (done) and pkg-php-tools (dep-wait) which were the bits at the bottom of your tree. I don't have to upload no-change rebuilds for the other stuff until you confirm that's appropriate
<nacc_> slangasek: that is, i'm noticing if i tell sbuild that there is a build conflict with php5-cli, e.g., the build fails unless i'm in a staged build (which is roughly the result we want with updated php-pear and pkg-php-tools)
<nacc_> ok, i'll spend some time tmrw morning, if that's ok with you, thinking about that
<Pharaoh_Atem> sarnold: yeah, the functionality of debootstrap is sorta not necessary in RH/Fedora because it's built into Yum (RHEL; Fedora <22) and DNF (Fedora >=22)
<slangasek> nacc_: but also, if the builds *are* doing the right thing, we can do the whole bootstrap in the main archive by just double-uploading no-change rebuilds
<slangasek> sorry, I mean if they aren't doing the right thing
<nacc_> slangasek: right
<sarnold> Pharaoh_Atem: have you seen this yet? https://wiki.ubuntu.com/SimpleSbuild
<Pharaoh_Atem> yeah
<nacc_> slangasek: i'm starting to think that possibly we'll be able to just build straight through in the right order
<Pharaoh_Atem> I've been trying to set that up
<nacc_> slangasek: but that's what i'd like to confirm tmrw before we kick it off
<slangasek> nacc_: ok
<Pharaoh_Atem> sarnold: it just finished building the chroot tarball, so I think it might actually work, just maybe possibly...
<nacc_> slangasek: and pkg-php-tools should be able to go once php7.0 is updated?
<slangasek> nacc_: yes
<slangasek> nacc_: so I'll retry that build as soon as php7.0 is done, which I'm expecting to be in less than a half hour
<nacc_> slangasek: yeah it takes a while, i noticed, but that was on my laptop :)
<nacc_> slangasek: thanks for all your help!
<nacc_> i really appreiate it
<slangasek> no prob
<nacc_> slangasek: sigh, just confirmed, e.g., that php-guzzlehttp-psr7 can just be rebuilt against xenial w/o bootstrap/modification
<nacc_> slangasek: there's two weeks+ of work that can be tossed :)
<nacc_> oh well, learned a lot
<Pharaoh_Atem> nacc_: at least you enjoyed it, right?
<Pharaoh_Atem> or did you hate everything :P
<nacc_> Pharaoh_Atem: no it was good, just stressful :)
<slangasek> nacc_: interesting, is this because something changed out from underneath you with php5-cli?
<nacc_> slangasek: yeah, debian has updated both php5 and php7 past the point where there was a conflict in the build-deps
<nacc_> err, in the binary packages
 * slangasek nods
<slangasek> so, a race condition
<nacc_> e.g., when i started, php7.0-cli and php5-cli conflicted
<nacc_> now they don't :)
<nacc_> yeh
<Pharaoh_Atem> so that means a mass import for the php stack  will fix everything?
<nacc_> Pharaoh_Atem: that's what i need to check
<nacc_> Pharaoh_Atem: I *think* the debian packages right now still refer to php5 in their deps
<Pharaoh_Atem> guh
<nacc_> Pharaoh_Atem: because debian hasn't uploaded the new php-pear and pkg-php-tools
<nacc_> that's the step that will diverge for now in ubuntu
<Pharaoh_Atem> that won't be for very long, practically speaking
<nacc_> with the understanding that what we have is what debian has in their git tree(s)
<nacc_> yeah
<nacc_> so it's a very known delta to carry for hopefully a short amount of time
<Pharaoh_Atem> that's why I've been submitting fixes to php7.0 to their git tree
<nacc_> yep and those have all been sync'd to ubuntu already, afaict
<Pharaoh_Atem> I've had some testing of it done against our applications
<Pharaoh_Atem> the fpm stuff has not
<nacc_> Pharaoh_Atem: ok
<Pharaoh_Atem> ondrej didn't see my patches and only applied the newest set from last week yesterday
<nacc_> Pharaoh_Atem: you saw this, right?
<nacc_> /tmp/adt-run.qW8OfQ/build.vJ1/php7.0-7.0.3/debian/tests/mod-php: 6: /tmp/adt-run.qW8OfQ/build.vJ1/php7.0-7.0.3/debian/tests/mod-php: cannot create /var/www/html/hello.php: Directory nonexistent
<Pharaoh_Atem> no, I didn't
<Pharaoh_Atem> that's weird
<nacc_> it's in the middle of the bulid log
<nacc_> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/p/php7.0/20160217_205539@/log.gz
<nacc_> i'm not sure why fpm is exiting yet, but when you've been running the tests, were you testing the archive version of php-fpm or your pathed version?
<Pharaoh_Atem> is /var/www/html not your default path?
<Pharaoh_Atem> nacc_: archive version
<nacc_> Pharaoh_Atem: that's the archive's build
<Pharaoh_Atem> I'm extremely confused now
<nacc_> http://autopkgtest.ubuntu.com/packages/p/php7.0/xenial/amd64/
<nacc_> start there
<nacc_> then test log
<Pharaoh_Atem> ah
<Pharaoh_Atem> now I get it
<nacc_> that's what i assume you were trying to resolve (as those tests need to pass)
<Pharaoh_Atem> yes
<Pharaoh_Atem> weirdly enough
<Pharaoh_Atem> that's not a test I modified
<Pharaoh_Atem> hold on
<Pharaoh_Atem> hold the phone
<Pharaoh_Atem> I think I *might* know why
<Pharaoh_Atem> I hope I'm wrong
<Pharaoh_Atem> because otherwise this will be really dumb
<Pharaoh_Atem> nope, libapache2-mod-php7.0 depends on apache2
<Pharaoh_Atem> oh, wait
<Pharaoh_Atem> nacc_: I know what happened
<Pharaoh_Atem> libapache2-mod-php7.0 doesn't depend on apache2, only apache2-bin
<Pharaoh_Atem> the directory is created when apache2 is installed
<Pharaoh_Atem> NOT when apache2-bin is installed
 * Pharaoh_Atem groans
<Pharaoh_Atem> nacc_: so basically, I need to add apache2 as a dep to the mod-php test
<Pharaoh_Atem> nacc_: it worked for me before because apache2 was installed
<Pharaoh_Atem> but this builder environment didn't have it
<nacc_> Pharaoh_Atem: glad to help :)
<nacc_> Pharaoh_Atem: will that fix fpm too?
<Pharaoh_Atem> fpm already had apache2 as a dep, but I think the other fix I made should make things better
<Pharaoh_Atem> if you'd be so kind to test a pair of patches I'll send your way?
<nacc_> Pharaoh_Atem: sure just e-mail them to me
<Pharaoh_Atem> nacc_: they should be in your canonical inbox
<nacc_> Pharaoh_Atem: ok ,might not get to it til the am, fyi
<nacc_> Pharaoh_Atem: working on dinner at the moment :)
<Pharaoh_Atem> that's okay
<Pharaoh_Atem> hopefully it fixes those tests
<Pharaoh_Atem> if these are good, I'll send them up to Ondrej for inclusion in the master-7.0 dgit
<cpaelzer> good morning
<pitti> Good morning
<pitti> stgraber: yes, it was broken due to a proxy issue, I fixed it last night
<highvoltage> 5
<cpaelzer> we have a test failing in dep8/autopkg runs due to sse3 not being available
<cpaelzer> which makes sense as the default vm has only up to sse2
<cpaelzer> I wonder if there is a way to define a d/t/control in a way so that tests would have sse3 available or something similar
<pitti> cpaelzer: your test could detect that and just skip itself (i. e. early exit 0)
<cpaelzer> locally I confirmed that providing adt-run with "--qemu-options='-cpu qemu64,+ssse3' " it works
<pitti> but this bears the question, how is that going to work on an real system?
<cpaelzer> it is supposed to only work on real systems with >=sse3
<cpaelzer> disabling that would mean disabling all tests, so I wondered if there would be any way
<cpaelzer> of corse in the worst case one might detect and early exit, but keep the tests for those who run it local with the qemu options
<pitti> cpaelzer: if only some of the tests need ss3, then only check it there?
<cpaelzer> pitti: all of them need it
<cpaelzer> but I'd really like to check if there is really no way to get such options passed properly before disabling it
<pitti> cpaelzer: so where is "disabling that would mean disabling all tests" a problem then?
<pitti> if your debian/tests/whatever just checks /proc/cpuinfo and prints a sensible message and exits 0?
<cpaelzer> pitti: the problem would be no dep8 tests in normal CI on package upload
<pitti> if none of the tests below can run, then you aren't losing anything
<pitti> right, but that's nothing the test itself can influence
<pitti> a test doesn't have magic powers over the testbed you are running it on
<cpaelzer> pitti: ok, I'd hoped there would be a way to force the test env to have such properties - like the isolation or class flags
<cpaelzer> pitti: but thanks I really just wanted to make sure there is no easy way to get sse3 in the test env overlooked
<jamespage> cpaelzer, ok - lets just put a check in the test to skip the tests if sse if not found then
<cpaelzer> jamespage: ok
<jamespage> I'm not really around this morning - if you can't find a sponsor, I'll pickup pm today
<pitti> cpaelzer: no, this kind of feature test is way too specific
<pitti> cpaelzer: I don't have control over the -cpu flags in production, we are using scalingstack instances, not direct QEMU invocations
<cpaelzer> jamespage: ok, I'll pull the current package make the check happen test it and look around - if no one is here I'll mail you
<cpaelzer> pitti: the only thing we could control there could be via a flavor maybe
<cpaelzer> ah I see autopkgtest is a flavour already
<cpaelzer> it is probably too much, for just this test to put extra effort there
<cpaelzer> on-site aptop repair incoming - til later
<pitti> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Wily (15.10) 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-wily | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: pitti
<dholbach> good morning
<mgedmin> did anything change on archive.ubuntu.com recently?
<mgedmin> my squid-deb-proxy is reporting 503 errors for URLs like http://security.ubuntu.com/ubuntu/dists/precise-security/main/binary-amd64/Packages
<mgedmin> (and also archive.ubuntu.com)
<mgedmin> and then actual security updates fail with apt hash mismatch errors
<mgedmin> ("WARNING: The following packages cannot be authenticated")
<doko> cjwatson, could you have a look, if ghc can be built with llvm-3.8 (or -3.6) instead of 3.5?
<hallyn> doko: should pkcon be willing to install a file called com.ubuntu.terminal_0.7.170_multi.click on amd64?
<hallyn> (it says "Fatal error: Wrong architecture 'multi'")
<hallyn> I'm jus asking you since yourname is in the changelog,
<hallyn> though it looks like you just fixed the bulid, nm
<doko> hallyn, I have no idea about click ...
<hallyn> doko: yeah, sorry to bother you
<hallyn> the whole chnagelog is a lot of "rebuild" :)
<doko> pitti, nacc_: how many packages depend on swig's php support?
<flexiondotorg_> dholbach, Morning
<dholbach> hi flexiondotorg_
<doko> seb128, Laney, willcooke: fyi, https://bugs.launchpad.net/ubuntu/+source/lua-bitop/+bug/1547395
<ubottu> Launchpad bug 1547395 in luasocket (Ubuntu) "MIR: new dependencies for libquvi-scripts / libquvi" [Undecided,New]
<pitti> doko: was about 7, and none of the removed binaries had rdepends
<doko> nacc_, jamespage: fop needs a xmlgraphics-commons merge
<pitti> nacc_: can you please look at https://launchpad.net/ubuntu/+source/phpunit/5.1.3-1+ubuntu1/+build/9036792 ? segfault in dh_phpcomposer
<pitti> doko: x-c merge is already in -proposed
<pitti> l
<doko> ta
<pitti> nacc_: you have an irritating habit to add trailing space to your debian/changelog entries :)
<doko> did somebody give back pcl on amd64?
<pitti> ^ not me
<xnox> kees, depends. I have seen obscure events resulting in reversal of "boot" direction. E.g. restart or stop dbus. Whilst doesn't quite means shutdown, the only practical way to recover is reboot. dm-0... depends what's on it, what upstart-udev events are emitted, and what other things trigger on that. On Ubuntu it shouldn't cause too much havoc by default....
<pitti> xnox: not sure about the context, but "systemctl stop dbus" is a no-op under Ubuntu FYI (and thus restart doesn't work either -- I recently made that a bit more robust)
<xnox> pitti, the context was from "kees" saying many hours back -> "<kees> xnox: got a weird question for you -- why would the surprise appearance of dm-0 during upstart boot cause upstart to shut down they system?"
<Saviq> pitti, morning, do you know anything about why apport-retrace would fail with "ERROR: E:Problem executing scripts APT::Update::Post-Invoke-Success 'if /usr/bin/test -e /usr/bin/appstreamcli; then appstreamcli refresh > /dev/null; fi', E:Sub-process returned an error code"" since ~yesterday?
<pitti> nacc_: please also look at bug 1543850, you attached the wrong debdiff
<ubottu> bug 1543850 in phpunit-global-state (Ubuntu) "phpunit-global-state: add nocheck and stage1 build profiles" [Wishlist,Incomplete] https://launchpad.net/bugs/1543850
<pitti> Saviq: no; apparently appstream landed on the images/in ubuntu-desktop and now has a broken hook?
<pitti> Saviq: it probably needs another test for "am I root"
<Saviq> pitti, yeah, my apt-cacher-ng broke, too, need to allow the new file types
<pitti> Saviq: oh, I'm using acng too, I didn't yet see that
<Saviq> pitti, 403 on the .yml files
<pitti> ah, I don't have /usr/bin/appstreamcli
<Saviq> oh well, that's *a* solution
 * Saviq files bug with apport and acng
<Saviq> although, wonder, should the first one be with appstream instead
<pitti> Saviq: it's only a bug in appstream
<pitti> Saviq: it apparently installs that apt hook, and that needs fixing
<pitti> [ `id -u` = 0 ] or something
<Saviq> pitti, bug #1547428
<ubottu> bug 1547428 in appstream (Ubuntu) "Fails to update packages in apport-retrace" [Undecided,New] https://launchpad.net/bugs/1547428
<Laney> https://github.com/ximion/appstream/pull/28
 * pitti hugs Laney, thanks!
<Saviq> pitti, bug #1547431 for acng
<ubottu> bug 1547431 in apt-cacher-ng (Ubuntu) "Does not allow appstream files" [Undecided,New] https://launchpad.net/bugs/1547431
<pitti> nacc_: btw, for next  time: simpler to just add multiple tasks to one bug about the same issue ("add stage1 blabla")
 * pitti declares victory in today's sponsoring battle against nacc :)
<pitti> l
<ogra_> m
<xnox> pitti, we have lxd for s390x.
<xnox> pitti, is that because nacc fell asleep or some such?! =)
<pitti> nacc_: segfault in https://launchpad.net/ubuntu/+source/twig/1.23.1-1ubuntu2/+build/9036982 too
<cjwatson> doko: My general sense from debian-haskell@ is "haha no", and I'm certainly not going to go down a rabbit-hole on it when the experts think it's implausible to touch that.  My understanding is that GHC is going to end up vendoring LLVM. :-/
<doko> ok, at least it's now demoted
<cpaelzer> this morning we discussed here about skipping tests in openvswitch-dpdk if the environment can't provide sse3
<cpaelzer> since fixing this autppkgtest blocks another packets migration through proposed I wanted to ask if somebody would have a minute to sponsor bug #1547460
<ubottu> bug 1547460 in openvswitch-dpdk (Ubuntu) "openvswitch-switch-dpdk failing in autopkgtests" [High,Triaged] https://launchpad.net/bugs/1547460
<cpaelzer> jamespage: you are not back already are you ? ^^
<infinity> cpaelzer: So, while skipping tests when they literally can't run is reasonable, we also shouldn't find ourselves in a situation where we can't test at all in our production builds.  Have you talked to people about perhaps bumping the baseline scalingstack machine configs?  I don't think any of the underlying hardware lacks sse3, we're probably just running in -cpu=core2duo or something and masking it out.
<doko> rbasak, jamespage: now Debian is depending a lot on tomcat8 (libservlet3.1-java) instead of tomcat7 (libservlet3.0-java). I saw that seb128 changed libhsqldb1.8.0-java to libservlet3.0-java. time to move to tomcat8?
<xnox> apw, Setting up linux-image-4.4.0-6-generic (4.4.0-6.21) ...
<xnox> Running depmod.
<xnox> update-initramfs: deferring update (hook will be called later)
<xnox> cp: cannot stat â/boot/initrd.img-4.4.0-6-genericâ: No such file or directory
<xnox> Failed to copy /boot/initrd.img-4.4.0-6-generic to /initrd.img at /var/lib/dpkg/info/linux-image-4.4.0-6-generic.postinst line 745.
<xnox> dpkg: error processing package linux-image-4.4.0-6-generic (--configure):
<xnox> apw, on amd64....
<cpaelzer> infinity: yeah  talked this morning with piiti and jamespage and skipping them was what was decided
<cpaelzer> infinity: we talked about the flavour used for autopackagetest very briefly, and as soon as that might be changed the test would run as-is again without further upload needed
<cpaelzer> infinity: but we didn't consider changing the flavour an immediate task like "for today"
<xnox> $ ls -latr /initrd.img
<xnox> -rw-r--r-- 1 root root 0 Jan 31 13:21 /initrd.img
<infinity> cpaelzer: *nod*
<xnox> which is well aweful.
<xnox> apw, ^
<cpaelzer> infinity: but you are right, I guess no one would have driven that - I'll write down a note to send a mail to the mailing list about it
<infinity> xnox: Where did that root filesystem come from?
<doko> ahh, that's LP: #1539903
<ubottu> Launchpad bug 1539903 in tomcat8 (Ubuntu) "tomcat-8 in main for upcoming 16.04 LTS" [Low,Fix committed] https://launchpad.net/bugs/1539903
<xnox> infinity, that's just my xenial laptop.... fairely normal install with full disk encryption. but otherwise mostly harmless.
<apw> xnox, what sort of image is that
<infinity> xnox: We've seen this on curtin installs, IIRC, where initrd is a file instead of a symlink.
<infinity> xnox: Oh, that was just installed with ubiquity or d-i, then?
<apw> and when installed
<xnox> infinity, i did d-i, cause wanted to keep my windows 10.
 * xnox checks
<infinity> xnox: link_in_boot = yes?
<apw> infinity, i am starting to think i have to just remove these if they are the wrong type, there are just too many of them
<xnox> infinity, link_in_boot = no
<infinity> Oh, that's not link_in_boot, you said /
<xnox> $ cat media-info
<xnox> Ubuntu-Server 16.04 LTS "Xenial Xerus" - Alpha amd64 (20160125)
 * infinity wonders why he's not actually seen this failure mode yet.
<apw> infinity, i don't see how link_in_boot matters, i htink we only notice that there because curtain is making a mess in /boot and you don't notice it if you arn't link_in_boot because there is no name clash
<apw> infinity, me too
<xnox> well has ubuntu desktop now, also i noticed that it was lacking "quiet splash" -> which i had to fix manually. Do servers not default to quiet & spalsh, btw?
<infinity> xnox: Servers default to noisy, I believe.
<xnox> ok.
<apw> infinity, i assume a d-i install is simply a install linux-generic and let the normal mechanics make a mess
<infinity> apw: Quite.
<xnox> apw, i wonder if we should make kernel scripts more resiliant "this is a file, not symlink => purge" before doing anything.
<infinity> d-i would definitely never be putting a regular file there.
<apw> infinity, so this has somehow to be either an initramfs-tools or postinst issue
<xnox> cause this ended up failing to upgrade kernle, and generate apport popup
<xnox> but that's a bandaid.
<infinity> apw: Yeahp, it's going to either be initramfs-tools or linux-image.postinst
<xnox> cause we still don't know who or what is making a mess.
<apw> xnox, making the postinst resilient would be trivial i am sure, but we have at least two different mess makers out there
<apw> xnox, and i am loath to let them get away with it
<apw> xnox, i will finish what i am at, and try and do a server install in a vm and see if it goes wrong too
<apw> though of course the last milestone should have failed dismally if that was the case
<xnox> apw, infinity https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1547471
<ubottu> Launchpad bug 1547471 in linux (Ubuntu) "package linux-image-4.4.0-6-generic 4.4.0-6.21 failed to install/upgrade: subprocess installed post-installation script returned error exit status 2" [Undecided,New]
<infinity> cpaelzer: Uploaded.
<cpaelzer> infinity: thanks++, I'll check excuses and such after lunch
<infinity> tseliot: Can you verify https://bugs.launchpad.net/ubuntu/+source/fglrx-installer/+bug/1518958 so we can push those both to updates?
<ubottu> Launchpad bug 1518958 in fglrx-installer-updates (Ubuntu Trusty) "SRU Request: fglrx-installer: dkms build failures with linux-lts-wily" [High,Fix committed]
<tseliot> infinity: sure, can you approve my nvidia-361 (and -updates) in Xenial NEW, please?
<infinity> tseliot: Not tonight, it's past 3am, but we'll get there soon.
<tseliot> ok
<infinity> cpaelzer: Of course, openvswitch-dpdk is now FTBFS: http://paste.ubuntu.com/15130205/
<infinity> cpaelzer: Have fun. :P
<infinity> cpaelzer: Definitely looks like libdpdk.so is underlinkes.
<infinity> s/underlinkes/underlinked/
<infinity> cpaelzer: http://paste.ubuntu.com/15130215/ < -- You should aim to clear all that up.
<infinity> At least missing -ldl and -lm... And one or two others I can't immediately identify.
<cpaelzer> infinity: it is statically linked atm which is a bug #1546550 on its own
<ubottu> bug 1546550 in openvswitch-dpdk (Ubuntu) "openvswitch-switch-dpdk links against libdpdk statically" [Medium,Triaged] https://launchpad.net/bugs/1546550
<cpaelzer> infinity: there goes my dream that this would have been simple, I'll look into it
<doko> willcooke, seb128: what's the goal with the libvdpau / libvdpau-va-gl component mismatch? asking because I'm assing to the vdpau-video and intel-vaapi-driver MIRs
<cpaelzer> infinity: I wonder why that didn't show up in my sbuild
<infinity> cpaelzer: Which bit?  The underlinked stuff?  It probably did show up and you didn't notice.  It's not fatal.
<infinity> cpaelzer: Unless you mean a test build of openvswitch-dpdk, which I can only assume you did against the old dpdk by accident.
<cpaelzer> infinity: I wonder why that didn't show up in my sbuild openvswitch-dpdk, which is why I built against it
<cpaelzer> infinity: I guess they meet in proposed
<cpaelzer> infinity: and fail there
<cpaelzer> infinity: jamespage has already the 2.5 ready (so do I), so I'll patch&test his last 2.5 now
<infinity> cpaelzer: The bug isn't in openvswitch, though, it's in dpdk.
<willcooke> tjaalton, any thoughts on doko's query? ^
<infinity> cpaelzer: dpdk.so should be linked to all the libs it uses.
<tjaalton> doko,willcooke: no idea, one got promoted before?
<doko> tjaalton, what do you mean?
<tjaalton> doko: willcooke forwarded the question to me..
<doko> tjaalton, well libvdpau is in main since 2010 ... https://bugs.launchpad.net/ubuntu/+source/libvdpau/+bug/506788
<ubottu> Launchpad bug 506788 in libvdpau (Ubuntu) "[MIR] libvdpau" [High,Fix released]
<tjaalton> what was the question about? the other one is a separate source
<doko> tjaalton, component mismatch, see http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg  not sure we want ffmpeg in main
<tjaalton> hasn't ffmpeg replaced libav on ubuntu too?
<tjaalton> please be so
<doko> feel free to file these 30 MIRs for ffmpeg
<tjaalton> heh
<tjaalton> i thought it happened in wily
<tjaalton> guess not
<tjaalton> seb128: ^
<davmor2> tjaalton: Package: ffmpeg     Version: 7:2.8.4-1ubuntu3    Priority: optional     Section: universe/video
<doko> lamont, https://launchpadlibrarian.net/240544779/buildlog_ubuntu-xenial-amd64.isc-dhcp_4.3.3-5ubuntu6_BUILDING.txt.gz
<doko> wanting to link: LDFLAGS="-lirs-export", was in libbind-export-dev
<tjaalton> doko: what's the libva MIR?
<doko> tjaalton, there's none yet (if you click on the svg file, then it wants to open one)
<tjaalton> doko: ahh, but libvdpau wants to pull in -va-gl?
<doko> tjaalton, yes
<tjaalton> ok then
<doko> lamont, how to proceed? libirs isn't shipped by bind, and isc-dhcp has the bind subdir removed
<doko> lamont: looks like we need a correspondeing isc-dhcp 4.3.4? to be released on March 29?
<bluesabre> Laney: can you run the packageset generation script? We have make some changes to shimmer-themes (with Kubuntu's permisssion) and the package should now appear in the xubuntu packageset again
<Laney> ok
<tjaalton> doko: that's only because libvdpau-va-gl Provides: vdpau-driver?
<tjaalton> and should be fixed if libvdpau1 didn't Recommend vdpau-driver
<doko> tjaalton, but vdpau-driver-all still depends on libvdpau-va-gl1
<tjaalton> ah
<tjaalton> suggests then
<seb128> doko, tjaalton, I've no idea about ffmpeg vs libav, we should probably follow debian
<tjaalton> does that Recommend matter btw? guess not since vdpau-driver is virtual
<tjaalton> seb128: yeah, probably too late though
<seb128> :-/
<tjaalton> amazing noone noticed before :)
<doko> seb128, we don't have libav anymore
<tjaalton> good
<tjaalton> I guess we never had libav provided stuff in main, so it's fine
<seb128> tjaalton, we had in precise according to https://launchpad.net/distros/ubuntu/+source/libav
<tjaalton> seb128: ah, so it seems
<rbasak> nacc_, jamespage: looks like a new tomcat7 microrelease went into Debian yesterday but didn't make our freeze. Worth a manual sync?
<rbasak> There are new build deps, but given freeze was yesterday the release team may be OK with it.
<seb128> lamont, https://errors.ubuntu.com/problem/ff29324d627eef6e11b0e8b37e37b3f645e6ea9c seems a new issue (but lacks symbols/not very useful so)
<seb128> bdmurray, ^ do you have any idea why that retracing fails?
<tseliot> infinity: all tested
<tjaalton> doko: libvdpau fixed, hopefully
<slangasek> nacc_: fyi, started looking at <2> on https://launchpadlibrarian.net/238303205/php7-archive-admins.howtov4 ; php-zeta-base is listed as only needing a rebuild, but it fails to build with an error in phpunit, possibly because it gained a phpunit build-dep in the 1.9-2 upload?
<cpaelzer> infinity: FYI I sorted out with jamespage to get the fix to openvswitch-dpdk (that we already had in ppas) combined with my fix
<cpaelzer> infinity: the issue you pointed out is still an issue on its own and worked on in #1547517
<cpaelzer> infinity: thanks
<cpaelzer> should have written bug #1547517 to get the bot posting the right link
<ubottu> bug 1547517 in dpdk (Ubuntu) "libdpdk should link against the library it uses" [Low,Triaged] https://launchpad.net/bugs/1547517
<jamespage> cpaelzer, just testing both ovs and ovs-dpdk with a snapshot from the 2.5 branch (which is in release stabilization right now)
<jamespage> and then I'll upload
 * dholbach hugs pitti 
<jamespage> cpaelzer, ok - both uploaded  - tested fine
<lamont> seb128: Sorry, you are not a member of a group that is allowed to see the data from error reports. Please fill out this form to request access.
<lamont> seb128: and I have no idea what I'm requesting access to in order to request it... care to smack things over the head as needed?
<seb128> lamont, bdmurray can probably help there
<seb128> lamont, it's a segfault which started with the recent xenial update but the retracing fail for some reason so there is no debug symbol so not useful anyway until we get that resolved
<cpaelzer> jamespage: thanks, I'm happy that both changes go along well
 * cpaelzer touches all kind of wood to leave update_excuses now
<lamont> seb128: segfault in what?
<lamont> doko: we may just need to deliver libirs?  not sure?
<seb128> lamont, http://paste.ubuntu.com/15131566/
<lamont> but yes, I suspect that we want to at least consider getting 4.3.4 dhcp for xenial
<lamont> seb128: hrmpf... which version of bind?  /me suspects 3ubuntu1
<seb128> lamont, in fact we have a bug with a retracing it seems
<seb128> lamont, reports are from 1:9.10.3.dfsg.P2-3~build3 and 1:9.10.3.dfsg.P2-3~ubuntu1
<lamont> those are the best, yes? :(
<seb128> lamont,
<seb128>  talloc_abort_unknown_value () at ../talloc.c:417
<seb128>  talloc_chunk_from_ptr (ptr=0x7f1504003140) at ../talloc.c:436
<seb128>  _talloc_free (ptr=0x7f1504003140, location=0x7f152192e888 "../common/ldb.c:289") at ../talloc.c:1625
<seb128>  ldb_asprintf_errstring (ldb=ldb@entry=0x7f151c226010, format=format@entry=0x7f150adfe4b7 "No such Base DN: %s") at ../common/ldb.c:289
<lamont> do we hvae the named.conf files from that trace?
 * lamont needs to step away for a few, but will look when he's back online in 20 or so
<seb128> lamont, I don't think so, apport doesn't seem to have a hook to include that info
<lamont> seb128: if you can ask the submitter for it, that may help isolate things.
<lamont> afk
<seb128> k
<doko> lamont, yeah, fixing ... cyphermox told me the same
<doko> pitti, looks like the gnutls transition is blocked on systemd
<doko> ginggs, cuda doesn't migrate, missing dependency. see excuses_html
<ginggs> doko: i saw that, needs nvidia driver for ppc64el, -3 not much different to -2ubuntu1
<ginggs> doko: i was talking to tseliot about creating an nvidia-tesla-drivers package for ubuntu - neither of us have ppc64el hardware with a gpu for testing
<ginggs> doko: and we are working on cuda 7.5 packaging in debian, so hope to have that ready soon
<dobey> who is our xrandr expert these days?
<seb128> I don't think we have one
<seb128> you can try tjaalton or robert_ancell
<seb128> or maybe the mir team has people knowing about xrandr as well
<dobey> tjaalton: around? :)
<tjaalton> dobey: one foot only
<tjaalton> so be quick :)
<dobey> tjaalton: oh ok. i don't know if this would be quick. i'm wondering if there's some way to "fake" xinerama-like setup with xrandr on intel, using the VIRTUAL1 output to wrap the actual DP1-X outputs
<tjaalton> doesn't sound too quick, no :)
<tjaalton> what are you trying to do?
<tjaalton> i mean, why fake-xinerama
<dobey> tjaalton: i have a 4k display, and only way to get 60Hz is MST, and intel treats it as two completely separate monitors :-/
<tjaalton> ah
<tjaalton> yeah no experience with that, but I bet you're not the only one
<tjaalton> which cpu?
<dobey> i7 4790S
<tjaalton> haswell, might work
<tjaalton> skylake doesn't
<tjaalton> so if google doesn't help, I can dig something next week
<dobey> i guess good thing i didn't upgrade yet then
<tjaalton> same here (to 4k :)
<dobey> yeah, searching hasn't been productive so far
<dobey> i've been stuck at 30Hz for far too long
<tseliot> they implemented RRMonitors exactly for that, IIRC
<tseliot> the window manager needs to support that though, I think
<dobey> tseliot: so we need to fix compiz?
<tseliot> dobey: that, and the new X https://cgit.freedesktop.org/xorg/proto/randrproto/tree/randrproto.txt?id=randrproto-1.5.0
<dobey> tseliot: so i can't make this work until 16.04?
<tseliot> dobey: exactly
<dobey> tseliot: is compiz fixed in 16.04?
<tseliot> dobey: not yet
<dobey> tseliot: will it be?
<tseliot> dobey: maybe ask the maintainers?
<tseliot> right now the new X breaks hybrid graphics because of the new RandR, so that should be fixed
<dobey> tseliot: is there no way to use the VIRTUAL1 output in older xorg to redirect the monitors to a single display?
<tseliot> dobey: not that I know. You can still ask in #intel-gfx or in #xorg-devel
<dobey> ok
<tseliot> dobey: on a second thought, simply rebuilding gtk with RandR 1.5 support might work: https://git.gnome.org/browse/gtk+/commit/?id=e670720d196bac1cef6f88313f6514cdd8c4a0c5
<dobey> tseliot: would still need 16.04 for the new X, but hopefully that gtk+ patch will be included. i wonder if anything special will need to be done from chromium/etc though.
<tseliot> dobey: it turns out the code is already there. Support in X was missing. Maybe you can try the PPA for Xenial?
<tseliot> but again, that comes with bugs: https://bugs.launchpad.net/gtk/+bug/1547510
<ubottu> Launchpad bug 1547510 in GTK+ "display scaling doesn't work with xserver 1.18" [Medium,Confirmed]
<dobey> tseliot: well, i don't use display scaling, so i guess i'll be fine there :)
<tseliot> dobey: ok, here's the ppa https://launchpad.net/~canonical-x/+archive/ubuntu/x-staging
<dobey> tseliot: but i don't think i want to upgrade to xenial yet :)
<tseliot> fair enough
<dobey> tseliot: but i'll keep all this in mind when i do. thanks! :)
<nacc> pitti: sigh, so last night we might have realized that bootstrapping is altogether unnecessary
<nacc> pitti: meaning we can drop all these deltas
<nacc> pitti: i'll fix up my side to make sure there isn't trailing space, sorry!
<nacc> pitti: i learned about the lp tasks thing only after starting, now i'm doing that :)
<Son_Goku> nacc: did my patches help with the tests?
<nacc> rbasak: jamespage: i'll try and look at tomcat7
<nacc> slangasek: will look at php-zeta-base now
<nacc> Son_Goku: about to kick them off again now
<Son_Goku> awesome
<doko> apw, tjaalton: please see https://bugs.launchpad.net/ubuntu/+source/intel-vaapi-driver/+bug/1075780   is this something which should get promoted?
<ubottu> Launchpad bug 1075780 in intel-vaapi-driver (Ubuntu) "[MIR] intel-vaapi-driver" [Wishlist,Confirmed]
<Laney> xnox: could you send a second cfn for the dmb please?
<nacc> Son_Goku: is it just me or should your patches be numbered 48 and 49?
<nacc> Son_Goku: that is, the php7.0 src seems to have all the old php5 patches in it still?
<Son_Goku> nacc: it should cleanly apply on top of php7.0 src on master-7.0 branch
<Son_Goku> these are patches that apply to the debian git itself
<Son_Goku> they donât go into debian/patches
<Son_Goku> nacc: they apply on top of this: http://anonscm.debian.org/cgit/pkg-php/php.git/log/?h=master-7.0
<lamont> ta
<lamont> bah
<nacc> Son_Goku: oh ... that's not as helpful for me to test (and is also not what adt is testing); can you spin patches that apply on top of the src package
<Son_Goku> debian/patches stuff donât work for fixing tests
<nacc> Son_Goku: good point
<Son_Goku> nacc: an easy way to apply them is to expand your source tree, initialize with git, and then do âgit am </path/to/patches/in/order.patch>â to apply them
<Son_Goku> then repack and rebuild
<Son_Goku> nacc: I could just go ahead and send them to Ondrej anyway
<nacc> pitti: re: https://launchpad.net/ubuntu/+source/phpunit/5.1.3-1+ubuntu1/+build/9036792 -- i don't see a segfault?
<nacc> pitti: but the issue is probably the one i mentioned in the xdebug bug
<nacc> Son_Goku: ok, got it, rebuilding php7.0 now to test locally
<Son_Goku> awesome
<lamont> seb128: happily? that trace is against 9.9.5, so it's not related to my most recent mess^Wupload
<doko> seb128, Laney: if not seen ... gnome-software doesn't build because of a component mismatch
<pitti> nacc: oh, seems someone retried the test and it's working now, so apparently it happens only sometimes
<pitti> nacc: twig still has a segfault; I can retry too if you think that's useful
<nacc> pitti: testing it now here
<nacc> pitti: will let you know
<nacc> pitti: it's possible the new xdebug went in in between?
<nacc> pitti: hrm, reproduced the twig segfault, debugging it now
<doko> nacc, remove firebird from b-d's if not yet done
<pitti> php7.0 lost its firebird dep today
<nacc> doko: that's done for php7.0
<doko> ta
<Laney> doko: it has an approved MIR and was previously in main
<seb128> doko, it built before and control didn't change, appstream needs to be promoted back
<doko> I didn't demote it ...
<nacc> pitti: can you tell me why component-mismatches says php7.0 has a dep on xmlrpc-epi? we dropped it via LP #1547245 ?
<ubottu> Launchpad bug 1547245 in php7.0 (Ubuntu) "php7.0: remove dependencies that come from universe" [Undecided,Fix committed] https://launchpad.net/bugs/1547245
<seb128> doko, I guess it was not promoted, sorry, but it has a MIR approved so it can be
<Laney> https://bugs.launchpad.net/ubuntu/+source/appstream/+bug/1538293/comments/8
<ubottu> Launchpad bug 1538293 in appstream (Ubuntu) "[MIR] appstream" [Undecided,Fix released]
<pitti> nacc: supposedly the new version is still in -proposed, so it sees the one in ubuntu-release?
<pitti> seb128: an approved MIR isn't sufficient -- you need something in main to depend on it
<nacc> pitti: ah ha!
<nacc> pitti: thanks :) sorry, some obvious stuff isn't so obvious to me still :)
<pitti> seb128: otherwise it's on component-mismatches and archive admins demote it back
<seb128> pitti, right, which is what doko is pointing, gnome-software is deptwaiting on it
<seb128> but it was probably on component-mismatch for a week or so
<doko> seb128, well, I even pasted the commit message
<seb128> before gnome-software got promoted
<doko> infinity, did you demote packages this week?
<seb128> doko, right, I guess it was demoted in between
<doko> anyway, promoting
<infinity> doko: Nope.
<Laney> I don't see that it got promoted on +publishinghistory
<Laney> https://launchpad.net/ubuntu/+source/appstream/+publishinghistory
<Laney> so, not sure what happened before
<nacc> pitti: also, i *think* the php-defaults -> dh-php5 dep is a false positive. Because php-json used to be its own src package, but now is a binary package produced by php-defaults
<nacc> and we're going to drop the old src package
<seb128> doko, thanks
<seb128> doko, could you have a look to bug #1513922? gdb/python is buggy on i386, the attached patch fixes it
<ubottu> bug 1513922 in gdb (Ubuntu) "[xenial] backtrace gives python error" [High,New] https://launchpad.net/bugs/1513922
<doko> I think I should promote tomcat8 now
<nacc> pitti: finally, thank you for all your help. I really appreciate it!
<infinity> lamont: Your bind9 udebs are uninstallable (depend on debs, due to new deps that aren't udebby)
<xnox> pitti, ppc64el are all dead?
<lamont> infinity: awesome.
 * lamont adds that to the list for -4
<xnox> pitti, could you hint through juju-core? passed everywhere apart from blocked up ppc64el, and we need it for the demo today...
<lamont> Depends: ${shlibs:Depends}, ${misc:Depends}
<lamont> Package-Type: udeb
<lamont> dammit, I liked using the variables
<infinity> lamont: Yeah, it's not a bug in your package.
<infinity> lamont: Except for the part where you're linking libs that aren't udebs.
<infinity> lamont: It's not debian/control that needs fixing, it's either the other packages that need udebs, or your udeb build of your libs need to have fewer features.
<infinity>  libdns162-udeb : Depends: libgeoip1 but it is not installable
<infinity>                   Depends: libgssapi-krb5-2 but it is not installable
<infinity>                   Depends: libkrb5-3 but it is not installable
<lamont> oh
<doko> pitti, is systemd: autopkgtest for linux 4.4.0-6.21 really a regression?
<infinity> libxml2-udeb seems broken too, for some reason.  Oh, how I love feature freeze.
<smoser> is anyone else seeing apt 503 from security.ubuntu.com ?
<seb128> lamont, unsure, maybe the launchpad report is not the same, the e.u.c are no useful info, I guess we need bdmurray or somebody to tell us why the retracing is not working and get that fixed, then we get more info about the issue
<lamont> seb128: ack
<lamont> infinity: looks like I may need to reintroduce the export build/
<doko> lamont, ugh, why? how many packages need fixing?
<doko> seb128, on my list
<pitti> xnox: they will auto-cleanup/restart in an hour, but I restarted them now
<lamont> doko: I can't see needing libgeoip in d-i
<lamont> OTOH, well.
<bdmurray> seb128: I'm trying to look at it but the Error Tracker is having some issues at the moment
<nacc> pitti: i think the symfony build goes now (if you add -proposed, where the nwe version of php-proxy-manager is), but that breaks the unit tests ... i'll see if i can fix those up now
<lamont> the nice part is that libdns is the boottom of the pile, so it's just those 3
<seb128> bdmurray, hey! ok, thanks
<seb128> doko, thanks!
<bdmurray> seb128: what package was the crash about?
<seb128> bdmurray, bind9
<xnox> pitti, well, something is/was odd with them. As e.g. slowest armhf passed juju-core 4 hours ago, and it was available for testing 5 hours ago.
<bdmurray> seb128: IIRC that's missing ddebs
<pitti> xnox: hinted juju
<seb128> bdmurray, I though that missing ddebs was deprecated now that those are in launchpad?
<bdmurray> seb128: but there aren't any in LP either
<seb128> https://launchpad.net/ubuntu/+source/bind9/1:9.10.3.dfsg.P2-3~ubuntu1 lists some though
<xnox> seb128, depends. if things were copied from PPAs with bad config, there might not be any ddebs.
<pitti> doko: no, systemd for anything else than the systemd update itself is not a regression; we need to land the new systemd to fix the ppc64el test, but that's blocked on gnutls
<seb128> https://launchpad.net/ubuntu/xenial/amd64/bind9-host-dbgsym/1:9.10.3.dfsg.P2-3~ubuntu1
<pitti> doko: systmed/ppc64el has a hint, though
<seb128> xnox, bind9 is an archive upload and the launchpad build record have them
<xnox> seb128, but that package version is superseeded in -proposed.
<xnox> .... so garbage collected.
<doko> pitti, but the linux test in systemd is blocking gnutls28  ...
<pitti> doko: oh, *this* way around
<bdmurray> seb128: that's only the -proposed package version
<seb128> xnox, right, the retracings are from previous days when that was not the case
<seb128> bdmurray, well the issues are only with proposed versions
<pitti> no, that just looks flaky, it's a failure in apparmor
<cjwatson> xnox: binary GC is much much less aggressive than that.
<pitti> doko: hinted
<pitti> ok, gotta run, cu on Monday
<bdmurray> seb128: okay, I'll have a look when errors comes back
<seb128> bdmurray, thanks
<seb128> pitti, have a good w.e!
<xnox> cjwatson, ok.
<jtaylor> doko: thanks for the vim-py2 :D
<doko> jtaylor, otoh this one upstream proposed a py3 compatible package
<jtaylor> doko: you mean youcompleteme?
<doko> yes
<doko> or IcompleteYou
<jtaylor> doko: thats one of many, also I'm not using the package
<Pharaoh_Atem> nacc: so how are the tests going?
<pitti> xnox: FTR, ppc64el machines are getting serial-killed by some test in trusty:
<pitti> E: Failed to fetch http://ftpmaster.internal/ubuntu/pool/main/e/eglibc/libc-dev-bin_2.19-0ubuntu6.6_ppc64el.deb  404  Not
<pitti> +Found
<pitti> this counts as temporary failure and thus they retry
<pitti> I didn't look into that yet
<Laney> Something is going wrong with the apt update
<cjwatson> Yeah, latest version is 2.19-0ubuntu6.6
<cjwatson> Er, 6.7
<cjwatson> pitti: Do you have output from the apt update?
<nacc> Pharaoh_Atem: still building php7.0 :) it's a bit big to get to all the .debs
<Pharaoh_Atem> yeah, I know :/
<nacc> Pharaoh_Atem: will ping you as soon as they are going
<Pharaoh_Atem> nacc: awesome
<infinity> lamont: PS: This is blocking d-i, which is blocking the kernel, so ick.
<nacc> Pharaoh_Atem: kicking off the tests now
<Pharaoh_Atem> :D
<lamont> infinity: ack
<jtaylor> infinity: I hope feature freeze does not mean no glibc update anymore?
<jtaylor> is there something I can do to help?
<nacc> Pharaoh_Atem: ok, mod-php tests fixed, but fpm still fails
<nacc> Pharaoh_Atem: is it possibly due to not restarting apache2? i really don't know much about what's ahppening, but see this line:
<nacc> "To activate the new configuration, you need to run: service apache2 restart
<Pharaoh_Atem> hmm
<Pharaoh_Atem> the fpm test does have an apache2 restart call
<nacc> Pharaoh_Atem: ok
<Pharaoh_Atem> nacc: do you have the output from the fpm test?
<nacc> Pharaoh_Atem: no ... running again to get it
<Pharaoh_Atem> nacc: thank you
<infinity> jtaylor: I fully intend to break my own freeze, I got stuck at a sprint this week, so I'm delayed a tad.
<rbasak> If a conffile is renamed, is the old name supposed to still show as obsolete in "dpkg -s"? If not, then what's the mechanism dpkg uses to make it not appear there?
 * rbasak goes afk, but will see replies in the next hour or two but will be offline for the weekend after that
<teward> who was working on php7 again...?  I forget, and I probably should know by now :P
<sarnold> teward: nacc
<teward> thank you :)
<teward> nacc: ping, if you're not busy, regarding php7 and fpm
<teward> nacc: With regards to php7 and fpm, php5 had the defaults, in Debian, to listen on a UNIX socket by default; has this been evaluated as a comparison to listening on a UNIX socket, and which way is implemented in php7.0-fpm for Xenial?
<teward> depending on the answer there, I may or may not have to modify the default nginx configuration files to adapt
 * teward should have checked this before but forgot
<Pharaoh_Atem> teward: it's set to use a Unix socket now
<teward> Pharaoh_Atem: i'm looking at the package in proposed and don't see that, if you can point me at where that change was done?
<Pharaoh_Atem> with php7.0, it uses a Unix socket by default because httpd 2.4.10 and newer supports using a Unix socket through mod_proxy_fcgi
<teward> ahhh, okay
<Pharaoh_Atem> Debian 8 includes httpd 2.4.12, and Ubuntu 16.04 LTS includes a newer version
<teward> Pharaoh_Atem: do you know what path it's using for the Unix socket?  So I can update the nginx default configuration, after I check to make sure it doesn't need an FFe :P
<Pharaoh_Atem> teward: yes
 * Pharaoh_Atem wrote the new httpd php-fpm config, so he figured all this out
<Pharaoh_Atem> the path is /run/php/php@PHP_VERSION@-fpm.sock
<Pharaoh_Atem> with @PHP_VERSION@ being replaced dynamically with the correct version number (7.0 in this case)
<teward> ah, wonderful, now I know what I need to change :)  thank you and nacc for your work on it :)
<Pharaoh_Atem> no problem
<nacc> Pharaoh_Atem: thanks for helping out
<Pharaoh_Atem> no problem
<nacc> Pharaoh_Atem: still trying to figure out why fpm is failing, no logs produces that say exactly why
<Pharaoh_Atem> that's frustrating
<nacc> Pharaoh_Atem: just a non-zero exit status
<Pharaoh_Atem> O.o
<nacc> I *think* the tests are actually passing
<Pharaoh_Atem> I think they are too
<Pharaoh_Atem> because when I manually run them as normal scripts, it works correctly
<nacc> Pharaoh_Atem: hrm, if the test returns false at the end
<nacc> wont' it be RC=1?
<nacc> Pharaoh_Atem: ok, i'm trying to reproduce it manually in a schroot
<nacc> Pharaoh_Atem: couple of questions
<nacc> a2enconf php7.0-fpm
<nacc> ERROR: Conf php7.0-fpm does not exist!
<nacc> is that expected?
<nacc> also, dont' you need Depends: wget in the fpm test? (it wasn't installed by default in my schroot for instance)
<Pharaoh_Atem> hmm
<Pharaoh_Atem> it doesn't exist?
<Pharaoh_Atem> that's... weird
<nacc> hrm, i also get
<nacc> a2disconf php7.0-cgi
<nacc> ERROR: Conf php7.0-cgi does not exist!
<Pharaoh_Atem> if it's not been enabled, it should say that, I think
<nacc> ok
<Pharaoh_Atem> so... it looks like my config file is not being installed
<Pharaoh_Atem> that might be why it's not working
<nacc> php7.0-fpm: /usr/lib/tmpfiles.d/php7.0-fpm.conf
<Pharaoh_Atem> that's not the one I care about
<nacc> there's no other php7.0-fpm.conf in the archive?
<Pharaoh_Atem> there should be /etc/apache2/conf-available/php7.0-fpm.conf
<Pharaoh_Atem> the sources have a php-fpm.apache2 file
<nacc> php7.0-cgi: /etc/apache2/conf-available/php7.0-cgi.conf
<nacc> php7.0-fpm: /usr/lib/tmpfiles.d/php7.0-fpm.conf
<nacc> php7.0-fpm is busted?
<Pharaoh_Atem> I think it's not installing the apache2 conf file
<nacc> Pharaoh_Atem: it's not in the package
<Pharaoh_Atem> but it is installing the tmpfiles conf file
<nacc> Pharaoh_Atem: you should fix the fpm test to do the same checks as cgi
<nacc> would tell us if that's the case pretty easily
<Pharaoh_Atem> ah, yes
<Pharaoh_Atem> ls
<nacc> Pharaoh_Atem: and probably mod-php should be updated too :)
<Pharaoh_Atem> hmm, good point
<nacc> Pharaoh_Atem: ok, so if i manually put the src package's conf file in the right place a2enconf does work
<Pharaoh_Atem> what am I missing to make it install correctly?
<nacc> Pharaoh_Atem: not sure, but if i do that and then manually `service start php7.0-fpm`, the test works
<nacc> Pharaoh_Atem: so those two bits are what is missing right now, afaict
<Pharaoh_Atem> yeah
<Pharaoh_Atem> well, I'm also adding the file checks to the tests
<asper> hey folks. if i install xenial now. will i have to modify my apt-sources to get of the development branch, when it gets released?
<Pharaoh_Atem> no
<Pharaoh_Atem> it'll transition to release state automatically
<Pharaoh_Atem> afaik, there's no actual devel branch maintained publicly?
<asper> ok thanks. at least one good message today. :)
<kyrofa> Can anyone explain why sid has sbcl for essentially every arch (https://packages.debian.org/sid/sbcl) and xenial only has it for amd64 and i386 (http://packages.ubuntu.com/xenial/sbcl)?
<teward> kyrofa: fail to builds, it looks like
<teward> oh, um, i read the wrong line ;)
<teward> (disregard me)
<kyrofa> teward, haha
<kyrofa> I mean... the autosync should just pull them over, right?
<teward> kyrofa: i will point out that packages.ubuntu.com is not the best source of information for what is and is not available in the repositories...
<Pharaoh_Atem> teward: please don't tell me that
<sarnold> e.g. here's a powerpc package.. https://launchpad.net/ubuntu/+source/sbcl/2:1.3.0-1ubuntu1/+build/8322187
<kyrofa> teward, understood, but it reflects what I'm seeing from arm64 at least
<nacc> kyrofa: https://launchpad.net/ubuntu/+source/sbcl/
<teward> kyrofa: well, arm64 is stuck on depwait
<nacc> kyrofa: you can see underneath the current xenial version
<teward> on both the current and proposed
<nacc> the builds and as teward just said
<teward> https://launchpad.net/ubuntu/+source/sbcl/2:1.3.0-1ubuntu1
<teward> ^ that's what's in Xenial now (not proposed, which has FTBFS on all archs and depwait for arm64)
<nacc> teward: is it just me or is that depwait never going to resolve? given the older versions of sbcl wasn't built for arm64?
<nacc> Missing build dependencies: sbcl (> 1:0.9.5.50-9)
<teward> nacc: no clue, sorry, i just happened to be poking launchpad.net looking at other things on my radar, when the question came in and i started poking at that one in LP
<teward> nacc: probably won't ever resolve, though, no.
<teward> though, given the thing's in Universe, i'm not 100% concerned
<nacc> teward: sure, just wondering if that's normal
<nacc> teward: looks to be a bootstrap-y situtation
<nacc> *situation
<teward> nacc: I've never seen it, but what I focus on specifically, myself, is very narrow
<teward> so, that may be why i've never seen it :)
<nacc> heh
<teward> finally the thing accepts the bugfix only upload to fix the nginx default config issues that needed addressed due to php7.0 replacing php5 xD
<kyrofa> nacc, teward is there a way to fix that? It's blocking me at the moment
<nacc> kyrofa: is it expected for sbcl to need sbcl to build? is there a restricted build that can be done (staged build or so)?
<robert_ancell> upload.ubuntu.com down?
<robert_ancell> back again
<kyrofa> nacc, heh, I have no clue. All I know is that it's a dependency of the code I'm trying to build
<teward> robert_ancell: it looks like a delay is all
<teward> finally came though for my upload heh
<robert_ancell> teward, I was getting connection refused :(
<teward> ah
<teward> then i'm lucky ;)
<nacc> Pharaoh_Atem: hrm, i noticed this
<nacc> override_dh_apache2: for sapi in apache2 cgi; do \
<nacc> should fpm be there too?
<nacc> Pharaoh_Atem: in d/rules
<kyrofa> nacc, but indeed, that dependency seems a bit bogus
<pepee> for kernel bugs, is it better to report to ubuntu, or upstream?
<kyrofa> Then again... it's lisp :P
<sarnold> pepee: ubuntu -- a bot will mmediately mark the bug for expiration and ask you to do some testing with upstream packaged kernels (it'll include links, etc..)
<nacc> kyrofa: ifeq (,$(BOOTSTRAPLISP)) BOOTSTRAPLISP=/usr/bin/sbcl --disable-debugger --no-sysinit --no-userinit
<nacc> endif
<nacc> i think it's a real dep :/
<kyrofa> nacc, yikes
<kyrofa> nacc, I've not seen that before
<kyrofa> nacc, so it must require some sort of staged build, then
<nacc> and the later on
<nacc> ./make.sh --xc-host="$(BOOTSTRAPLISP)" --prefix=$(CURDIR)/stage1 $(FEATURES)
<nacc> yeah, it basically seems to require a lisp to already be there :)
<nacc> kyrofa: i know nothing about lisp, but that's just my reading of the package
<kyrofa> nacc, unfortunately, neither do I. I'll continue to investigate
<doko>  fixed bind9 accepted
<doko> lamont, infinity: ^^^
<pepee> sarnold, what if I submit kernel bugs manually? also, by "better" I mean, which is quicker...
<pepee> *which one... this is the bug, btw: https://bugs.launchpad.net/ubuntu/+source/linux-lts-wily/+bug/1545401  I also asked in #ubuntu-bugs, no one has replied so far
<ubottu> Launchpad bug 1545401 in linux-lts-wily (Ubuntu) ""kernel BUG at /build/linux-lts-wily-Vv6Eyd/linux-lts-wily-4.2.0/mm/memory.c:3146!"" [Undecided,New]
<sarnold> pepee: 'manually'? also, quicker for whom and for what? :) just filing an issue? or getting a fix to a few million people?
<pepee> quicker as in, the less time from "submitted" to "solved"
<sarnold> probably submitting to launchpad; it'll still take work on your end but I think it'll get to someone who can fix it faster that way
<pepee> sarnold, ah, thanks
<Unit193> infinity: ...I don't suppose any way to get a package uploaded, jump from 2.2.28 â 2.2.33 (Debian unreleased vcs) without a ffe, even if they are very minor bug fix releases? :3
<nacc> Pharaoh_Atem: any experience with phpunit?
<Pharaoh_Atem> nacc: not much
<Pharaoh_Atem> I've only really run unit tests
<Pharaoh_Atem> why?
<Pharaoh_Atem> nacc: also, in re d/rules, you're right
<Pharaoh_Atem> it should be there too
<infinity> Unit193: If it's all bugfixes, the version number is irrelevant.
<Unit193> Hoho!  I may be in luck.
<nacc> Pharaoh_Atem: cool, maybe that's the issue?
<nacc> Pharaoh_Atem: and np on phpunit, i'll learn
<Unit193> Men, it's potentially uploadable. :3
<Pharaoh_Atem> nacc: sent you new patch series to try
<Pharaoh_Atem> please try asap
<gsedej> i have issue with dependency on 16.04 daily, where should I ask (libtinfo5:i386 breaks libtinfo5 on 64b)
<nacc> Pharaoh_Atem: will do
<nacc> Pharaoh_Atem: will take time to build, etc
<nacc> pitti: for now i have had to skip those twig tests
<nacc> pitti: i've filed upstream issues for each
<Pharaoh_Atem> nacc: that's fine
<cjwatson> kyrofa,nacc: language implementations often have self-build-depends.  we can certainly bootstrap that on arm64, but it would help if somebody (Logan?) could work out why the current version is failing to build everywhere
<cjwatson> kyrofa: if you want to help unblock this, that would be a good thing to investigate.  https://launchpad.net/ubuntu/+source/sbcl/2:1.3.1-1ubuntu1
<Logan> hi
<nacc> cjwatson: yep, it makes sense
<Logan> ah yes, I was looking into the sbcl failures
<nacc> Logan: kyrofa was asking about sbcl earlier -- seems like arm64 is stuck becuase it needs sbcl to already exist?
<Logan> right, as cjwatson said, we can bootstrap
<Logan> but we first need to figure out why this minor point release I uploaded yesterday suddenly fails to build on all architectures
<Logan> well no, it was 1.2.14 to 1.3.0, so I guess that's not a minor point release
<Logan> no
<cjwatson> 1.3.0 worked, it was 1.3.1 that failed
<Logan> it was 1.3.0 to 1.3.1
<Logan> yes
<cjwatson> Logan: let me know when I'm good to run a bootstrap cycle
<cjwatson> I probably won't remember unprompted
<Logan> it was some sort of etex failure
<Logan> urgh
<Logan> cjwatson: sure thing
<Logan> I love debugging TeX issues (not)
<Logan> lemme run a test build in my Debian chroot and see if it's failing there
<Logan> I can rope in the sbcl maintainer
<nacc> slangasek: ah! i see php-zeta-base changed versions since i bootstrapped
<nacc> slangasek: testing now to figure out what's needed
<nacc> Pharaoh_Atem: cp debian/php7.0-fpm.conf debian/php7.0-fpm/etc/apache2/conf-available/
<nacc> cp: cannot stat 'debian/php7.0-fpm.conf': No such file or directory
<Pharaoh_Atem> grr
<nacc> becuase it's debain/php-fpm.conf ?
<Pharaoh_Atem> so there's something that's missing to go from debian/php-fpm.conf to debian/php7.0-fpm.conf
<Pharaoh_Atem> nacc: php-cgi's conf does the correct transformation
<Pharaoh_Atem> nacc: I think I figured it out!
<Pharaoh_Atem> nacc: sent you a new patch to add on top of the current series
<Pharaoh_Atem> please test
<nacc> Pharaoh_Atem: ok, will do
<Pharaoh_Atem> my god
<Pharaoh_Atem> this package is so convoluted
<Pharaoh_Atem> nacc: I'm hoping that I'll finally have it, and once it works, I can send all of these patches to Ondrej
<nacc> Pharaoh_Atem: still building, will let you know
<nacc> Pharaoh_Atem: right, and we'll need to file a bug to update ubuntu, i think, as sync is off now
<Pharaoh_Atem> right
<Pharaoh_Atem> but I'll be happy just to get these tests beaten into shape
<Pharaoh_Atem> then it'll be a matter of taking a look at the php5 bugs filed for fpm and seeing if they even still apply
<nacc> Pharaoh_Atem: right
<nacc> slangasek: ha, in between my bootstrap and your update, they added phpunit as a build-dep and run the tests at build tim e:)
<Pharaoh_Atem> nacc: I'm glad the php-pear circular dependency has been broken
<Pharaoh_Atem> that was annoying when upgrading php in the past
<Pharaoh_Atem> but afaik, phpunit is a new circular dependency?
<nacc> Pharaoh_Atem: well, it's confusing, but i think because php 7 and php5 are coinstallable in debian and we are syncd (as of yesterday), phpunit isn't a problem anymore
<Pharaoh_Atem> ah
<nacc> slangasek: file a MIR to promote xmlrpc-epi (and then we can reenable php7.0-xmlrpc)
<sarnold> wow, xmlrpc-epi's mail list looks a bit idle, https://sourceforge.net/p/xmlrpc-epi/mailman/xmlrpc-epi-devel/
<sarnold> one message since 2008-11-05
<nacc> sarnold: yeah, not great
<sarnold> maybe that's because it's perfect
<sarnold> but it has both 'xml' and 'rpc' in the name so I'm suspicious
<rharper> lol
<nacc> sarnold: yep, i realize it's a possible issue
<nacc> sarnold: i *think* we could also go down the path of having a distinct src package in xenial/universe for just php-xmlrpc, but then we have to keep it in sync (or should try) with php7 (it's actual source) in main
<nacc> sarnold: but that's just my current opinion
<sarnold> nacc: not ideal either, heh
<nacc> Pharaoh_Atem: tests are starting up again now
<slangasek> nacc: separate source package> or we could focus on getting the build-dep MIR problem solved ;)
<slangasek> nacc: fwiw I believe all of your bootstrap patches are still appropriate (e.g. for the case of a from-scratch bootstrap), even if not required right now for the transition.  I suggest that you forward the remainder up to Debian
<slangasek> nacc: and yeah, php-zeta-base now uses phpunit, but phpunit has rebuilt for php 7 and php-zeta-base is still failing
<nacc> slangasek: yeah, it looks to be a real issue with php-zeta-base and php7
<slangasek> so, someone needs to make sense of that
<slangasek> ok
<nacc> slangasek: i'm working on fixing it
<slangasek> ok great
<sarnold> slangasek: probably php7-xmlrpc will runtime-depend upon xmlrpc-epi if it build-depends upon it.. heh
<slangasek> sarnold: yes, but php7 build-depending on xmlrpc-epi and spitting the php7-xmlrpc binary out to universe would be A-OK
<sarnold> slangasek: oh!
<nacc> slangasek: right, that's something i meant to ask about -- i think i've seen src in main producing binaries inmain & universe
<nacc> but the build-dep would still need to be in main, right?
<slangasek> nacc: only under the current model, which we are trying to change
<nacc> slangasek: ah right
<nacc> sarnold: fyi, you're right, php7.0-xmlrpc depends on libxmlrpc-epi0
<nacc> slangasek: would that be an approach we could take for the other bin packages we have removed as well?
<slangasek> nacc: yes
<nacc> slangasek: cool! would simplify things greatly for me
<nacc> slangasek: and would make our delta smaller
<nacc> slangasek: so ... i *think* 7 of the 10 failures we see in sbuild are because we're root?
<nacc> slangasek: i'm not sure why debian doesn't see the same problem, though
<nacc> slangasek: i created a dummy user in an schroot and the tests passed
<nacc> slangasek: because root doesn't respect file permissions
<slangasek> nacc: we don't run anything in the build as root
<nacc> slangasek: ok, that's good -- so probably just my env
<nacc> slangasek: so i'm back to the original 3 issues :)
<slangasek> nacc: and I reproduced the problem here (we're talking about php-zeta-base, right?) - you are pulling your build-deps from -proposed, not just from xenial?
<nacc> slangasek: yeah, i reproduced it here too
<slangasek> ok
<nacc> slangasek: not directly related, but similar, for tomcat8 -> main (and tomcat7 in universe), now that the seed change has been merged, I don't need to do a MIR? once tomcat8 is in main, there won't be any comonent-mismatches, afaict
<slangasek> nacc: should not need to do an MIR, correct.  Do similarly need to make sure that we make it a clean swap
<nacc> slangasek: right
<nacc> slangasek: at least in that case, since we're keeping tomcat7, it's a little easier
<slangasek> nacc: and php-guzzlehttp FTBFS
#ubuntu-devel 2016-02-20
<nacc> slangasek: looking
<nacc> slangasek: which version?
<slangasek> nacc: https://launchpad.net/ubuntu/+source/php-guzzlehttp/5.3.0-1build1/+build/9039999
<nacc> slangasek: simplest thing might be to sync 6.1.1-1 from experimental, but not sure
<nacc> slangasek: sorry, i'm looking into if we can get the 5.3.0 tests to work
<nacc> Pharaoh_Atem: all tests passed!
<nacc> nicely done :)
<nacc> slangasek: --^ fyi that will fix the adt failures for php7
<nacc> slangasek: fwiw, 6.1.1-1 builds & runs tests cleanly against xenial w/o modification
<Pharaoh_Atem> nacc: Woo!
<nacc> slangasek: i'm not sure if it's worth us carrying a delta on an older version of the module, but i can do it if that's the better way given FF
<nacc> Pharaoh_Atem: you'll probably need to file a bug, as the ubuntu package now has a delta -- can you handle that and cc me? and let me know when debian publishes? we can carry the delta and then hopefully sync -- is that roughly how it should work maintenance-wise, slangasek? this is a set of changes to debian's tests that we also need to pass the adt tests for src:php7.0
<slangasek> nacc: would prefer us just taking the upstream fix; if you can file a pro-forma FFe bug against the package I'll sign off on it and sync from experimental
<Pharaoh_Atem> I don't know how to do that, but I will be submitting the patches to Ondrej
<nacc> Pharaoh_Atem: if you can file the bug, i'll deal with the rest of it, just don't want to lose track -- feel free to assign to me
<nacc> slangasek: is there anything special i need to do for the FFe (this'd be my first)? special tags, etc
<nacc> slangasek: looking at the wiki as we speak, as well
<slangasek> nacc: explain why ("because it's needed for compatibility with php7"), subscribe ubuntu-release
<slangasek> nacc: normally you want to also provide analysis of the upstream changes and justification for any risks; since we've only just missed FF and this is a sync from experimental, I'm happy to waive that requirement
<nacc> slangasek: right, that's what i was just reading
<nacc> makes sense, thanks!
<Pharaoh_Atem> slangasek: I was just going to email Ondrej with a simplified set of the patches to apply
<Pharaoh_Atem> and cc nacc about it
<nacc> Pharaoh_Atem: i think his answers were for my questions
<nacc> Pharaoh_Atem: i'd appreciate it if you could at least file the bug
<Pharaoh_Atem> where and how do I do that
<nacc> Pharaoh_Atem: launchpad
<nacc> https://bugs.launchpad.net/ubuntu/+source/php7.0
<Pharaoh_Atem> okay
<Pharaoh_Atem> is it alright if I simplify the patches for him and send it to him?
<nacc> Pharaoh_Atem: yeah, of course
<nacc> Pharaoh_Atem: i just don't want to lose track
<nacc> slangasek: LP #1547729
<ubottu> Launchpad bug 1547729 in php-guzzlehttp (Ubuntu) "please sync php-guzzlehttp 6.1.1-1 from Debian experimental" [Undecided,New] https://launchpad.net/bugs/1547729
<nacc> slangasek: still trying to figure out php-zeta-base
 * slangasek nods
<nacc> slangasek: i'm out next monday, but will get back to it first thing
<nacc> i think i've fixed up anything other than php-zeta-base you and pitti hit overnight
<slangasek> nacc: do you mind checking on the other uploads to see whether any have gotten stuck in dep-wait and require attention?
<slangasek> once we have a handle on those I can batch up the next set of rebuild uploads
<nacc> slangasek: sure -- what's the URL again (sorry not yet on the top of my head)
<slangasek> nacc: ah... https://launchpad.net/ubuntu/+source/$sourcepkgname
<slangasek> then drill down from there
<nacc> slangasek: ok, need to run out quickly, but will do that when i get back
<sarnold> nacc: it's quite handy to set up firefox keyword search for that, https://launchpad.net/ubuntu/+source/%s
<sarnold> nacc: we've got a few other useful ones noted https://wiki.canonical.com/UbuntuEngineering/Security/Tips
<slangasek> sarnold: huh, keyword searches work for you? they broke for me a while ago and I filed a bug on firefox but got no response
<sarnold> slangasek: yeah; but I use pentadactyl so it might be something they've gone to some effort to continue supporting if firefox broke them..
<nacc> sarnold: super nice! i'll have to add those
<nacc> sarnold: yeah all the urls are super handy to have at hand
<nacc> slangasek: ok, looks like all are good except the known php-zeta-{console-tools (depwait on base),base} and php-guzzlehttp
<slangasek> sarnold: turns out they work now, but last time I tried to migrate from the old-style extensions to keyword-based bookmarks they were broken. Neat, that'll save me time again, thanks :)
<slangasek> nacc: excellent!
<sarnold> slangasek: woo :)
<sarnold> yeah if these were to stop working I'd be pretty cranky
<rlaager> Is Xenial expected to ship with zfsutils-linux on the server install CD?
<sarnold> hey rlaager :) probably
<Pharaoh_Atem> nacc: so do I just call this bug "Request to sync with Debian after application of patches" or what?
<Pharaoh_Atem> nacc: I sent the email to Ondrej and cc'd you and Robie
<sarnold> rlaager: interesting, it looks like it isn't currently set to ship on the CD; more details about what goes on the images and how is at https://wiki.ubuntu.com/SeedManagement
<sarnold> rlaager: oh, of course, that's blocked on -me- finishing the security review first. jeeze. good thing it's friday afternoon.
<rlaager> sarnold: So would it need to be in the Ship or Install seed?
<sarnold> rlaager: i'm not sure which one, I thought of 'standard' or 'boot' on the first time through the introduction on that page..
<Pharaoh_Atem> nacc: I cannot assign it to you: https://bugs.launchpad.net/ubuntu/+source/php7.0/+bug/1547738
<ubottu> Launchpad bug 1547738 in php7.0 (Ubuntu) "Request: Sync with Debian to get upstream fixes for autopkgtests" [Undecided,New]
<rlaager> sarnold: I was assuming that standard is more-or-less equivalent to ubuntu-standard, and I'm not sure it needs to, or even should, be there.
<rlaager> sarnold: I suppose installer, given that the next step would be installer support?
<sarnold> rlaager: I don't know if installer support is planned for 16.04 or not; the foundations team is stretched pretty thin as it is. I know debian just grew support for it, there might be enough there worth stealing..
<rlaager> sarnold: Sure, if installer support isn't possible for 16.04, that's fine. Getting the tools on the CD is a big step in that direction, though. It would allow the by-hand installation process to be greatly simplified. Instead of having to run debootstrap and do everything by hand, it would probably be possible to use most of the standard installer.
<sarnold> rlaager: yeah, and since the image hasn't fit on a CD in ages anyway probably there aren't real space limitations to keep it out of the images
<slangasek> we are not supporting root on ZFS
<slangasek> so there's no particular benefit to having the tools on the install media; just install them afterward
<Pharaoh_Atem> nacc: if you would please assign yourself to the php7.0 bug I just made, that'd be A+
<rlaager> slangasek: Just because Ubuntu as a project isn't supporting root on ZFS doesn't mean you can't make small changes to make it easier for others (like me) who are interested in doing that.
<rlaager> The thing to remember is that the server installer (unlike the Live CD) doesn't allow us to just `apt-get install zfsutils-linux`.
<rlaager> sarnold: Good luck with the security review. I'll keep doing the best I can to build instructions for the root on ZFS case with whatever ships.
<nacc> Pharaoh_Atem: done
 * nacc -> long weekend
<Logan> kyrofa: FYI http://bugs.debian.org/815205
<ubottu> Debian bug 815205 in src:sbcl "sbcl: FTBFS due to TeX error" [Serious,Open]
<slangasek> rlaager: on the contrary; since we don't support root on ZFS, we have a definite interest in avoiding making changes that give users a false impression of its supportability
<sarnold> slangasek: he's left :/ he's still in #zfsonlinux however
<slangasek> sarnold: ah, indeed :)
<mitya57> Mirv, I pushed the qtbase dbustray patches to master branch.
<kyrofa> Logan, I appreciate your looking into that, thank you!
#ubuntu-devel 2016-02-21
<Mirv> mitya57: thanks!
<flexiondotorg_> Mirv, I can't thank you enough for sponsoring some of my stuff on a Sunday!
<flexiondotorg_> Really, thank you!
<Mirv> flexiondotorg_: what better use for free time than some Debian/Ubuntu stuff? :)
<flexiondotorg_> I really appreciate it. We got delayed getting that last of the packages prepared.
<flexiondotorg_> 3 of us have been testing all weekend.
<flexiondotorg_> Mirv, If you feeling bored sponsoring this little one would make a would of difference for us :-)
<flexiondotorg_> Mirv https://bugs.launchpad.net/ubuntu/+source/ubuntu-mate-settings/+bug/1547989
<ubottu> Launchpad bug 1547989 in ubuntu-mate-settings (Ubuntu) "ubuntu-mate-settings 16.04.2 release [debdiff attached]" [Wishlist,New]
<Mirv> done and done
<Md> I am testing the 16.04 installer, but I have noticed that my custom partman recipe now creates an extended partition instead of a primary one. has something changed?
<infinity> lamont / doko: Thanks for the bind9/d-i fixes.
<flexiondotorg_> Mirv, When our paths cross the beers are on me. Thanks!
<slangasek> pitti: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#php-file-iterator shows a missing dispatch of a test for php-codecoverage on amd64; reliability problems, or did autopkgtest.u.c decline to run it for some reason? I notice the version it lists for amd64 is different than for other archs
<slangasek> pitti: ditto for phpunit-version and phpunit 5.1.3-1+ubuntu1; not sure how either of these even got triggered for the versions in question, since those are -proposed versions (phpunit 5.1.3-1+ubuntu1 is /now/ in xenial, but wouldn't have been at the time)
<pepee> so, this bug is actually dangerous:  https://bugs.launchpad.net/ubuntu/+source/linux-lts-wily/+bug/1545401  after hitting the bug, I tried updating the system... dpkg couldn't configure the packages because the system won't kill processes
<ubottu> Launchpad bug 1545401 in linux-lts-wily (Ubuntu) ""kernel BUG at /build/linux-lts-wily-Vv6Eyd/linux-lts-wily-4.2.0/mm/memory.c:3146!"" [Undecided,New]
<pepee> so if someone doesn't know how to fix this, they will get a broken system
<pepee> I mean, how to fix dpkg/apt... not the bug itself
<asper> hi there. according to this article: http://news.softpedia.com/news/Ubuntu-16-04-LTS-to-Use-Systemd-s-Networkd-Instead-of-Ifupdown-480536.shtml (which is rather old) 16.04 will use systemd networkd. i installed 16.04 but it seems that sytemd still uses networking.unit
<asper> is this something that will be added until release or not on the agende anymore?
<asper> ok figured it out. hostapd was bringing it up.
#ubuntu-devel 2017-02-13
<cpaelzer> good morning
<pitti> xnox, slangasek: Ian reverted my commit to Debian's sysvinit to keep the package in sync (https://anonscm.debian.org/cgit/collab-maint/sysvinit.git/commit/?id=6ac609340af1), so the current zesty-proposed version brings back all the old cruft
<pitti> xnox, slangasek: can you please remove it? remove-package in chroot complains with "Unable to find the server at api.launchpad.net" for me right now
<pitti> (I'm talking to Ian how to fix this more properly)
<fossfreedom_> seb128: hi - when you have a mo' please can I ask you to review the merge request for the gnome-menu patch we discussed on Friday last.  Cheers.  https://bugs.launchpad.net/ubuntu/+source/gnome-menus/+bug/1631745
<ubottu> Launchpad bug 1631745 in gnome-menus (Ubuntu) "Ubuntu Budgie - panel crashed with SIGSEGV in g_slice_alloc()" [High,In progress]
<ilmaisin> can anyone do sru if one can find someone with upload access to sponsor it?
<jbicha> ilmaisin: yes! https://wiki.ubuntu.com/SponsorshipProcess
<cult-> xnox: do you have any planned time schedule for odb of xenial?
<xnox> cult-, no. it is not that urgent. even though it does affect your systems =/
<cult-> xnox: is there anything i can do for it?
<xnox> not really, no change uploads need to be prepared and uploaded. and one needs upload rights for that.
<cult-> you mentioned that there's paperwork too for lts?
<xnox> correct, i believe i have already filled all the boiler plate in the bug report description.
<melodie> hi
<melodie> I am using a Xenial install and being on a light system, trying to find a way to disable at-spi2. I don't find. There is no service for it so I can't use systemctl, and update-rc.d does not work anymore. If I remove the package it wants to pull off Evolution, which I need. What would be the best move? Create a service? Or ask the packager of Evolution to mark at-spi2 as optional?
<seb128> fossfreedom_, hey, yes it's on my list, glad that we converged toward a real fix and not a workaround
<fossfreedom_> :) thanks seb128
<seb128> melodie, hey, what's the issue with at-spi? you might be able to turn off some bits in the a11y u-c-c settings
<ilmaisin> xnox: did you get till's mail about the cups sru?
<ilmaisin> xnox: if you ae in hurry i can maybe help with the paperwork if someone will sponsor the update
<ilmaisin> xnox: as it got little more important as it was noticed that on some systems cups will shut down even with shared printers
<xnox> ilmaisin, cups did not affect anybody at all. It only affected systems running -proposed, which no human should be doing.
<xnox> ilmaisin, the fix is in the sru queue, and pending review by ~ubuntu-sru team, which i'm not part of
<xnox> ilmaisin, also cups sru is available from a ppa, linked on the bug reprot
<xnox> ilmaisin, also cups sru is available from a ppa, linked on the bug report
<ilmaisin> xnox: in my last message about cups shutdown i meant the bug 1598300, not the bug 1642966 that is in testing, but they are interwoven that the fix to former depends on the fix to the later one
<ubottu> bug 1598300 in cups (Ubuntu Xenial) "CUPS web interface stops responding after a while" [Undecided,Fix committed] https://launchpad.net/bugs/1598300
<ubottu> bug 1642966 in cups (Ubuntu Yakkety) "package cups-daemon 2.1.3-4 failed to install/upgrade: subprocess new pre-removal script returned error exit status 1" [High,Triaged] https://launchpad.net/bugs/1642966
<xnox> ilmaisin, sure i understand that; but the next step for it to get published in proposed channels is to have ~ubuntu-sru team review it.
<ilmaisin> xnox: ok
<tjaalton> doko: mesa 17.0.0 was released, I'll switch it to use llvm-4.0 instead of 3.9
<doko> tjaalton: for trusty as well?
<tjaalton> doko: no, just zesty
<doko> ahh, ok
<tjaalton> it'll be backported to xenial later
<tjaalton> skipped 3.9 there
<doko> just noticed that llvm 3.9 requires cmake 3.4.3 :-/
<tjaalton> and it failed to build on ppc64el on xenial
<ChrisTownsend> seb128: Hi!  So, as we discussed last week, the libertine landing needs a little help in -proposed.  Would you have time to help out with that?
<seb128> ChrisTownsend, hey, let me have a look
<ChrisTownsend> seb128: Thanks!
<zul> mterry: can you have a look at LP: #1662215 please when you get a chance should be pretty striaght forward
<ubottu> Launchpad bug 1662215 in python-weakrefmethod (Ubuntu) "[MIR] python-weakrefmethod" [Critical,New] https://launchpad.net/bugs/1662215
<rbasak> !dmb-ping
<ubottu> bdmurray, BenC, cyphermox, infinity, micahg, rbasak, sil2100: DMB ping.
<mterry> zul: on it
<zul> mterry: thanks
<hallyn> yay, another one of those updates that resets my xmodmap
<hallyn> hadn't had one in awhile so i was perplexed why tmux was acting weird
<slangasek> pitti: sysvinit/zesty-proposed removed
<pitti> slangasek: cheers
<xnox> tedg_, is cgmanager needed for systemd-ubuntu-app-launch?
<tedg_> xnox: No it is not
<tedg_> Which makes UAL a lot faster too :-)
<xnox> tedg_, you need click to launch clicks?
<tedg_> xnox: Yes, and for our click hooks in the package.
<xnox> tedg_, is the C library libubuntu-app-launch upstart only?!
<xnox> well the ubuntu-app-launch.cpp part of it?
 * xnox guess it's not quite C library but C/C++
<tedg_> xnox: Yeah, the C code is basically a wrapper on the C++ stuff so that current users don't have to switch.
<xnox> tedg_, do you support launching clicks, under systemd? and in that case shouldn't one be launching (click?!) helpers with systemd?
<tedg_> xnox: Yes, because they'll become snap helpers soon.
<tedg_> xnox: Once all the interface hooks stuff lands in snapd.
<xnox> tedg_, but i see that helpers are only launched with upstart, in libubuntu-app-launch/ubuntu-app-launch.cpp and ripping that out, appears to be breaking the ABI as well.
 * xnox pretends that return FALSE; is not good enough here.
<tedg_> xnox: Yes, that's part of what I'm doing to remove Upstart, is have helpers use the jobs objects, which take care of that.
<xnox> tedg_, right, so i can't really rip out build dep on upstart just yet, as that will break things =(
<xnox> bugger
<tedg_> xnox: Yes, we were discussing plans in #ubuntu-desktop this morning. We're gonna work to remove Upstart.
<juliank> jbicha: your packagekit merge just build successfully on amd64 :D
<juliank> it was "fun"
<juliank> Ah, I'm subscribed to PackageKit bugs because I'm a member of the PackageKit-team team
<jbicha> thanks!
<xnox> tedg_, nice.
<nacc> tarpman: would you be able to look at some of the autopkgtest failures from the openldap merge in http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#openldap ?
<tarpman> nacc: looking
<nacc> tarpman: thanks! i think libreoffice is unrelated (as the version in excuses is triggering the same failure on itself), dogtag-pki is probably also not related
<tarpman> nacc: dovecot one looks like some kind of TLS error? ssl.SSLEOFError: EOF occurred in violation of protocol (_ssl.c:720)
<nacc> tarpman: yeah
<tarpman> no idea about libaws really but also doesn't look particularly ldap related :\
<nacc> tarpman: yeah and it's odd that it is passing on a few and not on a few, i'll dig into that one
<tarpman> nacc: do you happen to know whether the testbeds have anything installed a typical sbuild chroot wouldn't? e.g. ubuntu-minimal
<nacc> tarpman: off the top of my head, sadly, no
<nacc> tarpman: fwiw, the libaws regression is unrelated, i'm pretty sure -- it's also happening for libaws itself, as well on those archs
<nacc> jgrimm: --^ FYI, openldap merge is done, but stuck in proposed while we figure out the tests
<tarpman> nacc: but they need to be fixed for openldap to migrate, related or not, right?
<nacc> tarpman: right, but the fix might not be in opendldap (e.g., i think the libaws ones needs rebuilds of specific packages)
<jgrimm> nacc, ack
<melodie> seb128 still here?
<nacc> tarpman: e.g., looking through excuses, i think all of the ada related packages are in 'regression' status for the same reason
<melodie> seb128 my issue is about having the hand on the management of services and processes, which I don't have, because systemd-ui does not provide any kind of management
<melodie> seb128 in Trusty it has been possible to disable the launch of at-spi2 and therefore a11y which is launched by dbus, using update-rc.d, but in Xenial with systemd there is no service written for this feature, so it's started for no reason as I don't  need it, and I can't remove it because it's tied to Evolution, which I do need.
<melodie> I thought maybe I could somehow tweak the behavior in apt conf as the Arch users do with the pacman.conf file for their package manager, but I found no clue about that in the man of apt or apt.conf â¦
<tarpman> nacc: ack. currently looking at dogtag-pki, but only here for a little longer
<nacc> tarpman: if I absolutely had to guess, that one is also unrelated
<nacc> tarpman: as we have very similar regressions across other source packages
<tarpman> sure, but a better chance of being within my power to do something about :)
<jbicha> melodie: what's the problem with at-spi2 running?
<melodie> jbicha resource
<melodie> jbicha I tend to eliminate any process which is of no use in my system, so I'd like to be able to manage the processes the way I feel fit
<jbicha> you could try cp /etc/xdg/autostart/at-spi-dbus-bus.desktop ~/.config/autostart/  and then add Hidden=true to that file in ~/.config/autostart
<melodie> jbicha I will try that, thank you
<jbicha> but Ubuntu intentionally does not make it easy to disable autostart files in the default install since disabling them often causes more harm than good
<melodie> should I comment "NoDisplay=true" before using the Hidden feature?
<melodie> jbicha perhaps the person who manages the package Evolution could mark at-spi2 as "recommands" and not as hard dependency?
<melodie> quitting the session and coming back to test
<sarnold> melodie: if you just want to uninstall the thing, there's a package that lets you build a package with nothing in it, that serves only to make apt happy
<sarnold> sigh
<jbicha> melodie: from what I can see, it's not a hard dependency of Evolution; it's a hard dependency of gtk3
<sarnold> melodie: if you just want to uninstall the thing, there's a package that lets you build a package with nothing in it, that serves only to make apt happy
<sarnold> sadly I still haven't figured out the name of the package
<melodie> jbicha strange
<Laney> sarnold: equivs
<melodie> jbicha because when I try to remove the package it wants to remove Evolution specifically
<sarnold> Laney: that's the one! thanks :D
<sarnold> melodie: maybe the 'equivs' package can help you
<jbicha> melodie: it probably wants to remove everything gtk3 on your system!
<melodie> jbicha I don't think so
<jbicha> the package that has that autostart is at-spi2-core: https://packages.debian.org/sid/amd64/at-spi2-core/filelist
<melodie> jbicha and?
<jbicha> never mind, it's a different related pkg that gtk3 depends on
<melodie> tried what you suggested it didn't work
<Laney> You probably want to discuss this in a support channel
<melodie> Laney it would be better if someone in the dev team could tell me if a service file would help have the hand on it
<melodie> I'm not used to write any of these service files, but if I have to to be able to manage the service I might try to give it a go
<melodie> then I could share it with other people
<Laney> XDG autostart files can be overridden in your home directory
<melodie> Laney that's what jbicha suggested but it didn't work
<melodie> http://paste.ubuntu.com/23990496/
<dobey> or by using an environment which doesn't do xdg autostart
<melodie> dobey a
<melodie> what about having a service file which allows people to manage their services the way they like it?
<jbicha> melodie: there's also systemd user services, at-spi-dbus-bus.service and at-spi-registryd.service
<melodie> jbicha in this case I try systemctl commands now
 * Laney requests that you go to a support channel for 'tweaker' discussions
#ubuntu-devel 2017-02-14
<tmartins> Hey guys, jamespage, I'm trying to start "systemctl start gnocchi-api" (Ocata Cloud Archive), and I'm seeing the following error:
<tmartins> gnocchi-api[10900]: gnocchi-api: error: unrecognized arguments: --config-file=/etc/gnocchi/gnocchi.conf --log-file=/var/log/gnocchi/gnocchi-api.log
<tmartins> Any clue?
<tmartins> I manage to run "gnocchi-update" as expected, gnocchi-statsd and gnocchi-metricd are running, gnocchi.conf looks good...
<tmartins> But gnocchi-api doesn't run...
<tmartins> I think that the "/lib/systemd/system/gnocchi-api.service" that comes wth Ubuntu is wrong...
<tmartins> I'm not sure but, looks like that gnocchi-api is a Web App, that runs under Apache2.4, don't know why its package includes systemd files, but no apache confs...   =/
<tarpman> nacc: so the deal with tomcat-pki seems to be that 'systemctl start pki-tomcatd' does nothing because systemd thinks it was already started - but it's not running because that was before it was configured
<jamespage> tmartins, hey - which Ubuntu release?  I think coreycb and zul have worked on the apache2/mod_wsgi transitions this cycle so it might be fixed for ocata
<tmartins> Ubuntu 16.04 + Ocata Cloud Archive
<tmartins> staging...
<jamespage> tmartins, a load of changes landed very late in newton which did cause some pain - gnocchi is not covered by the automated testing we do for openstack deploys so it might have got missed
<tmartins> I see...
<tmartins> I really need AutoScaling in OpenStack...
<tmartins> Looking forward to use those tools on Ubuntu, like Senlin, Ceilometer, Aodh, Gnocchi...
<tmartins> Working to put those things together
<tmartins> I'm trying rift.io but, looks very complex.
<tmartins> I'll prefer to give a try first, with OpenStack projects.
<tmartins> Thanks for your reply!
<tmartins> jamespage, I think that I got gnocchi-api to work under apache. It is definitely not a daemon to run via systemd. I used the nova-placement-api as an example...    ;-)
<jamespage> tmartins, that's a good guide - keystone, aodh and others work the same way
<jamespage> tmartins, projects are in a bit of a transitionary state atm
<cking> happyaron, hey, what's the situation with the zfs sync from debian to ubuntu?
<tjaalton> doko: mesa in proposed now wants llvm-4.0, can you handle the switch to main and demote 3.9?
<doko> tjaalton: no, not now. next week would be better (Thu & Fri afk). Did you check that everything else builds using 4.0?
<tjaalton> doko: new libclc does
<doko> tjaalton: I don't want to know the success stories ;p
<doko> tjaalton: fyi https://launchpad.net/~ubuntu-toolchain-r/+archive/ubuntu/rust/+packages  ... so newer llvm versions for trusty will be fun ...
<tjaalton> trusty is not an issue for me at least
<ginggs> cjwatson_: hi, are you still interested in #708123 by any chance?  I have an affected machine
<cult-> xnox: cool! :)
<Odd_Bloke> xnox: Is https://bugs.launchpad.net/cloud-images/+bug/1664367 something that you'd be able to look at?  I know you did the original livecd-rootfs work for s390x.
<ubottu> Launchpad bug 1664367 in livecd-rootfs (Ubuntu) "s390x squashfs image should include s390-tools" [Undecided,New]
<xnox> Odd_Bloke, yes i can look into that. All of that makes sense, as long as squashfs is not used as the basis for any container-like images.
<Odd_Bloke> xnox: *sad trombone* It's used by lxd.
<xnox> Odd_Bloke, since s390-tools is a bootloader and makes sense only on things that are booted (e.g. VMs and bare metal)
<Odd_Bloke> xnox: Well, MAAS uses the squashfs as well.
<xnox> Odd_Bloke, does amd64 squashfs has UEFI grub and grub2?
<Odd_Bloke> xnox: http://cloud-images.ubuntu.com/xenial/current/xenial-server-cloudimg-amd64.squashfs.manifest is what it has.  (i.e. no)
<Odd_Bloke> So it sounds like maybe my diagnosis of the issue is incorrect.
<Odd_Bloke> And really curtin/MAAS needs to understand that s390-tools should be installed in to s390x images?
<xnox> Odd_Bloke, i did the curtin work too.
<xnox> and it totally should install s390-tools before calling zipl (previously it was important and seeded everywhere)
<xnox> Odd_Bloke, added a comment to the bug report.
<xnox> cpaelzer, ^^^^ squashfs is a base for container images too, hence should not have a bootloader (pointlessly)
<xnox> powersj, ^^^^
<GunnarHj> chrisccoulson: Hi Chris, pepperflashplugin-nonfree has been fixed in Debian and synced to zesty. Is there any reason to backport that fix and keep update the package in Ubuntu, considering that we have adobe-flashplugin? (Discussion today at bug #1632870.)
<ubottu> bug 1632870 in pepperflashplugin-nonfree (Ubuntu) "Package is broken since Google stopped shipping Flash with Chrome 54 for Linux" [High,Fix released] https://launchpad.net/bugs/1632870
<Odd_Bloke> xnox: My guess would be that grub ends up in there when the kernel is installed.
<Odd_Bloke> xnox: Because the kernel Recommends grub.
<Unit193> GunnarHj: adobe-flashplugin is in a repo that by default is disabled, whereas this is in the primary repositories.
<GunnarHj> Unit193: True, but why is that significant? This is what we currently say in the desktop guide: https://help.ubuntu.com/stable/ubuntu-help/net-install-flash.html
<xnox> Odd_Bloke, kernel cannot know if one needs grub-efi; grub-pc; or grub-legacy
<xnox> on s390x it's only s390-tools ever, but we may or may not have /etc/zipl.conf written out for us, before kernel is installed =/
<Odd_Bloke> xnox: There's some logic around EFI in curtin.
<xnox> apw, should kernel, on s390x, recommend a bootloader? (s390-tools)
<xnox> Odd_Bloke, i shall look at curtin.
<mdeslaur> Could someone from the SRU team please process the php7.0 packages in the xenial and yakkety queues, please? We are waiting on them as security updates...
<mdeslaur> apw, bdmurray, rbasak, stgraber ^
<xnox> smoser, is there work started to support curtin for bare-metal support? e.g. for subiquity or not at all yet?
<xnox> cause curin will need to learn which network interfaces and hard drives (zfcp and dasd) are requested to be used; and run `chzdev -e` for all of those ids to activate them and make that activation persistent (by generating udev rules)
<rbasak> pho7.0> looking
<rbasak> php7.0>
<xnox> smoser, not sure if this belongs in curtin or subiquity
<mdeslaur> rbasak: thanks!
<rbasak> mdeslaur, nacc: please see https://bugs.launchpad.net/ubuntu/+source/php7.0/+bug/1658289/comments/4. This doesn't stop us from landing 7.0.15, but we should tweak the changelog. Do you want to handle the security update separately? Or do you still want this SRU in the proposed pockets?
<ubottu> Launchpad bug 1658289 in php7.0 (Ubuntu) "Regression in pdo_pgsql after SRU to php 7.0.13 (fixed upstream)" [Undecided,Triaged]
<ChrisTownsend> seb128: Hi again:)  Just wondering if you've had a chance to look at libertine in -proposed.  afaict, it's still stuck due to some other libertine packages needing to be promoted from universe to main.
<mdeslaur> rbasak: I plan on rebuild in the -security pocket once the SRU has been successful
<rbasak> mdeslaur: you mean after 7 days?
<mdeslaur> yeah
<rbasak> OK. Then I guess I can drop this entry from the changelog.
<rbasak> (and re-upload)
<mdeslaur> thanks
<rbasak> Unless nacc wants to cherry-pick the fix or something?
<seb128> ChrisTownsend, oh, sorry, got pulled into other things yesterday and then forgot, I'm going to have a look in a bit, thanks for the reminder
<rbasak> mdeslaur: I might wait for nacc to come online if that's OK.
<ChrisTownsend> seb128: Ah ok, no worries:)
<mdeslaur> I plan on pointing people to -proposed when the mail starts pouring in when I release my php5 updates
<ChrisTownsend> seb128: And thanks!
<mdeslaur> rbasak: sure, np
<cpaelzer> nacc: pitti: would be nice if you could take a look at the prepared stable postgres updates at bug 1664478
<ubottu> bug 1664478 in postgresql-9.5 (Ubuntu) "New upstream microreleases 9.3.16, 9.5.6" [Undecided,New] https://launchpad.net/bugs/1664478
<cpaelzer> nacc: pitti: especially on the "known to be flaky tests" there is experience required
<smoser> xnox, you are the only one who has touched curtin and s390
<smoser> perhaps cpaelzer has thought about it.
<xnox> NM started to fail to start in adt tests
<xnox> quite weird, and blocks a few things.
<xnox> cyphermox, do you still touch NM?
<nacc> tarpman: interesting... thanks for investigating that
<nacc> rbasak: here
<nacc> cpaelzer: will do
<nacc> cpaelzer: approved the tasks, as well
<cpaelzer> thank nacc
<nacc> tjaalton: did you see that dogtag-pki failed to build on all archs (10.3.5-7)
<tarpman> he acked bug 1664457, so I guess so
<ubottu> bug 1664457 in resteasy (Ubuntu) "dogtag-pki ftbfs with libresteasy-java 3.1.0" [Undecided,In progress] https://launchpad.net/bugs/1664457
<cyphermox> xnox: I can look
<nacc> tarpman: ah thanks!
<xnox> cyphermox, the symptoms are failing adt tests of networkmanager in zesty. And from the logs it "fails to start network-manager-wait-online" on installation =/ with not permitted in the logs.
<cyphermox> for zesty?
<cyphermox> there was a rerun which looks like it went ok: http://autopkgtest.ubuntu.com/packages/network-manager/zesty/amd64
<cyphermox> (i'm not saying this is fixed, but more "what is this mess")
<slangasek> kees, mdeslaur, infinity, stgraber: TB meeting?
<mdeslaur> slangasek: ack
<tjaalton> nacc: yes, still needs tomcat 8.0
<tjaalton> even after fixing resteasy
<nacc> tjaalton: rather than 8.5, you mean?
<tjaalton> yes
<nacc> tjaalton: ack, ok, i pinged just now in -release, will see if i can get some traction on that bug today
<nacc> rbasak: what's up with php7.0?
<zul> bdmurray: ping https://bugs.launchpad.net/ubuntu/+source/aodh/+bug/1645772
<ubottu> Launchpad bug 1645772 in ironic (Ubuntu Yakkety) "[SRU] newton stable releases" [Undecided,Incomplete]
<cjwatson_> ginggs: interested I guess, but largely lacking in time to deal with it - it'd be a good opportunity to work out how to debug grub!
<ginggs> cjwatson: if you gave me some pointers where to start, i might be able to help
<bdmurray> zul: hmm?
<zul> bdmurray: the SRU passed
<cjwatson> ginggs: best thing to do would be to figure out a way to replicate the same situation with a VM (at minimum) or disk image (ideally)
<cjwatson> ginggs: grub-fstest can be useful for the latter
<cjwatson> ginggs: then it might be possible to work on minimising the test case to a point where it can usefully be debugged
<cjwatson> I vaguely remember trying to replicate that once and giving up ...
<ginggs> cjwatson: thanks - i'll make a disk image (at least that will give me a backup - i might try to upgrade the mdraid superblock format on the real machine) and see if i can replicate in a VM
<cjwatson> I seem to remember it partly being hard because fakeraid is weird
<cjwatson> but it was years ago ...
<ginggs> i'm not using fakeraid
<ginggs> i have an mdraid raid 1 array - array created in 2009 - machine stopped booting after 14.04 -> 16.04 upgrade
<ginggs> it comes up with 'error: disk 'mduuid/blahblah...' not found. Entering rescue mode...'
<ginggs> i can get it to boot if i set root and prefix to one of the drives
<smoser> cyphermox, looking at http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
<smoser> and knowing you've fought open-iscsi tests... i think its probably best to remove them
<smoser> what do you think ?
<nacc> smoser: do you think it's worth porting the curtin stuff to open-iscsi's tests?
<smoser> nacc, how so ?
<cyphermox> smoser: I don't think removing the tests is going to achieve much, this has the benefit of actually testing open-iscsi at least a bit
<smoser> i cleaned up a *lot* of the stuff that is in that package
<smoser> but still has serious issues that i dont have solutions for
<smoser>  https://git.launchpad.net/~smoser/ubuntu/+source/open-iscsi/tree/debian/tests/README-boot-test.md?h=diglett-master
<smoser> see 'Caveats' there.
<cyphermox> smoser: they could be fixed to work better though, possibly using a different kernel?
<cyphermox> s/kernel/root-image
<nacc> smoser: as in our tgt spawning logic, etc. or is it the image manipulation that's not working?
<smoser> see caveats there.
<cyphermox> this is just failing because something craps out in the maas image paths or something
<smoser> '1' can be addressed, but takes some engineering to do it.
<cyphermox> the download of open-iscsi isn't what broke here.
<cyphermox> /tmp/autopkgtest.qCZ79u/build.C9k/open-iscsi-2.0.873+git0.3b4b4500/debian/tests/zesty.d/root-image: not a file
<smoser> well, the file isnt there because the download failed.
<smoser> becauase 404 Not found.
<smoser> the argument of "it tests open-iscsi some" is not valid when it fails 100%  of the time for unrleated reasons.
<smoser> i'm not suggesting that we should not test.
<smoser> i'm suggesting that we should disable until tests that work can be added.
<smoser> nacc, the tgt spawning isnt really a problem, as it all in a vm. we just run tgt on the default port and use it htere.
<bdmurray> zul: What happened to ironic?
<zul> bdmurray: hmm...good question ill find out
<smoser> zul still sings that song all the time bdmurray
<zul> smoser: its ironic that i was working on ironic today while listening to ironic dont you think?
<smoser> is that actually irony or is that a coincidence. i get the two confused.
<nacc> smoser: ok
<smoser> pitti, you told me once, but i lost it.
<smoser> in a test run by adt, where does one find the package that caused this run
<teward> so, any of the packaging experts mind sharing a copy of their .quiltrc?
<teward> I apparently lost mine in the upgrade so it's not handling patches right with quilt, so i need to 'redo' my .quiltrc
<sarnold> QUILT_REFRESH_ARGS="--diffstat --no-timestamps --backup -p ab"
<teward> sarnold: what about for where to put patches, QUILT_PATCHES=debian/patches?
<nacc> teward: yeah
<nacc> QUILT_NO_DIFF_INDEX=1
<sarnold> teward: funny ehnough I almost never need that. I've got this alias that I almost never need:
<nacc> QUILT_NO_DIFF_TIMESTAMPS=1
<sarnold> alias dq='export QUILT_PATCHES=debian/patches'
<nacc> heh
<teward> nacc: sarnold: thank you both.  now I have a working quilt again.
<teward> *facedesks at forgetting to back it up before nuking and reinstalling*
<teward> sarnold: have I mentioned I have a hatred of manually recreating deltas?
<teward> it's ***PAINFUL***
<sarnold> teward: yup. sometimes retyping a security fix is the only way to get the stupid thing to apply..
<teward> sarnold: well, the issue was a missing quiltrc
<teward> because if I had that I'd save myself a headache
<teward> 'cause the quilt patches wouldn't apply with a direct import from Debian -> MergeInProgress
<teward> because it didn't have everything it needed to understand them :/
<teward> sarnold: this one's more painful for nginx though
<teward> we're at 1.10.3
<teward> Debian's at 1.10.2
<teward> I have to retroactively copy in Debian's changes
<teward> and then up the packaging to 1.10.3.
<teward> ***painful***
<teward> sarnold: let's just hope this doesn't blow up in my face
<teward> after all this work...
<Unit193> sarnold: Nice spot with the new motd, that's something nasty.
<sarnold> Unit193: what's this?
<Unit193> /etc/update-motd.d/50-news, and the new dynamic motd.
<sarnold> Unit193: ah! xnox found that. :)
<Unit193> Also fun because as it stands, it's implied you can disable it in /etc/default/motd-news, but you actually can't.
<teward> i think i fubard
<teward> and uploaded to release  by accident :/
#ubuntu-devel 2017-02-15
<RAOF1> Hm. Is anyone looking at the juju-core autopkgtest failure on i386?
<teward> uhm
<tsimonq2> teward: UHM
<teward> has anyone looked at the Perl pkgtest failures?
 * tsimonq2 runs
<teward> because that's holding up nginx merge.
<teward> rbasak: sarnold: jgrimm: powersj: ^ ping because relevant to what we're all looking at recently.
<sarnold> wow that perl sure blocks a lot
<nacc> yeah
<nacc> it's pretty ugly
<teward> well it's blocking the nginx merge
<teward> and 99% of EVERYTHING
<teward> and ***NOBODY*** has looked at it?
<rbasak> slangasek: ^ do you know if someone's driving the Perl stuff please?
<teward> oh dear he's not here.
<teward> this is... kinda a critical thing.
<nacc> looking at libgnupg-interface-perl, i bet it's a change in behavior for gpg2
<nacc> gnupg2, rather
<tsimonq2> teward: Then #ubuntu-release?
<nacc> gpg: can't connect to the agent: File name too long
<sarnold> o_O
<teward> tsimonq2: ?
<tsimonq2> teward: "this is... kinda a critical thing."
<teward> tsimonq2: this is the proper channel for this discussion
<teward> slangasek may be away right now, but *someone* will have to look at it
<tsimonq2> Fair enough
<teward> esp. if we want pretty much anything to move out of proposed
 * tsimonq2 backs away
<nacc> and for devscripts, i suspect maybe also
<nacc> debsign: gpg error occurred!  Aborting
<nacc> oh other way around, that's expected, but it's succeeding instead :)
<slangasek> blocking 25 packages... that's not 99% of everything
<teward> slangasek: i overemphasized, but i'm tired
<teward> blah
<tsimonq2> ohai slangasek :)
<teward> 7 hrs rest in the past 48h :P
<slangasek> why is nginx blocked by it?  is there a perl ABI change?
<teward> slangasek: autopkgtest hangup prevents migration -> zesty from proposed
<teward> the hangup on Perl
<teward> Depends: nginx perl (not considered)
<slangasek> no, that's not autopkgtest-related
<teward> slangasek: *and* we have dynamically compiled modules that *might* depend on perl ABI changes, if there's anything.
<teward> slangasek: from what I can tell there isn't any issue, but I can't build against proposed right now
<teward> I can *try* the merge
<teward> but it'll be stuck in proposed unless someone overrides
<teward> actually, what *is* the perl changes
<slangasek> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#nginx shows that the new nginx package depends on the new perl; I'm asking why
<teward> slangasek: no clue?
<teward> slangasek: ideally it wouldn't affect anything
<teward> though, with Perl, we have 5.4.1~rc1 to 5.4.1-1, so not sure if that's an ABI change
<teward> (not sure how to check from my phone, which is how I'm IRCing right now)
<slangasek> well, this doesn't take any special release team knowledge to figure out :)  and you'll want to know what the story is, because if there's a perl ABI transition, none of its revdeps are going anywhere anytime soon
<teward> slangasek: i'm not the one who pinged you :P
<teward> I pinged rbasak who then poked.
<teward> unless Proposed was used to build nginx's perl components, of which there *are* some, it shouldn't need to stay held up
<sarnold> slangasek: btw how'd you come to the conclusion that nginx required the new perl? the .dsc doesn't mention anything perl beyond "Build-Depends: .. libperl-dev .."
<teward> sarnold: update-excuses
<slangasek> precisely
<sarnold> that's the thing though; I can't find why or where it would depend upon a new perl vs last year's perl..
<teward> ah that's why...
<teward> libnginx-mod-http-perl
<teward> which is an upstream module.
<teward> I don't think it wouldn't be able to depend upon a new perl, if the ABI hasn't changed
<teward> but if the ABI has, then all 25 pkgs are screwed until eternity
<teward> and nginx merge will be pushed off to next cycle
<slangasek> nginx-extras wants to pull in the new perl; but I don't yet see why
<teward> i'm not sure either
<teward> unless proposed somehow leaked into the build env?
<slangasek> proposed is always part of the build env
<slangasek> by design
<teward> i know why
<teward> hang on
<teward> dep: perl (>= 5.22.2-1) [x32]
<teward> Larry Wall's Practical Extraction and Report Language
<teward> dep: perl (>= 5.22.2-1+b1) [hurd-i386]
<teward> dep: perl (>= 5.24.1-1) [not hurd-i386, x32]
<teward> oops WOT post.
<teward> slangasek: ^ Debian version string changes, apparently, but that shouldn't have been reflected in the one in proposed
<slangasek> teward: how exactly is this holding up the nginx merge?
<teward> slangasek: well, if I merge from Debian, it *wants* the new version in the deps
<teward> and will dep fail otherwise
<teward> if I downgrade the deps, that's just adding to the delta
<slangasek> there is already a version of nginx in -proposed that wants it
<teward> slangasek: and i'm not sure *why*
<teward> because that *packaging* hasn't changed since the last Zesty upload, which was a security fix IIRC
<slangasek> ok, but why does any of this prevent you from doing the merge and uploading it to -proposed?
<teward> slangasek: i'm not concerned about UPLOADING to proposed
<teward> I'm concerned about it getting into the repo before FF
<slangasek> that's not how it works
 * teward sighs
<teward> then i need sleep
<teward> because my brain's not working
<teward> (and that's probably the core issue)
<slangasek> a) -proposed is part of "the repo" b) packages that are uploaded before FF will be shepherded into zesty
<teward> slangasek: see nobody told me that part
<teward> ever
<teward> rbasak: ^ should've :P
<slangasek> ok. So I suspect what's going on is an adverse interaction with dh_perl, which may not be constructing the right dependency (5.24.1~ vs. 5.24.1)
<slangasek> hmmm except it specifically lists 5.24.1-1
<teward> slangasek: which it *shouldn't*, unless something odd happened.  I can forcibly change the Perl version for the merge, if necessary.
<teward> s/forcibly/probably forcibly/
<slangasek> no, that's not necessary at all
 * infinity scans backscroll a bit.
<slangasek> I'm only trying to understand if there's a toolchain bug here that we need to fix
 * teward yawns, and goes to get another venti latte with an extra shot of espresso
<infinity> FWIW, the gnupg2 "file name too long" failures should only be happening in containers, and it's a known issue we can pass for.
<slangasek> but I think the right answer is that you should ignore this, do whatever nginx merge is appropriate for 17.04, and let the perl transition shake itself our
<slangasek> out
<nacc> infinity: ok, good to know, i think that's at least one perl 'regression' then
<teward> slangasek: OK, i'm sending a note to the Server list for a call for testing, I have the merge already built in the PPA so I know it builds with non-proposed, and is decent enough to iron out upgrade/install failure cases, of wich more will be fixed if they crop up
<teward> i'll upload tomorrow if nothing major blows up in *my* tests.
<teward> which are queued to autorun on containers in about 6 hours.
<infinity> nacc: devscripts looks like the test keyring was made with gpg1, and the testbed has gpg2, so the autoupgrade of the keyring blows up the expected output.  Easy fix.
<nacc> infinity: ack, seems right
<infinity> libembperl-perl looks like a legit failure someone should drill down into.
<infinity> And that's the whole list.
<infinity> So, gnupg-in-container things we can skip, devscripts should get a testsuite fix, libembperl-perl needs a closer look.
<infinity> That doesn't seem terribly sky-is-falling, rant-inducing emergency OMG.
<tsimonq2> infinity: And that's what happens when sleep deprivation is a thing.
<teward> ^
<teward> bed time now for me heh
<teward> good night.
<tsimonq2> teward: Night, sleep well. :)
<sarnold> six minutes after a new coffee? :)
<slangasek> and gnupg-in-container thing can be skipped by explicitly declaring the test not-for-container
<slangasek> (which is not how it's spelled, but anyway)
<infinity> slangasek: Maaaaybe, but I'd rather tempfail them in hints for now on container arches and look at if we can fix the infra problem that causes it.
<infinity> slangasek: It *is* fundamentally a bug, just one that doesn't matter to most people in practice.
<infinity> Not super picky on that, though.  And it'll "go away" when we use VMs on all arches.
<slangasek> confirmed that dh_perl is outputting 5.24.1-1 as minver
<slangasek> for the perl package
<infinity> That's not wrong.
<slangasek> sure it is
<slangasek> -1 is wrong
<infinity> Well, it might be wrong to include the Debian revision, but this *is* technically a new upstream version.
<slangasek> and not using ~ is arbitrary
<slangasek> (and wrong in this case)
<infinity> If it was just 5.24.1 the migration would still be held up.
<slangasek> dh_perl is encoding assumptions about the versioning of the perl package which the perl maintainers are not consistent with
<infinity> Which would be correct, IMO.
<slangasek> held up how?
<infinity> The current version in release is an older upstream version.
<slangasek> ah, you mean if it was 5.24.1 instead of 5.24.1-1 - yes
<infinity> So, I agree that having the Debian revision there isn't right, but it's also not the cause of the migration block.
<slangasek> but it's still encoding an arbitrary lower bound with no upper bound
<slangasek> which appears to be nonsense
<Unit193> He never answered my question as to why he thinks it needs to be in base-files. :/
<cpaelzer> good morning
<pitti> cpaelzer: nice work on the pg-repack regression!
<pitti> cpaelzer: so seems this doesn't need to block the update but the test can be fixed out of band?
<cpaelzer> pitti: if the SRU team is willing to move the MRE on with this understood but not yet fixed yes
<cpaelzer> pitti: I already have the debdiff for the SRU on the bug as well
<cpaelzer> pitti: for pg-repack I mean
<cpaelzer> pitti: I think if you could ack that "this doesn't seem to block the update" then I might be able to work with rbasak who is on SRU duty today to move things forward
<cpaelzer> pitti: oh I see  you already did state that 31 minutes ago - thanks
<cpaelzer> rbasak: do you think you would have some of your SRU time today to help me upload and SRU check these things?
<rbasak> cpaelzer: I'm prioritising FF today and tomorrow, sorry.
<cpaelzer> rbasak: fair focus
<cpaelzer> rbasak: that might be true for most SRU Team activity thse days
<cpaelzer> rbasak: what do you think of a session on Friday if nobody else moved it forwards until then?
<rbasak> cpaelzer: maybe, but it depends on what else I need to do on Friday because I deferred things because of FF :-/
<cpaelzer> rbasak: ok for me, I'll take the maybe and poll you then if still needed
<cpaelzer> pitti: if you want and can still move some bits of the MRE process forward please feel free to do so
<cpaelzer> pitti: I'm now blocked by lacking upload rights for the moment
<cpaelzer> pitti: in any case nacc can later on do the uploads into unapproved
<cpaelzer> pitti: nacc: and fromt here it is SRU team anyway
<pitti> cpaelzer: oh, I thought bileto could land that for you?
<cpaelzer> pitti: it can land it for people with upload rights
<cpaelzer> pitti: = not me yet
<cpaelzer> if a properly privileged person hits publish it might work
<cpaelzer> as you know I'm already preparing a PPU and probably even an MOTU application for all the pg-* tools and more
<cpaelzer> but not ready yet
<pitti> cpaelzer: trying, clicked publish on the trusty one
 * pitti polls https://launchpad.net/ubuntu/trusty/+queue?queue_state=1
<cpaelzer> I see the matching ping in ubuntu-ci-eng
<cpaelzer> pitti: does that land in unapproved or does it bypass that?
<pitti> I think unapproved; at least I saw a lot of bileto-origin srus there
<pitti> ah, there it goes! https://launchpad.net/ubuntu/trusty/+queue?queue_state=1
<cpaelzer> good
<cpaelzer> thank you
<cpaelzer> I was afraid it might a whole to bypass of SRU Team
<pitti> cpaelzer: I just can't use the sru-* tools in a chrot, launchpadlib says httplib2.ServerNotFoundError: Unable to find the server at api.launchpad.net
<pitti> so, I'm happy to accept and just update the bug manually, without the boilerplate (which is fine, it's a "synthetic" bug anyway)
<cpaelzer> ok, thank you for your help
<pitti> cpaelzer: ok, all set; I can't yet run copy-packages/sru-release (for the same reason), I suppose I'll need to figure out why this is broken
<pitti> (it's my actual ubuntu partition, but chrooted into -- so I don't think it's missing packages)
<cpaelzer> pitti: ok, at least it is now one step further and ready for the SRU Team - thanks
<pitti> cpaelzer: not the SRU team actually -- we need to wait for distro-CI, please verify that the tests turn out as expected, then mark v-done
<cpaelzer> oh you even got them to proposed I see
<pitti> then we can copy to -updates
<cpaelzer> will do so
<pitti> bileto is quite convenient for sponsoring!
 * pitti hands a cookie to robru
<infinity> pitti: Stupid question, but are you sure your chroot has a valid resolv.conf and/or nsswitch.conf compared to the host?
<pitti> infinity: actually that's a very good question!
<pitti> I don't have it at all; must have been a leftover from some resolved experiments (NSS would already resolve, no need for the file)
<infinity> (Arguably the best thing about having a local resolver, so all your chroots can have localhost in resolv.conf without needing a smarter tool like schroot to manage it)
<pitti> ah, no, I did have a file, but it points to /etc/resolv.conf -> ../run/resolvconf/resolv.conf
<infinity> Which is probably broken or missing?
<pitti> yeah, chroot :)
<infinity> 127.0.0.1 to the rescue, if you have a listening resolver.
<pitti> et voilÃ , it works, thanks!
<rbasak> update-excuses now completely hangs my Firefox :-/
<infinity> My plan is working.
<rbasak> 10.61M.
<infinity> It's my UDDoS on the Ubuntu development community.
<infinity> NDDos?
<pitti> oh dear, how many packages did you upload
<rbasak> links works. links FTW.
<infinity> pitti: None, I've just been too busy to fix the ones sitting there.
<infinity> Migrating perl will help a bit.
<infinity> Which just needs someone to find a few minutes to unwing libemb-perl or whatever it is.
<infinity> The rest of the failures are false positives.
<infinity> False negatives.
<infinity> False fails?
<infinity> Whatever.
<infinity> BROKEN TESTS.
<pitti> post-factual tests!
<infinity> Oh dear.
<jbicha> || true
<jbicha> alterative truth :)
<infinity> If American politics bleeds over the border much more than it already has, I'm moving to Germany.
<ogra_> alternatively you could build a wall on the south border
<infinity> I never thought I'd be able to unironically use the sentence "I'm moving to Germany to escape fascism", but here we are.
<ogra_> seems to be fashinable
<ogra_> +o
<pitti> jbicha: haha, good one
<pitti> infinity: I thought sanity levels in Canada were quite high still?
<infinity> pitti: Can I apply for political asylum on the grounds that being near the US makes me feel icky?
<ogra_> you'd get my vote
<pitti> no objections from me :)
<ogra_> but i'd suggest to wait til after the election in sept. ;)
<infinity> pitti: Yes and no.  I think the "average Canadian" is significantly less nutty butters than what's been happening to the "average American", but our right wing has been winging it up pretty well.  And even have a Trumpalike running for party lead of the Conservatives.
<infinity> pitti: And the Facebooks are full of Canadians who think the Republicans are god's gift and really want us to have our very own Tea Party.
<pitti> infinity: you won't be save from that in .de either .. AfD *cough*
<ogra_> yeah
<infinity> pitti: But AfD doesn't hold any meaningful power, right?
<ogra_> they wont get over 10.-15% but still
<ogra_> definitely got worse over the recent times
<pitti> infinity: ... yet
<infinity> pitti: The Cons are the official opposition here, and formed the government for a decade before that.  If they do the same grass-roots buggery the Republicans do, it would be the same story here as it was there.
 * pitti seriously hopes it won't ever get to that point
<infinity> pitti: As in, I'm not talking about a fringe group, I'm talking about old guard being infiltrated by fringe (much like the Tea Party tore up what was left of the Republicans)
<pitti> I still can't believe that it will take more than a year or two until Trump fans finally recognize the big scam and turn away
<infinity> You say that, but...
<infinity> If the last few weeks weren't enough, nor the campaign for a year before that, there's some obvious cognitive dissonance that just can't wash off.
<pitti> yeah, hopeless optimism
<infinity> Plus, the US has *massive* single-issue voter problems.
<infinity> On certain single issues that most of the rest of the western world considers settled and behind us (like abortion).
<maswan> we actually have some hope in recruiting to $work based on recent political outcomes in U[KS], we'll see how it goes when we have a couple of sysadmin positions out in a month or two
<pitti> . o O {  or treating women as humans .. }
<infinity> Sure, there are pro-life folks in every western country, but most of them realise it's decided, it's done, and it ain't being reversed.  American conservatives hold out hope with every election that if they elect just the right awful people, yay, no more abortion.
<infinity> And maybe that's one area where Canada remains saner.
<infinity> When we progress, we tend to refuse to look back.
 * mdeslaur gets more popcorn
<infinity> Even my hardline right-wing religious parents are like "yep, gay people can get married now, the people decided, the courts backed it up, we're done arguing, the end".
<ogra_> there is always a chance they go back to dark ages though ... see poland ... EU doesnt protect you from that
<maswan> infinity: Harper's science policy was not exactly according to this though, had a few extended collegues in that area that got screwed by that
<infinity> maswan: Harper certainly had his regressive moments.  Most (but not all) of them were firmly smacked down by our courts, though, which is comforting.
<maswan> They've just about started to attend our common confeerences again
<pitti> well, no democratic institution can "protect" folks from voting for the right thing, by definition :)
<pitti> err, "wrong" thing obviously
<infinity> maswan: That said, he looked like a downright hippie compared to the current GOP.
<maswan> infinity: yup
<smoser> pitti, in an adt run... how do i know what package is intended to be tested? i know you told me this once... ie, if B depends on A and A changes, so dep8 tests run for B, how can I know 'A' ?
<pitti> smoser: it's the "trigger" you see on the autopkgtest.u.c. history, or the top-level package on excuses.html
<pitti> smoser: if you only have the log, search for --env=ADT_TEST_TRIGGERS=
<smoser> pitti, thanks.
<ChrisTownsend> seb128: Hi, sorry to bother you again, but it looks like libertine is still stuck in proposed.
<infinity> ChrisTownsend: Fixing.
<ChrisTownsend> infinity: Thank you!
<infinity> ChrisTownsend: Should sort itself out in an hour or so.
<seb128> ChrisTownsend, I promoted the python package earlier
<infinity> (or less)
<seb128> maybe something else was needed
<infinity> seb128: Yeah, you missed one.
<seb128> k
<seb128> infinity, thanks for fixing
<bregma> need to hit it with a bigger stick
<ChrisTownsend> infinity: seb128:  Ok guys, thanks for your help!
<smoser> pitti, sorry to keep pestering you. will ADT_TEST_TRIGGERS ever be more than one package ?
<pitti> smoser: not from britney, but it can be from manual retries
<smoser> so what is the format then ? space delimited or something ?
<pitti> and potentially in the future once britney gets better about grouping packages
<pitti> smoser: yes, the env variable is space delimited
<ginggs> cjwatson_: damn this grub bug - i cloned one of the raid disks with dd, checked that the clone exhibits the same problem, then put it in another machine. Now it passes grub, but drops to busybox saying it can't find root. mdadm doesn't want to bring up the md devices, saying the sd devices are busy
<ginggs> also 'mdadm: CREATE group disk not found' whatever that means
<nacc> tjaalton: nice work on the dogtag-pki stuff, thanks for the prompt turnaround!
<nacc> tjaalton: i'll keep an eye on excuses
<Laney> nice
<Laney> I had that on my radar somewhere
<nacc> Laney: :)
<Laney> hope it fixes the tests :-)
<Laney> it's blocking a surprising amount of stuff given that I'd never heard of it :P
<nacc> Laney: we kicked tomcat8.5 out of z-p and updated dogtag-pki, which should resolve the testing issues (technically only by the former, but the latter fixes FTBFS in new versions)
<Laney> nacc: Roger, that's good to know, thanks!
<Laney> doh, the s390x autopkgtest workers had been taken out due to a networking glitch
<Laney> sorry 'bout that
<tjaalton> nacc: looks like it built at least :)
<nacc> Laney: yeah :)
<nacc> err, tjaalton --^ :)
<wxl> xnox: friendly reminder https://irclogs.ubuntu.com/2017/02/12/%23ubuntu-devel.html#t03:06
<wxl> xnox: sorry meant that to go elsewhere
<wxl> cyphermox: friendly reminder https://irclogs.ubuntu.com/2017/02/12/%23ubuntu-devel.html#t03:06
<cyphermox> wxl: didn't we say fixing just the bug for that SRU was better?
<wxl> cyphermox: that's sort of the message i'm getting. just confirming. if so i should be able to fix this really simply.
<wxl> cyphermox: this is my first ever SRU so forgive me :)
<cyphermox> no worries
<cyphermox> so, in theory it should be pretty simple to fix yeah, just ping me when you have a debdiff you want me to sponsor
<wxl> cyphermox: excellent. i'll have something done right quick :)
<_hc> I'm an upstream dev and Debian packager for fdroidserver (among many other things), and I wanted to know the process for updating that package in 16.04 LTS.  I've been searching around, but no luck.  The update is already in Debian/stretch
<nacc> !sru | _hc
<ubottu> _hc: Stable Release Update information is at http://wiki.ubuntu.com/StableReleaseUpdates
<nacc> _hc: but that would only be for bugfixes noramlly
<teward> might make for a backport though, but not sure what the backlog is for the backports team
<teward> (probably huge)
<nacc> jgrimm: just glancing at the other test failures for python-boto, it seems like it's getting 'wrong' http response codes (403 instead of 404, e.g.)
<nacc> jgrimm: seems like a auth issue somewhere for all of them, actually
<nacc> jgrimm: "The security token included in the request is invalid"
<jgrimm> nacc, cool. i'll dig into it.
<nacc> jgrimm: and Token: None
<nacc> slangasek: could you take a look at something, when you have a moment? heimdal is FTBFS on 17.04, and I'm not sure how it is supposed to work. I filed an upstream bug with no response at: https://github.com/heimdal/heimdal/issues/241
<nacc> slangasek: but i'm confused how this would work on non-64bit archs (where it does not FTBFS)
<slangasek> nacc: huh, so this is a different problem than the previous heimdal FTBFS issues, which IIRC were on 32-bit? :)
<slangasek> nacc: 'ldd ./lib/krb5/.libs/test_rfc3961' doesn't tell the whole story; the wrapper script created for the test sets the LD_LIBRARY_PATH
<slangasek> nacc: it's not obvious to me why the behavior would be different across archs
<nacc> slangasek: yeah, i'm spinning up an i386 env to debug it live to see if the path order is different there
<nacc> slangasek: and yeah, seems to be different :)
<nacc> slangasek: that 32-bit fix got merged upstream, btw
<nacc> slangasek: also, it seems like debian is not showing the same problem, on any archs
<slangasek> nacc: oh - libsqlite3-dev is shipping a .la file that points at libdir?  that would seem to be the trigger... is that new?  for a long time we've tended to strip .la files out of the .debs
<slangasek> so maybe this is a change that happened more recently than the last time heimdal built in Debian
<nacc> slangasek: ah that could be -- i'll dig into that
<slangasek> hmm the .la file is also there in libsqlite3-dev in yakkety
<slangasek> so I don't know
<slangasek> nacc: the other thing might be that Debian doesn't hit it because the system libhcrypto4-heimdal isn't installed in the build chroots?
<nacc> slangasek: ack, i'll check on that
<nacc> slangasek: good catch, the ppc64el build of heimdal in debian does not have libhcrypto4-heimdal installed: https://buildd.debian.org/status/fetch.php?pkg=heimdal&arch=ppc64el&ver=7.1.0%2Bdfsg-9&stamp=1483969232&raw=0
<slangasek> nacc: so, why is it there on the launchpad buildds?  It really seems to me that it shouldn't be
<nacc> slangasek: urgh, so on i386, `./test_rfc3961 --version` passes (which is what is failing on amd64 technically) but then actually running the test also emits the relocation error after finishing the test (successfully)
<nacc> slangasek: so i think it's technically busted on i386, but the behavior is different enough that it's being considered successful :/
<nacc> slangasek: is it relevant that `seeded-in-ubuntu` is indicating heimdal is seeded?
<nacc> slangasek: not sure what is the base of the launchpad buildd's
<nacc> slangasek: but agreed, it seems like heimdal packages are installed already, as the first log entries include upgrading them all
<tarpman> nacc: random guess: apt-transport-https -> libcurl3-gnutls -> libldap-2.4-2 -> libgssapi3-heimdal -> various heimdal libs
<tarpman> not sure what's responsible for apt-transport-https though, my own chroots don't have it
<nacc> it's recommended by apt-transport-tor and ubuntu-standard
<cjwatson> apt-transport-https has been explicitly added to LP build chroots for long enough that I can't discern a rationale
<slangasek> ah
<nacc> cjwatson: ok :)
<cjwatson> though I don't know how much resemblance infinity's current chroot-building code bears to the script in puppet
<cjwatson> my guess would be that it's to make private PPA builds work
<cjwatson> because the base URL for those on production is https
<nacc> that would make sense
<tarpman> nacc: ironically enough, in the past there was a bug in src:openldap packaging that was hidden by heimdal pulling libldap into build environments... :)
<nacc> heh
<cjwatson> I believe that buildd chroots are basically debootstrap --variant=buildd + pkgbinarymangler + pkg-create-dbgsym + apt-transport-https
<nacc> dirmngr -> libldap-2.4-2 -> libgssapi3-heimdal as well
<tarpman> ow
<nacc> i just today created a zesty-i386 schroot and looking at the log, the first thing 01launchpad-chroot does is instlal the heimdal packages among others
<nacc> http://paste.ubuntu.com/24003706/
<Unit193> cjwatson: Speaking of which, is there something tracking effort for LP/etc for supporting debhelper based dbgsyms?
<nacc> slangasek: so i'm not entirely sure how to fix this -- that is, I understand that it's maybe non-ideal for heimdal to already be installed, but it does go back to the libsqlite3.la file (i think) as to why the order matters
<nacc> slangasek: in z-p, libsqlite3-dev definitely contains a libsqlite3.la file
<nacc> slangasek: ah but nm, as you said, was also there in y
<cjwatson> Unit193: the LP side is done AFAIK: https://bugs.launchpad.net/launchpad-buildd/+bug/1623256
<ubottu> Launchpad bug 1623256 in debhelper (Ubuntu) "adjust the way to create dbgsym packages like Debian does" [Undecided,In progress]
<cjwatson> Unit193: well, except that the extension still needs to differ
<cjwatson> Unit193: but the buildd change there *should* be enough to allow refactoring the rest of it
<Unit193> Oh bah.  OK, thanks for the update.
<nacc> slangasek: ok, the exec. summary is that heimdal FTBFS if libheimdal* are installed (aiui) -- because the system-libheimdal files will get seen before the build-local ones and they will fail to properly load. Is it possible to specify an anti-build-depends? :)
<nacc> slangasek:  would 'Build-Conflicts' be appropriate here?
<tsimonq2> Who's doing patch pilot?
<tsimonq2> (for today)
<tsimonq2> >___> ... <___<
<slangasek> nacc: it would be a correct declaration, but I don't know if launchpad would be accommodating ;)
<nacc> slangasek: :)
<wxl> <tsimonq2> use the calendar
<slangasek> (it *should*, but you'll need to test)
<nacc> slangasek: ack, i'll try that locally first
<slangasek> nacc: the only things that would make it not work would be things specific to the launchpad builder config
<slangasek> so I don't think a local test helps much; try a ppa instead
<nacc> slangasek: ack
<tsimonq2> wxl: I'm seeing if they'll step forward :P
<nacc> slangasek: sigh, not trivial (local test did help for that :) -- heimdal b-d on libldap2-dev => libldap-2.4-2 => libgssapi3-heimdal and the same chain as above. So tarpman maybe you can help me understand why we have a different dependency chain in Ubuntu. Is this because we have gssapi enabled by default on Ubuntu only?
<tarpman> nacc: correct
<tarpman> nacc: via likewise-open
<nacc> tarpman: right
<nacc> tarpman: so any idea on how to disentangle this so we can build heimdal? :)
<tarpman> nacc: off the top of my head, nothing better than 'fix heimdal' :S
<tarpman> the gssapi thing is nasty, but I wasn't planning to revisit it sooner than the next ABI bump (i.e. 2.5)
<tarpman> "nasty" is the wrong word, but you get my fridt
<tarpman> drift
<nacc> tarpman: yeah
<nacc> tarpman: i'm just trying to think of what the 'sane' fix would be -- we could post-process the LD_LIBRARY_PATH so the system path is at the end but that seems gross and fragile
<nacc> tarpman: or even 'a' sane fix :)
<tarpman> I don't even want to know why the 32-bit builds passed, do I
<nacc> tarpman: afaict, they technically shouldn't have
<nacc> tarpman: the relocation error emitted on amd64 (at least), is emitted on i386 too, just not when you run ./test_rfc3916 --version :/
<nacc> tarpman: and for some reason, on 32-bit, it's not causing the testcase to fail (I'm guessing they do some post-process grepping for determining success and aren't checking the return code from the test itself)
<nacc> tarpman: so yeah, probably didn't want to know :)
<tarpman> nacc: sorry, I don't have time right now to look in enough detail to contribute. will try to look after work
<nacc> tarpman: totally fine!
<nacc> tarpman: thanks for responding at all :)
 * tarpman peanut gallery
#ubuntu-devel 2017-02-16
<infinity> slangasek, nacc: Build-Conflicts in LP are basically pointless, since every build chroot is "fresh", so the only things you could conflict against is stuff we have installed on purpose, which you may find less than helpful to do.
<infinity> (If you're talking crypto stacks, it's probably there because of apt-transport-https, which needs to be there to support private PPAs)
<infinity> But fixing build systems to not wig out about locally-installed cruft is always more robust than a Build-Conflict anyway.
<slangasek> infinity: right, so in a public build where apt-transport-https isn't needed, would a Build-Conflicts: with it successfully remove it and let the build proceed?
<nacc> infinity: yeah, i think that's the right answer, just not exactly sure what hte right fix should be -- have some ideas (and i have one hacky method that does work) -- but i'm still thinking about the 'right' solution
<infinity> slangasek: It's plausible that sbuild might remove it for you, yeah.
<nacc> slangasek: but in this specific case, that won't help, because of the b-d on libldap2-dev itself :/
<slangasek> right
<infinity> Though, in *this* case, it's particularly silly for a package to fail to build when its own binaries are already installed.
<nacc> yeah, it's a testcase bug, without question
<infinity> That almost has to be a bug in the Debian packaging somewhere, cause I can't fathom how an upstream wouldn't notice.
<infinity> Oh, it's just the testsuite?
<nacc> it's the generated LD_LIBRARY_PATH in the test wrapper
<infinity> That's more plausible that someone committed an oops there indeed.
<infinity> We've had any number of glibc tests over the years that were accidentally testing the system libc.
<nacc> which is putting the system  libs in there, since sqlite3 is from the system, and then we end up pickin gup heimdal-crypto from it and there's an ABI mismatch
<infinity> Turns out that's really hard to notice until it breaks.
<infinity> nacc: Surely, the build directories should always be listed first.
<infinity> There's literally no point in an LD_LIBRARY_PATH that puts your special things last.
<infinity> "Yeah, I guess maybe test that one, if nothing else is around *shrug*"
<wxl> what about figuratively?
<nacc> infinity: yeah, i agree -- it's just 'happening' to do this, it feels like
<nacc> i think upstream heimdal may build sqlite3 at the same time? not sure
<infinity> Ew.
<nacc> infinity: but i agree, it makes sense (esp. for this testcase) to i think order the LD_LIBRARY_PATH
<nacc> or something like that, just need to figure out what generates them and tweak it, i expect
 * infinity nods.
<infinity> LD_LIBRARY_PATH should always be hand-crafted for a sane order.
<infinity> Well, "hand-crafted" that would ideally use an intelligent generator, but you know what I mean.
<infinity> "Have some random paths" will end in sad.
<nacc> yeah
<nacc> very sad in this case :)
<infinity> I'd cite the glibc testsuite as a solid example of how to get this right (now), but also, don't read it.
<nacc> heh
<infinity> We may reach a critical tipping point where lines of make outnumber lines of C in glibc at some point.
<infinity> (Not really, but it feels that way)
<mwhudson> infinity: does it use dejagnu?
<infinity> mwhudson: Nope.
<mwhudson> infinity: well that's something at lest
<mwhudson> *least
 * mwhudson remembers "DejaGNU has to be stopped somewhere." https://sourceware.org/ml/binutils/2008-03/msg00221.html
<ubottu> sourceware.org bug 2008 in ld "Segfault on IA64, something to do with Unwind and section ordering" [Normal,Resolved: fixed]
<mwhudson> lol
<Unit193> sarnold: BTW, atheme-services, https://github.com/atheme/atheme/blob/master/NEWS.md (CVE-2014-9773, CVE-2016-4478) That's the version Zesty has.
<ubottu> modules/chanserv/flags.c in Atheme before 7.2.7 allows remote attackers to modify the Anope FLAGS behavior by registering and dropping the (1) LIST, (2) CLEAR, or (3) MODIFY keyword nicks. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-9773)
<ubottu> Buffer overflow in the xmlrpc_char_encode function in modules/transport/xmlrpc/xmlrpclib.c in Atheme before 7.2.7 allows remote attackers to cause a denial of service via vectors related to XMLRPC response encoding. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-4478)
<sarnold> xmlrpc processing in irc? o_O what happened to our crappy thirty year old protocol?
<Unit193> .8 is a fix+more for .7, and .9 is a fix for .8. :P
<UHck> hey
<UHck> hi
<UHck> I want to know what are other developers working on right now so I can help out I want to be MOTU
<cpaelzer> good morning
<Laney> tjaalton: I guess you saw the dogtag-pki autopkgtest failures?
<tjaalton> Laney: the old one?
<tjaalton> -2ubuntu1 should fix that
<Laney> ok
<Laney> I didn't see that on excuses
<tjaalton> uploaded -3 to debian and then decided I can't wait 10h :)
<UHck_> Hey does anyone know any cool projects being worked on for chromium
<UHck_> I meant ubuntu
<tjaalton> why the armhf builder is so painfully slow..
<cult-> xnox: thanks for your work! how long it takes to move the proposed packages to the universal repo?
<xnox> cult-, everything is described on https://wiki.ubuntu.com/StableReleaseUpdates have you read it?
<xnox> plus not everything has been published yet.
<cult-> alright. i verified it already. do we have to verify all the other packages?
<liveiso> Hi IRC Council
<liveiso> any articles about how official daily ISO are build?
<Laney> tjaalton: It's failing still https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-zesty/zesty/amd64/d/dogtag-pki/20170216_132005_70578@/log.gz
<Laney> did you run it locally?
<tjaalton> Setting up libresteasy-java (3.0.19-2)
<tjaalton> where did that come from
<tjaalton> it should depend on 3.1.0-2
<tjaalton> ah heck
<tjaalton> only on build-depends
<Laney> /o\
<liveiso> any one know how a ubuntu daily build are created?
<tjaalton> still, proposed is enabled so why doesn't it pick up the new one
<Odd_Bloke> liveiso: They're built in Launchpad's builders using livecd-rootfs and live-build.  Do you have a specific question/issue?
<Laney> you get the minimal amount of things from proposed
<liveiso> Hi Odd_Bloke, I want to learn advanced knowledge and background info
<liveiso> https://debian-live.alioth.debian.org/live-manual/stable/manual/html/live-manual.en.html
<liveiso> I know debian distro has this project to build ISO, so I ask the same project that creating daily iso for ubuntu
<tjaalton> Laney: oh well, that's not what breaks the test though
<tjaalton> I have it working with 3.0.19-3 just fine
<liveiso> after several google search (result quite less..), I guess there must be a build team in launchpad
<Laney> tjaalton: This command fails in the same way for me: autopkgtest -s -U --apt-pocket=proposed=src:dogtag-pki dogtag-pki -- lxd autopkgtest/ubuntu/zesty/amd64
<tjaalton> I've lost my lxc images
<tjaalton> can't remember how I tested these four months ago
<Laney> autopkgtest-build-lxd images:ubuntu/zesty/amd64
<Laney> assuming lxd works for you in general
<Laney> I would guess that qemu will do the same too
<tjaalton> lxd doesn't work because my uid is silly
<tjaalton> creating the image does, autopkgtest does not
<tjaalton> works with sudo
<tjaalton> and fails the same
<tjaalton> how can I see what lxd images are around?
<Laney> lxc image list
<tjaalton> thx
<tjaalton> dunno then, pkispawn works fine on a qemu host
<Laney> autopkgtest-buildvm-ubuntu-cloud -r zesty, replace the end of the autopkgtest command with -- qemu autopkgtest-zesty-amd64.img
<Laney> that fails in the same way
<Laney> qemu instead of lxd this time
<tjaalton> okay
<tjaalton> i'll look into it
<Laney> awesome
<Laney> now I can lunch happy
<tjaalton> Laney: weird, restarting it manually from the autopkgtest instance works
<Laney> fun
<tjaalton> guess I found the bug, just don't know why it happens now
<tjaalton> Feb 16 15:11:38 autopkgtest-lxd-nffbdq pki-tomcatd[7293]: ERROR:  No 'tomcat' instances installed!
<tjaalton> it runs "/etc/init.d/pki-tomcatd start pki-tomcat" and it fails, with just "start" it works
<nacc> rbasak: caribou: sorry if already discussed, but in the nut merge, is that conflict context in the diff? (<<<<<< =====)
<rbasak> nacc: it's not present. I think it's because it technically conflicts with debian/sid because debian/sid is slightly newer now.
<rbasak> I think it's an LP bug.
<nacc> rbasak: oh ok, wasn't sure, just saw it in the e-mail
<smoser> hey...  the open-iscsi tests take a long time to run.
<smoser>  and end in timeout sometimes
<smoser>  example https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-zesty/zesty/i386/o/open-iscsi/20170210_235810_8d27d@/log.gz
<smoser> anyone have suggestions on how to do that ?
<smoser> to increase the timeout essentially? it was *not* hung, it just is slow
<smoser> and then... cloud-utils is held because of such a failure (and another failure also). my uploaded version of open-iscsi from yesterday should be fixed
<pitti> Laney: ^ add it to long_tests in worker*.conf, please?
<smoser> do i just hit the recycle icon ?
<Laney> long_tests
<Laney> pitti: Yes, I know, thanks.
<smoser> \o/ that was easy.
<pitti> ah, good :)
<smoser> so do ij ust hit the recycle button ?
<Laney> You wait, and then do that
<pitti> makes more sense to wait until the change is deployed
<Laney> I have to pull in like 9999 locations
 * Laney sniggers
<smoser> ok. thank you.
<Laney> smoser: ok, do it now
<nacc> tjaalton: hrm, new dogtag-pki also fails autopkgtest
<tjaalton> I know
<Laney> haha
<tjaalton> it's some sort of a race condition
<nacc> tjaalton: i can reproduce locally -- it seems like a tomcat interaction?
<tjaalton> no
<nacc> tjaalton: it reproduces every time for me at home -- doesn't feel like a race we ever win :)
<tjaalton> does autopkgtest drop to a shell?
<tjaalton> does so here
<nacc> tjaalton: not the way it is run in the automatic tests, but with -s, yes
<nacc> tjaalton: i'm at the shell in a failure at home, if you want me to debug anything
<tjaalton> "/etc/init.d/pki-tomcatd stop; /etc/init.d/pki-tomcatd start pki-tomcat" works fine after the test fails
<tjaalton> it thinks /etc/dogtag/tomcat is empty
<tjaalton> the first time
<tarpman> tjaalton: this isn't the same thing I wrote about in bug 1664453?
<ubottu> bug 1664453 in dogtag-pki (Ubuntu) "autopkgtests failing with systemd-232" [Undecided,New] https://launchpad.net/bugs/1664453
<nacc> tarpman: good bug/reminder
<tjaalton> tarpman: now it is, after all the other bugs got sorted
<tjaalton> or maybe is
<tjaalton> but the error was
<tjaalton> Feb 16 15:11:38 autopkgtest-lxd-nffbdq pki-tomcatd[7293]: ERROR:  No 'tomcat' instances installed!
<tjaalton> from the initscript
<tjaalton> that left the job in "active(exited)" status
<tarpman> my analysis was - that happens when the package is initially installed, before anything is configured
<tjaalton> ah
<tjaalton> could be
<tarpman> but the start() issued from pkispawn is a no-op because systemd considers the service already started
<tjaalton> yeah the timestamp might suggest that actually
<tarpman> I changed start() to restart() in scriptlets/configuration.py and that made the test pass on my system *shrug*
<tarpman> this is all in the bug, anyway ;)
<tjaalton> sure
<tjaalton> it really shouldn't start anything by default
<tarpman> I was wondering about that. not sure how to set up a sysv service that starts on boot but not when installed - at least without resorting to ENABLED=0 sort of hacks
<tjaalton> I'll fix the initscript
<nacc> tjaalton: where does the 143 SuccessExitStatus come from?
<tjaalton> nacc: where?
<nacc> tjaalton: in the pki-tomcatd service file
<tjaalton> no idea
<tjaalton> upstream
<nacc> 'pki-tomcat' must still be CONFIGURED! ... (see /var/log/pki-tomcat-install.log). Which doesn't exist :)
<smoser> nacc, do i need to kick the importer manually ?
<smoser> it does not have my open-iscsi upload from yesterda
<ogra_> wouldnt that be "footually" (if you kick) ?
<ogra_> :)
<tjaalton> nacc: where do you see that path?
<nacc> smoser: let me check
<nacc> tjaalton: i was messing around locally and trying to start the service after the failure and `systemctl status pki-tomcatd` says that
<tjaalton> nacc: 143; https://fedorahosted.org/pki/ticket/716
<nacc> tjaalton: ack, thanks
<tjaalton> nacc: ok, found it.. looks like it's a bit misleading message :) fedora doesn't use any of the initscript crap anymore, but we have no choice because tomcat has not migrated
<nacc> smoser: hrm, it seems like it should have, you're right. kicking it
<nacc> smoser: there must be a bug in my logic, i'll take a look
<nacc> tjaalton: ok :)
<nacc> tjaalton: manually running the failing test immediately after being dropped to the shell does produce this gem: http://paste.ubuntu.com/24008402/
<tjaalton> hehe
<tjaalton> I've got a working initscript now..
<tjaalton> which fails the right way ;)
<tjaalton> leaves the job in a failed state, guess that's proper.. test passes now
<nacc> tjaalton: cool, uploading?
<tjaalton> in a bit
<nacc> tjaalton: ok
<nacc> smoser: i think it should be there now
<nacc> rbasak: just to verify, you've not pushed your snapd import fix to master, right?
<tjaalton> nacc: done
<nacc> tjaalton: thanks!
<rbasak> nacc: I thought you had?
 * rbasak looks
<nacc> rbasak: hrm, it's failing to import, let me check
<nacc> rbasak: yeah it's there
<rbasak> What's the error?
<nacc> rbasak: checking
<nacc> rbasak: i bet it's failing to FF one of the -devel heads
<nacc> rbasak: that just happend to tomcat8 too
<nacc> rbasak: bah i know why
<nacc> rbasak: the importer's repo is out of date
<rbasak> Ah
<nacc> rbasak: sorry for the noise
<nacc> tjaalton: i think we can sync -3 from debian, right?
<nacc> tjaalton: as in, it's the same as 2ubuntu1 afaict
<tjaalton> nacc: I uploaded this as -3u1
<nacc> tjaalton: ah ok
<tjaalton> debian can wait for this, as it's busted there anyway
<nacc> tjaalton: just didn't see it in the queue or on lp
 * nacc will be patient
<tjaalton> zesty-changes has it
<tjaalton> armhf build will take 2h
<rbasak> nacc: if you have time, would you mind casting your eyes over https://git.launchpad.net/~racb/ubuntu/+source/nut/log/?h=merge please, before I upload? caribou is out now, so he can't check for me.
<nacc> rbasak: lookin
<nacc> *looking
<nacc> rbasak: do we care that there is a 2.7.4-5 already?
<rbasak> Oh, good point.
<nacc> looks to be a debian bugfix, so not urgent, i suppose
<nacc> rbasak: the debian/tests/test-nut.py is formatted a bit funny
* Laney changed the topic of #ubuntu-devel to: Yakkety Yak (16.10) Released | Archive: feature freeze, DIF | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-yakkety | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | Patch Pilots:
<nacc> rbasak: in that the "+ 5..." i think is actually not a sub-bullet
<rbasak> nacc: in the changelog?
<nacc> rbasak: yeah
<nacc> rbasak: http://paste.ubuntu.com/24008659/
<nacc> rbasak: the first line just ends 'give nut at most'
<rbasak> wAh
<rbasak> Ah
<rbasak> And now that you point it out, some of the other bullets are indented wrong or use the wrong bullet type.
<rbasak> Thanks, I'll fix up.
<rbasak> Also I just rebased to debian/sid. Seems to work.
<nacc> yeah, cosmetic, but worth cleaning now
<nacc> nice
<nacc> rbasak: othewrise, contentfully looks good
<mapreri> is DIF already in effect really?
<nacc> rbasak: i do think we should at some point adjust our documentation to drop whitespace noise in the changelog diffs
<nacc> rbasak: the tail of the debian/changelog changes is all noise
<nacc> rbasak: as well as a deletion of some metadata?
<rbasak> git-merge-changelogs is a no-op.
<rbasak> And a diff against old/ubuntu shows no changes apart from the dropping of the emacs modelines at the bottom
<nacc> ack, i'm not saying the merge is wrong
<rbasak> So it's an error carried forward. Opinions on fixing up?
<nacc> i'm suggesting we fix those errors :)
<nacc> not urgent for this merge
<rbasak> Let's leave it for now. We can discuss later. I feel that's a job for our tooling.
<nacc> we should talk about it generally, though, it's just noisy, and adds some overhead to the review (trivial amount, probably)
<rbasak> Yeah
<rbasak> http://paste.ubuntu.com/24008663/ are my changes from what you've just reviewed. Look good?
<rbasak> asciidoc-dblatex is picked up from latest sid.
<rbasak> It's in universe, but appears to be a documentation building thing anyway, so I don't think it'll result in a component mismatch (new rules)
<nacc> rbasak: yep, looks good
<rbasak> Thank you for the review! Uploading now.
<rbasak> Oh, and I need to bump the version.
<nacc> rbasak: err, right
<rbasak> And it FTBFS due to a symbol mismatch :-(
<rbasak> Oddly, it's on ppc64el only. caribou, do you mind looking into that when you're back please?
<rbasak> I filed bug 1665431 so hopefully we (server team) won't forget.
<ubottu> bug 1665431 in nut (Ubuntu) "nut 2.7.4-5ubuntu1 FTBFS on ppc64el" [High,Triaged] https://launchpad.net/bugs/1665431
<nacc> infinity: not urgent, but the heimdal issue seems to actually be from libtool itself (ltmain.sh generates the wrapper script and doesn't elide system library paths from a variable called temp_rpath like it does for a few others (compile_rpath and finalize_rpath)). Not entirely sure how to fix, since that gets regenerated at build-time from libtool
<jgrimm> nacc, have time for a merge review (/me races against the FF clock)
<nacc> jgrimm: i should be able to
<nacc> jgrimm: which one?
<jgrimm> nacc, https://code.launchpad.net/~jgrimm/ubuntu/+source/libqb/+git/libqb/+merge/317540
<nacc> jgrimm: well, and technically, FF has happened (see /topic)
<jgrimm> nacc, /me had 3pm in his head
 * nacc is not entirely sure what DIF stands for
<sarnold> what's DIF?
<nacc> heh
<nacc> Laney: --^
<sarnold> nothing useful looking in lastlog or google "ubuntu DIF" ..
<nacc> jgrimm: the merge looks good, but if FF is in place, we'd need an FFe, i think
<Unit193> Debian Import Freeze, sarnold.
<sarnold> thanks Unit193 :D
<nacc> Unit193: ah thanks!
<Unit193> No problem.
<jgrimm> nacc, Zesty will be enter Feature Freeze at 21:00 UTC tonight. ?
<nacc> hrm, maybe DIF is meant to be the 'type' of freeze right now?
<jgrimm> was email sent out a bit ago
<nacc> jgrimm: to which list?
<jgrimm> nacc, ubuntu-release at least
<rbasak> jgrimm: taking the autofs merge.
<jgrimm> nacc, and ubuntu-devel-announce
<nacc> jgrimm: ack
<jgrimm> rbasak, ack and thanks.
<jgrimm> nacc, thanks
<Unit193> Archives haven't picked 'em up.
<rbasak> jgrimm: autofs merge uploaded.
<rbasak> It was trivial, so I didn't file an MP.
<rbasak> Also *none* of the patches added over the years appears to have been upstreamed, which is quite disappointing.
<jgrimm> rbasak, thanks sir
<rbasak> I've made a note to do that.
<jgrimm> rbasak, yeah seems to be a mixed bag on whether that happens. i like that we've been religious this cycle
<nacc> infinity: this is rather ugly, but it does seem to at least pass the tests now. http://paste.ubuntu.com/24008952/
<infinity> nacc: patch is build-essential, you don't need to build-dep on it.
<nacc> infinity: ah ok
<nacc> i think i've seen another src pkg that has had to similar runtime patching outside of quilt, but I can't recall. I don't love it, and it feels fragile, but I'm also not a libtool expert as to why temp_rpath hasn't been made to resemble the other rpath's
<robru> cyphermox: so, looking at https://launchpadlibrarian.net/303039011/buildlog_ubuntu-zesty-arm64.fbset_2.1-29_BUILDING.txt.gz is that as easy as it looks? just add -fPIC?
<cyphermox> from my naive look at it, yeah
<robru> ok I'll give it a shot
<infinity> Probably not that simple.
<infinity> That one might rely on a dpkg merge magically making it happy.
<infinity> Which I need to do immediatelt after feature freeze. :P
<infinity> robru: Given that the fbset change was to use dpkg-buildflags, and it worked in Debian and not Ubuntu, *and* the upload was by the dpkg maintainer, I'll give 90-to-1 odds it relies on a newer dpkg-buildflags. ;)
<robru> infinity: so I'll leave that for you then?
<Unit193> Ah, that's when.  I'd asked but you may have been busy.  I'd presume/hope that depends on LP 1657704 (or, at least not rejecting the upload.)
<ubottu> Launchpad bug 1657704 in Launchpad itself "please start storing buildinfo files, for new dpkg versions" [High,In progress] https://launchpad.net/bugs/1657704
<infinity> Unit193: Yes.  I'll need to talk to Colin before I go breaking the world.
<jgrimm> are autopkgtests able to touch real world internet? python-boto tests want to interact with AWS, works fine on my system, but possibly not allowed in real build/test infra?
<stgraber> jgrimm: so long as you test deals fine with http_proxy and https_proxy you should be fine. Direct connection isn't allowed, but a proxy is provided for adt tests to access the internet.
<jgrimm> stgraber, ok good to know, i'll  look for that
<jgrimm> i should probably set my local testing with that configuration too, catch things pre-upload
<jgrimm> or learn to use bileto..doh
<smoser> hey. anyone ran autopkgtest on ppc64el ?
<smoser> failing for me like: http://paste.ubuntu.com/24009324/
<wxl> smoser: could be wrong but i thought i saw some discussion on that on -release
<smoser> my history doesnt show anything similar, other than that infinity probably can tell me what is wrong.
<nacc> infinity: fwiw, i've sent an e-mail to the libtool list to ask about it, but do you think that change makes sense otherwise?
<infinity> nacc: I don't have the time to unpack it and have an opinion, sorry. :/
<nacc> infinity: no problem!
<nacc> rbasak: would you be around by any chance?
<rbasak> nacc: o/
<bdmurray> smoser: Do you have any plans to update curtin for yakkety like is being done for xenial?
<slangasek> nacc: heh, running process-removals... an awful lot of packages removed from Debian unstable in December because they were uninstallable w/ php7 and never fixed
<nacc> slangasek: not too surprising
<nacc> infinity: quick check-in, I briefed rbasak on my chnage, I've verified it should have no impact on the built packages (just lets the test pass), I've opened a bugtask on libtool in the heimdal bug. We can alwasy revert the chagne if you find time to review and disagree with it. Are you ok if I upload the fix?
<infinity> nacc: I have no opinion.  If it fixes things and breaks nothing, go for it.
<nacc> infinity: ok :)
<nacc> i'm struggling to figure out why a debian/.gitignore file is being deleted by my dpkg-buildpackage runs. I think maybe I'm missing a flag, but -i -I doesn't seem to make a difference.
<rbasak> nacc: don't you *not* want -i -I if you want stuff like that included?
<nacc> rbasak: it didn't seem to make a difference either way
<infinity> nacc: It's meant to be excluded.
<nacc> rbasak: maybe because it's debian/.gitignore rather than .gitignore?
<infinity> nacc: And "-i -I" (without extra args) are the default now, I thought.
<nacc> infinity: right, but for some reason it still shows up as deleted in the debdiff (and it's not present in the debian.tar.xz)
<infinity> Err.  Yes, I'm arguing that's a good thing.
<rbasak> I didn't realise it was default.
<rbasak> But if it is, then AFAICT nacc's reported behaviour is the expected behaviour.
<infinity> I could be wrong, but I thought it had become the default.  I dunno, '-i -I' are finger memory for me.
<rbasak> And debdiffs would show one deletion at the point where the default changed.
<nacc> acck
<tarpman> default for 3.0 source formats, isn't it?
<xnox> barry, maybe i should do that, no?
<xnox> if you are about to SRU https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1647031 into yakkety?
<ubottu> Launchpad bug 1647031 in systemd "systemd-resolvedâs 127.0.0.53 server does not follow CNAME records" [Unknown,New]
<barry> xnox: you're welcome to do the sru :)  i was going to cherry-pick back the two reverted revisions in zesty
<xnox> barry, what was reverted?
<barry> xnox: 98974a88 and 47c16e59
<xnox> barry, i already made a zesty upload with -18 merge and other patches that were in the queue outstanding.
<barry> they cherry picked cleanly
<barry> xnox: i'm running the autopkgtests now and then will test the packages on my vm
<xnox> barry, which repository is that in? cause I don't see those in either debian or the upstream systemd =/
<barry> xnox: that's because it's in network-manager and i haven't pushed the revisions yet :)
<xnox> barry, carry on! =)
<barry> % git remote -v
<barry> origin	git+ssh://barry@git.launchpad.net/~network-manager/network-manager/+git/ubuntu (fetch)
<barry> xnox: :)
<xnox> barry, i thought you are talking about systemd ;-)
<barry> xnox: slangasek already uploaded the systemd fix that broke nm
<barry> i'm just reverting nm back to using resolved
<nacc> jgrimm: fyi, heimdal build fix is committed, just waiting on arm64 to finish (it successfully built everywhere else)
<jgrimm> ack
<tjaalton> nacc: finally, dogtag tests pass
<kyrofa> So let's say I wanted to compare the size of an Ubuntu Core image with the size of an Ubuntu Server image. I'm having trouble determining what exactly to compare. I have a basic uncompressed Ubuntu Core image, but comparing to e.g. the Server ISO makes no sense
<jgrimm> tjaalton, \o/
<sarnold> kyrofa: a cloud image is probably most immediately comparable http://cloud-images.ubuntu.com/xenial/current/
<kyrofa> sarnold, I thought about that, but which one? disk1?
<kyrofa> (.img)
<sarnold> kyrofa: that's probably the best choice; I don't know which of the others would have compression (but based on the sizes I could guess..)
<kyrofa> sarnold, alright great, thank you!
<kyrofa> sarnold, this Ubuntu Core image is 689.5MB, whereas the Ubuntu Server disk1.img is 322.8MB. How is that possible?
<nacc> tjaalton: nice!
<kyrofa> I could the image could include dead space...
<sarnold> kyrofa: heh, good question. are there published manifestts that might explain the differences?
<kyrofa> sarnold, not published, no. I know they're generated, but I'm not sure where they are
<kyrofa> sarnold, if I compressed them both with the same args, think that'd account for any padding in the partitioning? Or would that completely invalidate the comparison?
<sarnold> kyrofa: I think that would be ideal; I doubt there's much padding otherwise we'd serve it compressed...
<kyrofa> sarnold, I'm talking Ubuntu Core here (which is indeed served compressed), so good deal, I'll give that a shot
<kyrofa> sarnold, yep, you're right, like 5MB savings on the server image. Still waiting on core...
<kyrofa> sarnold, *cough* 417MB. Definitely padding, and definitely still larger than the cloud img
 * kyrofa deletes a slide from his deck
#ubuntu-devel 2017-02-17
<DarthFrog> Hi folks.  I was wondering, is there an info to be had about installing & booting Ubuntu Server from ZFS?
<sarnold> DarthFrog: give this a look https://github.com/zfsonlinux/zfs/wiki/Ubuntu-16.04-Root-on-ZFS
<DarthFrog> Thanks!
<smoser> bdmurray, shoot. i realized i never responded to you.
<smoser> i can upload to yakkety
<smoser> should be uploaded as soon as local sbuild finishes
<smoser> done.
<stgraber> barry: just uploaded a fixed autopkgtest to the archive (adds support for LXD storage API). If that resolves the failure with LXD 2.9, it'd be great if you could push that fix to Debian so we can sync again.
<tjaalton> Laney: I've kicked several dogtag-pki autopkgtests, but looks like freeipa test on dogtag-pki/i386 is somehow in limbo and just shows "in progress" while it clearly is not
<tjaalton> oh sorry
<tjaalton> now it's running :P
<tjaalton> damn. the queue was empty though
<Laney> hehe
<tjaalton> I'll kick the rest
<Laney> if you wait for dogtag-pki itself to migrate you'll have an easier time getting the new ones to pick that version up
<Laney> good work on the tests btw
<tjaalton> yeah
<tjaalton> I'll wait for that.. then work on freeipa which seems to have some issues still :/
<caribou> rbasak: nut's ftbs, looking at it
<rbasak> caribou: thanks!
<Laney> tough nut to crack
<caribou> rbasak: looks like it's a dh_makeshlibs issue : http://pastebin.ubuntu.com/24012671/
<rbasak> caribou: yeah it seems to end up with extra symbols on ppc64el which aren't part of the ABI
<rbasak> I'm not sure I understand why.
<caribou> rbasak: dunno where that cruft comes from indeed
<rbasak> I've seen it in other packages.
<rbasak> It seems wrong to just stuff those lines in libnutclient0.symbols.
<rbasak> doko: ^ any advice please?
<caribou> rbasak: I get the same error in a PPA
<caribou> rbasak: doko is out today afaik
<caribou> rbasak: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=831725
<ubottu> Debian bug 831725 in src:nut "nut: FTBFS on some 64-bit architectures with symbols mismatches" [Serious,Fixed]
<caribou> rbasak: fix is in though
<cult-> xnox: Boris hasn't yet responded on the ticket. I could only verify the base odb package. is there anything i can do?
<tsdgeos> oh man our zesty libreoffice still crashes because the version mismatch between apps and l10n is still there
<tsdgeos> are we going to fix that or should i just go the snap way that seems to have the newer version anyway?
<caribou> Is there a reason why dpkg-gensymbols would behave differently on ppc64el ?
<caribou> it appends the full version string (with the ubuntu1 suffix) on ppc64el and does not on amd64
<caribou> here is the diff of the debian/libnutclient0/DEBIAN/symbols files b/w amd64 & ppc64el builds : http://paste.ubuntu.com/24013220/
<caribou> rbasak: I suspect that this is why nut build is failing on ppc64el
<infinity> caribou: That just means the symbols files in the package are wrong.
<infinity> caribou: And don't list ppc64el where they should.
<caribou> well, it's in the debian buildlog as well, so might not be why it fails
<infinity> It is why it fails.
<infinity> At least one of the symbols is obviously jumping out.  Lemme dig a bit.
<caribou> infinity: here is the debian buildlog : https://buildd.debian.org/status/fetch.php?pkg=nut&arch=ppc64el&ver=2.7.4-5&stamp=1485336450&raw=0
<infinity> caribou: Not sure why our toolchains differ to make that not fatal in Debian, but our behaviour is more correct. :P
<caribou> infinity: good to know
<infinity> caribou: Tossing a build at ppa:adconrad/staging to see if I got all the bits.
<ginggs> infinity, caribou: new symbols aren't fatal, dropping symbols is
<ginggs> ppc64el defaults to -O3 in Ubuntu
<ginggs> some symbols might be being optimized away
<infinity> Oh, indeed, I missed the MISSING line.
<caribou> infinity: could come from here : http://paste.ubuntu.com/24013303/
<caribou> that's the bug I mentionned earlier
<infinity> caribou: https://launchpad.net/ubuntu/+source/nut/2.7.4-5ubuntu2
<caribou> infinity: yep, got it but it faiild
<caribou> failed
<caribou> infinity: looking at your diff atm
<infinity> The part where nut is leaking half of stdlib through its ABI is ridiculous.
<infinity> So, yes, -O3 generates slightly different stdlib grossness, and ppc64el becomes a unique snowflake on Ubuntu.
<infinity> The other option would be to drop optimisation to -O2.
<infinity> The best option would be to fix libnutclient0 to stop leaking stdlib.
<infinity> Anyhow, this works for now.
<fossfreedom_> seb128: sorry to keep bothering... - beta 1 is next week.  Any chance that our gnome-menus patch (bug 1631745) could be pushed before the beta build on Tuesday? TIA
<ubottu> bug 1631745 in gnome-menus (Ubuntu) "Ubuntu Budgie - panel crashed with SIGSEGV in g_slice_alloc()" [High,In progress] https://launchpad.net/bugs/1631745
<infinity> caribou: So, all the lines where I added ppc64el to some amd64 bits, those can be upstreamed to Debian.
<caribou> infinity: k
<infinity> caribou: Where we're unique is that top line with the mangled ppc64el-only stdlib thing, and near the end, with the !ppc64el added to a demangled stdlib thing. :P
 * infinity ponders a nap.
 * caribou ponders a meal
<seb128> fossfreedom, not today, I've too much to do and need to call it day early but I'm not the only sponsor around
<seb128> fossfreedom, I can have a look on monday otherwise
<fossfreedom_> seb128: thanks - ask on motu?
<seb128> they probably don't have upload rights for main?
<seb128> no, the channel we are on is good
<seb128> but it's not easy to find people wanted to do sponsoring nowadays :-/
<fossfreedom_> thanks.  Anyone around who is able to upload to main and is willing to sponsor a very import fix for Ubuntu Budgie please? bug 1631745
<ubottu> bug 1631745 in gnome-menus (Ubuntu) "Ubuntu Budgie - panel crashed with SIGSEGV in g_slice_alloc()" [High,In progress] https://launchpad.net/bugs/1631745
<jamespage> ratliff, hello
<jamespage> ratliff, the python-crypto security update to 2.6.1-6ubuntu0.16.04.1 in xenial has a bit of a knockon into paramiko
<ratliff> jamespage: ask working on it, I will release a regression fix asap
<ratliff> jamespage: thanks for letting me know
<jamespage> ratliff, just found the bug report for paramiko !
<jamespage> ratliff, CTR mode needs counter parameter, not IV
<jamespage> ratliff, no not that on
<jamespage> ratliff, https://bugs.launchpad.net/ubuntu/+source/paramiko/+bug/1665565
<ubottu> Launchpad bug 1665565 in paramiko (Ubuntu) "python-paramiko 1.16.0-1 incompatible with python-crypto 2.6.1-6ubuntu0.16.04.1" [Critical,Confirmed]
<jamespage> beisner, ^^
<beisner> ack thx jamespage
<popey> hello! apparently http://gb.archive.ubuntu.com/ubuntu/dists/precise/main/installer-amd64/current/images/netboot/xen/vmlinuz doesn't boot under Xen anymore, but the trusty and xenial ones do. Where should this be reported?
<Odd_Bloke> popey: That file hasn't changed in ~5 years, so I'd be surprised if that specific path was the issue.
<smb> popey, the question might be under what version of Xen. I could imagine hypervisor changes happening which might result in old kernels failing with newer hypervisor versions. tbh with precise I would be tempted to hide somewhere until April
<popey> Odd_Bloke: smb I'm told in Xen 4.4 (which is in debian stable) is breaks.
<popey> hm, it's possibly it's always been broken, friend said he only just discovered it.
<smb> That I could believe. Not sure why there is a special image anyway. At least for Precise onwards I believe the normal kernel should just work
<popey> Ok. Thanks.
<barry> stgraber: 4.3ubuntu1?
<Henning__> Is there any way to get this into zesty: https://bugs.launchpad.net/ubuntu/+source/xkeyboard-config/+bug/1655782 ?
<ubottu> Launchpad bug 1655782 in xkeyboard-config (Ubuntu) "Elfdalian layout + merge with Debian 2.19-1" [Wishlist,In progress]
<teward> arges: cyphermox: either of you know whether there was any progress on https://bugs.launchpad.net/bugs/1600452 ?  Someone on Ask Ubuntu is asking if/when this fix will be available to backport into older releases.
<ubottu> Launchpad bug 1600452 in mokutil (Ubuntu Xenial) ""Failed to set variable: (2) Invalid Parameter" when enrolling MOK" [Medium,Confirmed]
<teward> and I haven't seen any progress on that since Sept. in the comments.
<cyphermox> teward: it always takes a while, this requires a new shim to be signed.
<smoser> hey. open-iscsi at http://autopkgtest.ubuntu.com/running#pkg-open-iscsi
<smoser> is there a way to get the full log of that ?
<smoser> or do i just have to wait till it fails (neither of those are going to finish, the hang has occurred)
<nacc> slangasek: infinity: re perl and libembperl-perl, it's a testcase regression (I think) where if PERL_DL_NONLAZY=1 is set, we get a redefinition warning from the DynaLoader module. Is it normal for DynaLoader.pm to be in both /usr/lib/x86_64-linux-gnu/perl/5.24.1/ and /usr/lib/x86_64-linux-gnu/perl-base/ ?
<nacc> I guess so, nm, it's that way in yakkety (allowing for version difference) too
<nacc> slangasek: infinity: ok, so I ran the libembperl-perl testcase against the release pocket and it also fails
<fossfreedom> Hi all - I asked this earlier - but just in-case someone who didnt see ...  Anyone around who is able to upload to main and is willing to sponsor a very import fix for Ubuntu Budgie please? bug 1631745
<ubottu> bug 1631745 in gnome-menus (Ubuntu) "Ubuntu Budgie - panel crashed with SIGSEGV in g_slice_alloc()" [High,In progress] https://launchpad.net/bugs/1631745
<nacc> fossfreedom: i can look
<fossfreedom> much appreciated!
<nacc> fossfreedom: the patch from Feb. 10, I assume
<fossfreedom> yes - comment 19
<nacc> fossfreedom: sponsored
<nacc> fossfreedom: note that i think there is no actul task for budgie-desktop itself?
<fossfreedom> nacc: \o/
<fossfreedom> correct - nothing specifically for budgie-desktop - but its budgie-desktop that crashes due to this bug in gnome-menus
<nacc> fossfreedom: ack, i'll mark it as fix committed there too then
<nacc> fossfreedom: it'll need to be manually updated to fix-released when gnome-menus migrates
<fossfreedom> no worries - I'll handle.
<nacc> fossfreedom: thanks!
<nacc> xnox: i saw your rebuild for liblog4ada -- I don't understand how/why it's still out of date. Do you know ada? :)
<kyrofa> Where might I find the manifest for ubuntu server (amd64)?
<kyrofa> Xenial, specifically
<kyrofa> I see the ones for the desktop on http://releases.ubuntu.com/xenial/, but no server
<dobey> kyrofa: the manifest of the ISO, or do you mean the bits that genrate the ubuntu-server meta-package?
<ogra_> kyrofa, http://cdimage.ubuntu.com/ubuntu-server/xenial/daily/current/
<ogra_> they seem to not go to releases.u.c for some reason
<dobey> yeah and desktop iso isn't on cdimage for some reason
<dobey> no idea why
<kyrofa> dobey, ogra_ haha, perfect, thanks guys
<ogra_> dobey, just a bit hidden http://cdimage.ubuntu.com/xenial/daily-live/
<ogra_> or s/xenial// for zesty
<dobey> ogra_: i mean, the release ISOs aren't in the like 16.04.1 release directory on cdimage, but the server ISOs are
<ogra_> ah, yeah
<infinity> dobey: Eh?
<infinity> dobey: "the release ISOs aren't in the like 16.04.1 release directory"?
<infinity> dobey: x86 goes to releases, ports go to cdimage.
<infinity> dobey: The "server ISOs are on cdimage" bit you're seeing are !x86.
<dobey> oh
<dobey> well when looking for *desktop* i wasn't even paying attention to what archs were there, only that desktop wasn't
<infinity> cdimage could probably do with a top-level index header with wordy explainy things, like releases but backwards.
<dobey> or *gasp* cdimage could have all the images ;)
<dobey> but meh
<infinity> "Here's where we host ports arches, unsupported images, and daily builds, for Canonical-supported x86 images, go -> here"
<infinity> It perhaps could do.  But then people might start using it as their primary download source.
<infinity> Which would be expensive.
<infinity> The point of releases/archive versus cdimage/ports is that the former is what 95% (99%?) of our users use, so it's a small set of bits, widely-mirrored.
<dobey> well, could have redirects to releases. the "physical" location of the ISOs i don't care much about. just want one listing of everything :)
<dobey> yeah, i get that. i'm not complaining (much). just confused whenever i go there and don't remember the split
<dobey> so meh
<dobey> anyway, time for me to fly, as it were. later :)
<nacc> so puppet is failing in z-p (has been for some time) because (I think) `puppet cert print $(hostname --fqdn)` complains about no certificates. I'm not sure how this is supposed to work if there's no guarantee that certificates are installed/configured somewhere in the tests themselves and I can reproduce this in a Sid lxd (although ci.debian says it did pass there before)
<nacc> I'm not entirely sure what is recommended here
<nacc> are quote exceeded messages in autopkgtest logs a concern? e.g. the linux autopkgtest for pciutils (https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-zesty/zesty/amd64/l/linux/20170217_124537_d30e3@/log.gz)
<nacc> ogasawara: --^ or is the RTC timeout a known issue for the kernel test?
#ubuntu-devel 2017-02-18
<Laney> nacc: it should retry until it gets an allocation
<nacc> Laney: ok, that's what I figured
<Laney> some tests require m1.large instances, and it's possible for others to sneak in underneath them
<nacc> Laney: sure
<Laney> AFAIK the linux failures are real ones
<nacc> Laney: yeah, I don't think they are strictly related to the packages in question, but it does seem to be a real failure
<Laney> Mmm - I think that it was allowed in at some point and now it continues to fail when triggered by other things
<Laney> Or something like that
<nacc> Laney: sounds about right
<xnox> nacc i am confused about it too
<Unit193> xnox: I don't suppose you'd care to comment on LP 643623?
<ubottu> Launchpad bug 643623 in ubuntu-keyring (Ubuntu) "Should ubuntu-keyring include the debug archive key?" [Undecided,Confirmed] https://launchpad.net/bugs/643623
<jbicha> pitti: it looks like you can drop the badtest hint for gjs/armhf, no idea what's not working with s390x
<jbicha> (gjs 1.47.90 was broken until -0ubuntu3)
<doko> rbasak, caribou: that most likely comes from -O3. either adjust the symbols files, or force to build with -O2 on ppc64el
<Unit193> in src:gocryptfs, disable the first patch and you fix the ftbfs.
#ubuntu-devel 2017-02-19
* SmellyPirate changed the topic of #ubuntu-devel to: * g o a t s e x * g o a t s e x * g o a t s e x * g o a t s e x * g o a t s e x * g o a t s e x * g o a t s e x * g o a t s e x * g o a t s e x * g o a t s e x *
* grumble changed the topic of #ubuntu-devel to: Yakkety Yak (16.10) Released | Archive: feature freeze, DIF | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-yakkety | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | Patch Pilots:
<musician_pro> any software developer here?
<musician_pro> I need a work collaboration
<TenFootLongBoner> musician_pro: yes, your mother is here developing software to assist her in raping pigs
<TheMuso> What is the base URL for the debug repositories? I seem to have forgotten.
<sarnold> http://ddebs.ubuntu.com/ ?
<TheMuso> sarnold: Thanks.
#ubuntu-devel 2018-02-12
<jamespage> doko: hi - so I need todo something that's going to look a bit odd
<jamespage> doko: I transitioned gnocchi to use py3 only, but that's creating a headache for deployers atm as there appears to be some use case to run multiple WSGI openstack apps in the same apache context
<jamespage> and afaict its not possible to run py2 and py3 in the same instance
<jamespage> doko: so I'm proposing to re-introduce the python-gnocchi package for these deployers - the default experience would still be py3, but its possible to get a py2 version if you really need it until we complete transtion of all packages to py3
<jamespage> thoughts?
<doko> jamespage: sure, sounds fine
<doko> jamespage: still some MIRs needed ...
<jamespage> doko: yeah on my list for today - slangasek raised them end of last week - we'll complete the details
<coolfish> Hi, on 2018/01/26 I asked for a bigger autopkgtest-VM for the package ganeti. Laney was so kind and told me, that he will add ganeti on a small list of 'big' packages. See https://irclogs.ubuntu.com/2018/01/26/%23ubuntu-devel.html.
<coolfish> However, it seems that the test-VM still has only 1536M. See log from 2018-02-11 10:00:07 UTC on http://autopkgtest.ubuntu.com/packages/g/ganeti/bionic/amd64 with error message: error type: insufficient_resources, error details: Not enough memory on node node1 for creating instance instance1: needed 1024 MiB, available 792 MiB.
<coolfish> ganeti is in proposed and we as the ganeti community don't like to miss the 18.04 release! So I kindly ask for someone who can set a bigger test-VM for ganeti.
<jamespage> doko: ok completed https://bugs.launchpad.net/ubuntu/+source/pysmi/+bug/1748572 but I think that's going to need security team input
<ubottu> Launchpad bug 1748572 in pysmi (Ubuntu) "[MIR] pysmi, pycryptodome" [High,New]
<notsgnik> Hello, i'm using ubuntu bionic beaver daily build freshly installed yesterday and i'm running into trouble with ipv6 :/
<notsgnik> i tried to disable it but it don't
<notsgnik> here what i've tryed https://notehub.org/bs63x
<notsgnik> four diferent things and it is still up oO!?
<juliank> notsgnik: hey, the help channel for development versions is #ubuntu+1
<notsgnik> juliank, sorry :p
<rbasak> !dmb-ping
<ubottu> bdmurray, BenC, cyphermox, jbicha, micahg, rbasak, sil2100: DMB ping.
<tseliot> ginggs: hi, if you feel adventurous enough to test my packages (which should build soon), here they are (I haven't tested the upgrade path from the 384 series yet): https://launchpad.net/~canonical-x/+archive/ubuntu/testing
<ginggs> tseliot: thanks - will test upgrading from 384
<tseliot> ginggs: ok. I haven't provided transitional packages yet, but let me know how that goes
<jbicha> slangasek: good morning, please ping me when you're online
<ginggs> tseliot: doing 'sudo apt install nvidia-driver-390 nvidia-compute-390 nvidia-utils-390 xserver-xorg-video-nvidia-390
<ginggs> ' now...
<tseliot> ginggs: nvidia-driver-390 should pull in everything
<ginggs> tseliot: i tried that first, but then got 'nvidia-driver-390 : Depends: nvidia-compute-390 (= 390.25-0ubuntu1~ppa1) but it is not going to be installed' and the same for -utils- and -xorg-video-
<tseliot> ginggs: yes, well, I haven't tested that with the old packages installed
<superm1> these days is the backporters team still reviewing backports?  Or are we supposed to upload them and AA will review them at upload time?
<slangasek> jbicha: hello
<jbicha> slangasek: I emailed you this morning about Debian #887087, that fix is being requested by the GNOME Release Team
<ubottu> Debian bug 887087 in libfreetype6-dev "ftconfig.h:113:26: warning: "__SIZEOF_LONG__4" is not defined, evaluates to 0 [-Wundef]" [Serious,Open] http://bugs.debian.org/887087
<slangasek> jbicha: hmm ok :)
<slangasek> jbicha: I did tell people I was going to try to get that done last week... and didn't.  I'll see what I can do today
<jbicha> thanks :)
<jbicha> I was surprised that GNOME was affected by it too
<xevious> nacc: What's the status of the PHP 7.2 transition? I just made a new system image with Bionic and PHP. I asked it to install php-cli and it installed php7.1-cli. If I try to install XDebug, it's attempting to pull in PHP 7.2 packages.
<nacc> xevious: yeah, we're about midway? :)
<nacc> 7.2 is now in
<nacc> xevious: bug php-defaults has not migrated yet
<nacc> since i have to fix all the 7.2 regressions first :)
<xevious> I saw the "excuses..." page. There are quite a few of them.
<nacc> xevious: i think i have a fix for symfony
<xevious> Particularly Horde... Does anyone actually still use Horde?
<nacc> (basically removingn packages that debian is going to remove)
<xevious> nacc: Is there anything I can do to help?
<nacc> xevious: probably? i'm just getting myself back up to speed right now, as i find stuff
<nacc> i'm hoping to unwedge phpunit today
<xevious> Yeah, I spoke to rbasak last week and he said you were out. When you're done sifting through all your emails and whatnot, let me know if you've got any work that can be split up. I've got a lot of experience with Debian packaging, although not for any official repos.
<nacc> xevious: great, thanks!
<nacc> yeah, phpunit going through will unlock 15-20 packages on its own
<nacc> symfony will unlock a few more, too
<nacc> then i was planning on php-defaults, which would allow us to remove 7.1
<xevious> php-defaults and libvirt-php are what are blocking me right now.
<nacc> xevious: ok libvirt-php shouldl have worked, but seems to have ftbfs on ppc64el, retriggering it now
<xevious> Thanks
<nacc> xevious: sorry about that, i had retriggered the others, but must have missed that one
<xevious> No worries. Glad that one was such an easy fix. :)
<Pharaoh_Atem> nacc: did you get my email a couple weeks back about libvirt-php?
<Pharaoh_Atem> and if there's anything I can do to help, let me know
<Pharaoh_Atem> it'll be like last time around ;)
<Pharaoh_Atem> except hopefully I won't be porting a PHP extension at the last second again :P
<nacc> Pharaoh_Atem: i did, but had forgotten about it! We are at 0.5.4-1 in b-p
<Pharaoh_Atem> do we know when that will flush out to bionic?
<nacc> thanks to xevious' ping, it's built now on all arches, should migrate ok on its own
<Pharaoh_Atem> awesome
<Pharaoh_Atem> it'd be fantastic if that could be migrated out asap
<Pharaoh_Atem> it's blocking some stuff on my end
<hjd> Are there any particular tags to use in bug reports or teams to tag regarding packages with circular dependencies, like bug 1748755? :)
<ubottu> bug 1748755 in node-gulp-babel (Ubuntu) "Circular dependency between node-babel and node-gulp-babel" [Undecided,New] https://launchpad.net/bugs/1748755
<xevious> nacc: Should composer be listed on this page? http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
<michagogo> Hi, I'm trying to do a bit of backporting into my PPA to test and running into an issue. gcc-mingw-w64 says it's missing binutils-mingw-w64 as a dependency, and then when I went to backport that, it says it's missing binutils-source
<michagogo> I see binutils-source comes from binutils, but when I try to backport _that_ it seems to fail
<michagogo> https://www.irccloud.com/pastebin/dFgEDKXz/
<michagogo> Does anyone have any idea how to fix this?
<sarnold> michagogo: wild guess, copy aside the most recent dozen entries in the debian/changelog, and when running dpkg-source -b ... pass in -l path/to/shorter/changelog
<michagogo> How do I do that? I'm using backportpackage
<sarnold> oh.
<michagogo> I don't see an option that looks like the equivalent there.
<michagogo> Hmm, it also said it wants g++-7
<michagogo> Tried pushing *that* up there, and now it wants even more stuff
<michagogo> I suspect this is going down a bit of a rabbit hole... am I doing the wrong thing?
<michagogo> (this is the PPA: https://launchpad.net/~michagogo/+archive/ubuntu/backport-mingw/+builds?build_text=&build_state=all )
<nacc> hjd: no tag i know of, it needs bootstrapping?
<nacc> hjd: i think you'll want to talk to the AAs for that
<nacc> xevious: no, composer 1.6.2-1 is in bionic already
<nacc> xevious: or do you mean it needs a rebuild?
<xevious> nacc: I see. It's not on that page since it didn't change (only its dependencies did).
<nacc> xevious: right
<hjd> nacc: Yes, looks like it needs bootstrapping. Both packages are currently waiting for the other.
<hjd> AAs would be the archive admins, right? I can try to subscribe them to the bug report, perhaps?
<nacc> hjd: yeah ~ubuntu-archive
<michagogo> Hm, looks like if I try to just do it from artful it only gets stuck on gcc-6-source
<michagogo> Maybe that would work better?
<hjd> nacc: Got it, thanks :)
<jbicha> hjd: btw, it's possible to bootstrap node packages without being an AA
<michagogo> (Could someone perhaps tell me if what I'm trying to do makes any sense, or if I've taken myself on a wild goose chase?)
<doko> mitya57: python3-docutils autopkgtest needs 2to3 dependency as well
#ubuntu-devel 2018-02-13
<Mirv> thanks LocutusOfBorg for vlc 3.0 in bionic :)
<Skuggen>  Will bionic generate dbgsym packages automatically?
<Unit193> Uhh, Ubuntu has been doing that since about edgy.
<Unit193> So, yes.  Bionic will too.
<Skuggen> I mean debhelper, for third-party builds, not what Ubuntu's build hosts do
<Skuggen> i.e. What Debian Stretch does that Debian Jessie did not
<Unit193> Using debhelper rather than pkg-create-dbgsym?  Yes that's already been changed, though I doubt it matters for the resulting dbgsym package.
<Unit193> ...OK, I need to read better.  Sorry, yes.  This can already be done and has been for a little while (though in the past you could install that package.)
<LocutusOfBorg> Mirv, you are welcome :) I'm sad for the missing chromecast support
<Unit193> ricotz: Out of curiosity, do you do anything or know of anything done with libdvdcss?  I saw it in pkg-multimedia a bit ago.
<ricotz> Unit193, I don't think it qualifies to be uploaded in the official archives
<Unit193> Correct, it does not.
<didrocks> xnox: I have a small ubiquity question once you are around: does the "recursive" property of record_removed() will remove all unused rdepends or just depends ? (It sounds like get_remove_list() only does cache._depcache.broken)
<didrocks> xnox: and there is no apt autoremove at the end of the installation, correct?
<Skuggen> Unit193: Thanks, what I mean is just whether dbgsym-files would automatically be created when running debuild. We (upstream MySQL) made some packaging changes for non-Stretch to replicate its behavior, and I noticed lintian is complaining about it in Bionic. We never used pkg-create-dbgsym (since as far as I know it's Ubuntu-specific)
<Unit193> Skuggen: Yes, dbgsym packages as created by debhelper are default, like in Debian.
<Skuggen> Thanks (just means we have to drop that change from the upstream 18.04 packages) :)
<Unit193> Skuggen: Note that Ubuntu's will have a *.ddeb extension though.
<Unit193> https://patches.ubuntu.com/d/debhelper/debhelper_11.1.4ubuntu1.patch that's the difference between debhelper in Debian and Ubuntu, pretty minimal now.  Not sure why we exclude changelogs though.
<Skuggen> Unit193: Ah, that might actually matter, since our systems might just handle *.deb, thanks
<doko> jamespage: http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg   what have both python-libnacl and python-nacl?
<jamespage> doko: you might be asking the wrong person about that bit
 * jamespage looks
<jamespage> but I agree having both seems a little silly
<doko> hmm, no they seem to be something different
<doko> roaksoax: ^^^
<mvo> xnox: do you mind if I upload http://paste.ubuntu.com/p/vR7hNwZSkt/ to bionic? this fixes an issue we have with snapd caused by a dbus/apparmor mediation change (cc jdstrand, feel free to weight in here)
<xeon_kyo> hi all i need a bit help about writing bash , does somebody know bash writing here?
<juliank> xeon_kyo: I suggest you ask in #bash, this channel is about developing ubuntu
<juliank> unless of course, it's an Ubuntu-specific bash question
<mdeslaur> sil2100: do you have an exim4 merge planned soon?
<mdeslaur> xnox: FYI, I'm switching clamav to 0.99.3 final
<juliank> Did anyone hear something about s2disk (or rather, resume) breaking in a recent xenial update?
<mdeslaur> juliank: the reverted intel microcode update was causing S3 problems
<juliank> mdeslaur: I don't think there even are any microcode updates for Core i*-3* yet
<juliank> latest updates were today
<juliank> will do some more investigation
<roaksoax> doko: TBH, no idea as i've not looked at what the differences are, but will take a look
<doko> roaksoax: maybe you could ask cjwatson about the differences in python-nacl and python-libnacl, he is one of the Debian uploaders
<roaksoax> doko: that's what I waas planning on doing :)
<cjwatson> different upstream projects with incompatible APIs
<cjwatson> more or less similar functions
<cjwatson> but AIUI switching from one to the other is basically a rewrite
<cjwatson> not my fault :P
<jdstrand> xnox (cc mvo and tyhicks): +1 for the systemd change. fyi, tyhicks and I are going to revisit the upstream dbus changes so there is a possibility at some point we can drop this later in the cycle, but that all depends on what happens with upstream dbus
<michagogo> Hey, can someone help me understand something? I'm trying to see if I can backport mingw-w64 from bionic (or artful?) to xenial, since the xenial version is badly broken
<michagogo> Trying just a plain `backportpackage` into a PPA didn't really work, all kinds of dependency issues
<raanst> michagogo what kind of dependency mingw-w64 want?
<michagogo> One sec, let me look again
<michagogo> Actually, mingw-w64 worked fine, but gcc-mingw-w64 wanted binutils-mingw-w64. I tried to `backportpackage` that, and it failed because it needed binutils
<michagogo> When I tried binutils, it failed with this error: https://www.irccloud.com/pastebin/dFgEDKXz/
<michagogo> In addition, gcc-mingw-w64 wanted gcc-7
<raanst> Maybe it's stupid, but why You have computer date at 1999?
<michagogo> Eh? I don't.
<michagogo> I'm not Christopher, either.
<raanst> dpkg-genchanges: warning:     debian/changelog(l7258): cannot parse non-comformant date '18 Sept 1999 01:21:05 -0400'
<raanst> Okay, nevermid
<raanst> nevermind
<raanst> Are You try install binutils from tar.gz file?
<michagogo> All I used was `backportpackage`. That was the command that failed with that error I pasted above.
<cjwatson> you might just need to edit the changelog manually then and rerun that dpkg-buildpackage command
<cjwatson> or run it with a different -v argument
<michagogo> cjwatson: How do I do that? I have ~no experience with Ubuntu packaging
<cjwatson> this will probably be too difficult a task then
<michagogo> I'm not even sure if what I'm doing makes sense, or if I'm leading myself on a wild goose chase by trying to just `backportpackage` anything it says is missing
<cjwatson> the changelog is in debian/changelog, and the dpkg-buildpackage command was in your paste (run in the temporary directory that backportpackage created)
<michagogo> Maybe it's just a matter of editing the original gcc-mingw-w64 package to call for an older version or something?
<cjwatson> you are probably in for a bad time in backporting a bunch of toolchain packages with no packaging experience, but OTOH there's probably little alternative if you want to backport mingw-w64, so ...
<michagogo> Is it just that I don't have experience? Meaning, would it be particularly hard/complex for someone who does know what they're doing?
<cjwatson> a toolchain backport is always a bit of an unknown quantity
<cjwatson> it might just be this one changelog bump in the road, or it might be a task that requires intimate understanding of binutils ...
<michagogo> Hmm. I was hoping that it might be simpler because it's not something that's used on the system itself, but rather just for cross-compiling
<michagogo> But OTOH maybe that's completely misguided
<cjwatson> you could certainly start by just fixing the changelog syntax and building the source package with that, but I have no idea how many other complexities there'll be
<cjwatson> and you WILL have to be prepared to do some research for yourself (e.g. looking up how to edit a changelog is going to be one of your easiest tasks here)
<michagogo> My end goal here is that I'm trying to find a way to allow people to build Bitcoin Core on Xenial
<michagogo> Right now, the build docs say to edit the apt sources file to pull from the... zesty, I think? repository and apt-get upgrade
<michagogo> And I know enough to know that that's... inadvisable
<cjwatson> a chroot would no doubt be possible
<michagogo> Last I heard, chroot wasn't implemented in WSL...
<cjwatson> cryptocurrencies and WSL are two things I know little about and am not interested in learning, so good luck :)
<michagogo> And in any case, I fear that may be too complicated
<michagogo> I mean, we already have gitian for building in a VM/LXC container
<michagogo> Heh, no need to learn about cryptocurrencies :-P
<michagogo> You can replace 'Bitcoin Core' with 'Some arbitrary package that fails to build with the Xenial version of g++-mingw-w64'
<michagogo> (Which, actually, _might_ actually be "all software" - I don't remember exactly what the problem was, but I think it was something pretty fundamental...)
<michagogo> Does anyone know if there's a general guide somewhere to backporting packages that do need to be changed and can't just be built as-is? Even a step-by-step explanation of what `backportpackage` actually does, so I can read and learn what the steps are, and figure out where to step in and change things?
<michagogo> I'm hoping (perhaps in vain?) that if I just change the dependencies to the GCC that's in Xenial it might work
<rbasak> michagogo: backportpackage is a pretty small script
<rbasak> I don't think it does much apart from tweak the changelog for you.
<michagogo> Yeah, I saw. It would be nice if it were in bash
<michagogo> But I see that it's all python using various libraries
<rbasak> No thanks. Doing it in bash would be a little insane IMHO.
<michagogo> Yeah, I didn't mean that I think the script should be in bash
<michagogo> I assume that the process can be accomplished using a series of commands
<michagogo> Hm
<michagogo> Maybe I'll just throw pdb in there>
<rbasak> Still, you'd have manipulate version string components.
<rbasak> You'd end up writing a tool to do the manipulation and call that from bash.
<rbasak> And we have that tool already - it's called backportpackage :)
<michagogo> rbasak: Yeah, the thing is right now I'm trying to do a non-no-change backport
<rbasak> michagogo: you know about debdiff, right? Run backportpackage, see what it did with debdiff, then throw away backportpackage and handle the changes you need manually.
<michagogo> And I didn't see a flag to backportpackage that says "give me the opportunity to change something"
<michagogo> Debdiff?
<rbasak> http://manpages.ubuntu.com/manpages/xenial/en/man1/debdiff.1.html
<michagogo> The thing is, I have ~no Ubuntu packaging experience
<rbasak> Run it against two dsc files.
<cjwatson> backportpackage leaves its stuff around in a temporary directory
<cjwatson> you can go and edit it if you like
<michagogo> To me, right now, backportpackage is pretty much a black box, with the end result being that the package ends up in the PPA
<cjwatson> and then build the source package and upload it to the PPA manually
<cjwatson> it writes the dpkg-buildpackage command it uses to build the source package to its output, so you can copy and paste that
<rbasak> OK, so here are some pieces that I think you should learn: 1) how to get from an unpacked debian source tree to debian source package files (dsc, debian.tar.gz, changes).
<rbasak> 2) how to unpack debian source package files into a directory
<rbasak> 3) how to build from debian source package files a set of debs locally.
<rbasak> 4) how to compare changes
<rbasak> 5) how to upload to a PPA
<rbasak> Once you've got that you should generally know what questions you need to ask I think.
<cjwatson> rbasak speaks wisdom.
<rbasak> Quick lookup: 1) dpkg-buildpackage; 2) dpkg-source -x; 3) sbuild (and mk-sbuild); 4) debdiff; 5) dput
<rbasak> There are details and nuances with all of that and I have made some deliberate mistakes there in the interest of my summary
<rbasak> But hopefully that's enough to get you started so you know what docs to look up
<rbasak> After you've got to grips with those, you should see that backporting is really just a case of grabbing a source package and changing it as needed (just debian/changelog for a no-change backport, and more for other changes as needed) and uploading it again.
<cjwatson> pull-lp-source is worth knowing about too.
<rbasak> FWIW, nacc and I are working on a tool that makes all of this much easier, but I'm not sure I'd recommend newcomers to using it yet, because there are still many rough edges
<rbasak> +1
<cjwatson> all of these things have fairly decent man pages, plus https://wiki.ubuntu.com/SimpleSbuild and https://help.launchpad.net/Packaging/PPA
 * juliank really wants lxd sbuild
<rbasak> juliank: "git ubuntu build" roughly works and does it in lxd.
<juliank> I have two options: Fix the autopkgtest backend to actually work, or write a separate lxd backend. I think the latter is easier, I already have a docker backend :)
<juliank> rbasak: well, yeah, but it's not sbuild :D
<rbasak> I don't think we're ever going to match feature parity with sbuild. Like you say, adding a lxd backend to sbuild would be better I think.
<juliank> rbasak: and well, most stuff is not in git-ubuntu repos
<rbasak> juliank: we're working on fixing that :)
<juliank> rbasak: In theory, sbuild should be able to use lxd via it's autopkgtest virt-server integration. In practice, it just hangs or fails with weird errors.
<rbasak> juliank: OOI (not that we're going to implement them), what does sbuild have that you would miss the most with git ubuntu build?
<juliank> I'm not sure I'm missing something specific.
<juliank> But I'd also like to use sbuild for debian builds and stuff
<juliank> and being as close to a build server as possible is a bonus there
<juliank> I think LP also uses _some_ sbuild
<cjwatson> LP uses stock sbuild
<cjwatson> only a few modifications these days and they're all wrapped around the standard package; see lp:launchpad-buildd, lpbuildd/binarypackage.py and sbuildrc
<cjwatson> well, and bin/sbuild-package
<juliank> the chroot is managed outside of sbuild in launchpad though AFAICT from build logs
<rbasak> I didn't think sbuild managed its own chroots anyway?
<rbasak> mk-sbuild isn't in the sbuild package for example
<rbasak> (although sbuild-update is)
<juliank> well, it has backends for chroot-like things
<juliank> _normally_ it's used with schroot
<rbasak> Oh, I see. That sense of "manage" :)
<juliank> there are schroot, sudo, and autopkgtest backends
<juliank> I guess LP uses the sudo one then
<juliank> I also have a docker one, and am thinking about writing a lxd one
<juliank> the docker is prototype-y, though
<jbicha> there's also a sbuild-launchpad-chroot package that is useful
<juliank> I don't want to build in chroots, because they are crazy insecure
<michagogo> What does it mean when the Build-Depends line contains e.g. "mingw-w64-i686-dev <!stage1>"? I tried looking for the dsc file syntax, but a couple pages I saw didn't say anything about the <!stage1> part of the syntax
<juliank> michagogo: these are build profiles, for bootstrapping new architectures
<juliank> so you can have a stage1 with the least features compiled in, then a stage2 with more, ...
<juliank> in order to resolve cycles
<michagogo> Oh, for cases of circular dependencies etc.?
<michagogo> I see.
<michagogo> Now I'm confused about the version numbers of gcc-mingw-w64
<michagogo> They're numbers like 17, 19.3, 20.2
<michagogo> Those don't look like software version numbers
<juliank> why not?
<juliank> have you seen systemd's version?
<michagogo> I mean, they don't look like they're version numbers for MinGW, which is at 5.0.3
<juliank> right
<michagogo> Or GCC, which is at 7.x.x (or 6.x.x or 5.x.x or whatever)
<cjwatson> juliank: no, LP uses the schroot backend
<juliank> cjwatson: interesting
<michagogo> Now I'm starting to think I may not actually understand what the gcc-mingw-w64 package is...
<juliank> michagogo: The binaries have a different version number.
<juliank> michagogo: So, the gcc-mingw-w64 package probably build-depends on gcc-source and compiles gccs from that
<cjwatson> juliank: The main oddity is that we use schroot type=plain and do the setup/teardown ourselves
<juliank> and then it generates packages like gcc-mingw-w64 with versions like 7.2.0-20ubuntu1+20.2
<cjwatson> juliank: But then the actual entry to the chroot is done using schroot (which means we get its ability to reliably kill a session, which sbuild's sudo mode couldn't do)
<michagogo> Hm... so if it build-depended on, say, gcc-5-source rather than gcc-7-source, it would produce GCC 5 binaries, with the newer MinGW code?
<michagogo> Dammit, I think this is turning into "Micha doesn't understand the relationship between GCC and mingw-w64"
<cjwatson> The way I would answer that question would be by going to https://tracker.debian.org/mingw-w64, which links to https://anonscm.debian.org/cgit/collab-maint/mingw-w64.git, grabbing that git tree locally, and then looking back through its history to see if the Build-Depends change to gcc-7-source was accompanied by any other changes
<cjwatson> That sort of approach is usually a good strategy for "help, I need to unwind this complicated new build-dependency for a backport, but I have no idea what else I might need to unwind at the same time"
<michagogo> cjwatson: the Build-Depends on gcc-7-source is in gcc-mingw-w64, not in mingw-w64
<rbasak> michagogo: gcc-mingw-w64? Sounds like you're diving in at the very deep end there.
<rbasak> michagogo: I would step back and consider your approach. I don't know what problem you're solving, but there might be an easier way.
<michagogo> Yeah, I'm thinking more and more that I'm looking at something much more complex than I hoped
<michagogo> My starting point is this
<michagogo> The version of mingw-w64 (or maybe it's g++-mingw-w64? I don't think I understand well enough how the different projects interact) in xenial is very broken
<cjwatson> michagogo: ok, substitute the starting URL accordingly then
<michagogo> It produces binaries that don't work, Leading to a certain project having instructions in the build guide to change apt sources in a xenial environment to point to the zesty repos and upgrade
<michagogo> Which, if I'm not mistaken, is a very effective way to hose your environment.
<rbasak> Zesty is EOL now.
<rbasak> But you can usually fire up a lxd container and use a newer release to run a build just fine.
<rbasak> No need to hose the host system.
<michagogo> The build process for releases just uses a Trusty container to get around that issue, but it's desirable to have a way to build without all that
<rbasak> Also, if the reason it doesn't work in Xenial is due to a bug, we're quite happy in general to cherry-pick the fix for all Xenial users to benefit.
<michagogo> (One example being Windows users, who want to use WSL, which doesn't have containers or chroot afaik)
<rbasak> Can they not use WSL with a different Ubuntu release?
<Odd_Bloke> rbasak: We only provide xenial WSL images.
<Odd_Bloke> You can upgrade the environment, but then you're on your own.
<michagogo> AFAIK you're not given a choice as to which version to download
<rbasak> Ah, OK
<michagogo> And ISTR that do-release-upgrading breaks things
<mvo> slangasek: hey, who should I talk to about a systemd fix? I have a debdiff ready (http://paste.ubuntu.com/p/W2w883BFgR/) and would love feedback if its ok to upload or if I should follow a different process (PR or somesuch)
<nacc> mvo: i'm told elsewhwere that slangasek is away today and tmrw
<mvo> nacc: aha, thank you
<nacc> mvo: np, i wonder if xnox is around (although late for him)
<juliank> nacc: it's earlier for xnox than for mvo :D
<juliank> but I have not seen him
<juliank> that said, a lot of people do not respond on IRC today :)
<juliank> mvo: I would not do anything with systemd right now. it's stuck in the cryptsetup transition with test failures
<juliank> I think xnox wanted to investigate them
<mvo> juliank: ok, thank you
<nacc> juliank: :) i never know anymore
<michagogo> I think Iâm probably not going to keep pursuing this right now, but:
<michagogo> That stage1 stuff in the build-depends that we talked about earlier, is that also relevant for PPAs?
<michagogo> Meaning, if I wanted to upload packages with circular dependencies to a PPA, would that work
<michagogo> ?
<nacc> michagogo: i believe PPAs don't have build-profiles exposed
<nacc> michagogo: so you can't do the bootstrap in a PPA, except by hand (e.g., drop the stuff you don't need to get pkg1 built, then build pkg2, then rebuild pkg1 re-adding what you dropped)
<cjwatson> That's correct.  It's a feature that might be worth adding in the feuture.
<cjwatson> *future
<juliank> cjwatson: what was that?
<cjwatson> the ability to configure a PPA to build with certain build profiles
<juliank> um, yeah, I meant the <DEL> character
<cjwatson> err, dunno, something lag-induced
<juliank> cjwatson: did you restart ddeb-retriever or did it finish?
<juliank> in any case, we do have bionic-updates now :)
<cjwatson> I didn't touch it except to deploy your change; I think it finished
<juliank> Ah I guess it did not get yakkety,viid,zesty back from LP and hence did not regenerate them or something
<juliank> I'm always amazed at how easy some things are too fix
<tsimonq2> build-profiles in PPAs> That would be SUPER useful for Qt transitions.
<juliank> tsimonq2: ooi how do you use build profiles for qt transitions?
<tsimonq2> juliank: The base Qt packages have circular dependencies with the doc packages. If we had access to build with specific profiles, we'd go with nodoc for the first run and then from there unset nodoc and rebuild the packages one more time.
<xevious> nacc: How's phpunit coming along? Is there anything I can help out with for php-defaults while you're working on that?
<nacc> xevious: just working on monolog and then it should be good
<nacc> xevious: if you can look to see any of them need retriggers, (e.g., the packag that was tested has already been updated in bionic-proposed or bionic), that would be helpful. Or if any need an update from Debian.
<nacc> that's usually my first step
<xevious> Yeah I can do that.
<nacc> xevious: thanks, just ping me with what you find
<juliank> tsimonq2: interesting
<michagogo> rbasak/juliank/cjwatson: Thanks for your help. I also discussed the issue a bit with people who have a bit more understanding and think I have a slightly better idea of this whole story. I think I'm going to drop the issue for now, since I don't think I have enough time to learn enough about the various topics involved and get into it. On the horizon for Bitcoin Core specifically, we want our build tooling to optionally create and use its
<michagogo> own toolchain, in order to be independent of Ubuntu (and other distro) packaging-related issues like this.
<michagogo> Maybe at some point in the future I'll look into it again as a learning opportunity...
<michagogo> And I mean, in the meantime mingw-w64 is broken for everyone, it's not just us, but...  ð¤·ð½ââï¸
<jbicha> juliank: did you see LP: #1747033 ?
<ubottu> Launchpad bug 1747033 in apt (Ubuntu) "transitional package dependency shouldn't be auto-removable" [Undecided,New] https://launchpad.net/bugs/1747033
<juliank> jbicha: Oh, well, the package is in the wrong section
<juliank> it needs to be in oldlibs
<jbicha> juliank: is that the only problem there?
<juliank> jbicha: yeah, if its in oldlibs, gnome-tweak-tool becomes autoremovable, and gnome-tweaks gets the bit gnome-tweak-tool had before
<jbicha> if so I'll reassign to gnome-tweaks and look for an AA to help
<juliank> jbicha: Sorry I was confused last time I looked at it
<juliank> and then I forgot about it
<juliank> magic!
<mdeslaur> infinity, kees, stgraber, slangasek: TB meeting?
<xevious> nacc: Caught up with tickets. Got about 30% done writing a script to check for things needing retriggers.
<nacc> xevious: nice :)
<xevious> I'm getting back to that now.
<Unit193> Debian #890287, #890288.  Fun.
<ubottu> Debian bug 890287 in src:mbedtls "mbedtls: CVE-2018-0488 - Risk of remote code execution when truncated HMAC is enabled" [Grave,Open] http://bugs.debian.org/890287
<ubottu> Debian bug 890288 in src:mbedtls "mbedtls: CVE-2018-0487 - Risk of remote code execution when verifying RSASSA-PSS signatures" [Grave,Open] http://bugs.debian.org/890288
<nacc> xevious: once php-monolog (just uploaded) is published, I can retrigger phpunit's tests and should be able to pick up wherever you are on php-defaults
<powersj> nacc: Is this still the best guide for git-ubuntu + workflow? https://wiki.ubuntu.com/UbuntuDevelopment/Merging/GitWorkflow
<xevious> nacc: I've been juggling a number of things today. I should have that script shortly. I'll drop it in a snippet or gist or something when it's ready.
<xevious> nacc: Can I PM you to confirm some details?
<nacc> xevious: ack
<nacc> powersj: the manpages of the snap are probably a bit better
<nacc> to enable them, LP: #1699526
<ubottu> Launchpad bug 1699526 in usd-importer "Extra steps needed to enable manpages in snap" [Low,Triaged] https://launchpad.net/bugs/1699526
<nacc> powersj: (although i believe that i need to revisit that with some upstream changes recently in snapd)
<powersj> nacc: thx!
<nacc> powersj: np, i think the merge manpage is basically that wiki page still, but it's supposed to be the place to go
<nacc> powersj: also use the beta snap
<powersj> ah was on edge
<nacc> powersj: edge would be fine
<nacc> just a bit less stable :)
<nacc> edge should be ok (I thikn that's what i am using)
<nacc> note that some repos are currentlly ... in flux :)
<nacc> because of our importer changes
<nacc> powersj: if you hit issues, let me know, i can walk you through how to workaround them
<powersj> nacc: ok thanks again
<nacc> np
<nacc> xevious: retriggering php-monolog now
<xevious> Great.
<nacc> xevious: i *think* that will also get a bunch of stuff in php-defaults through
<nacc> because it's all the phpunit entangled packages that cause those mismatches
<nacc> xevious: cacti just got fixed in debian, it *should* sync down once it builds/publishes there
<xevious> Great.
<xevious> How long does that usually take?
<nacc> hopefully it will be done or in progress when i wake up trmw
<nacc> *tmrw*
<nacc> xevious: since you're still collecting data on php-defaults, i might try and get php-horde-test through, since that will unblock the rest of horde probably
<xevious> Ok. I'm about to publish a gist with the script and the current results.
<nacc> xevious: thanks
<xevious> nacc: https://gist.github.com/iammattcoleman/88013cb5f92105b15a66ee2ada442a16
#ubuntu-devel 2018-02-14
<nacc> xevious: thanks
<nacc> xevious: fyi, cacti just synced, it's running its tests now
<xevious> I found an issue with version parsing (see mediawiki), so I'm fixing that and rerunning.
<xevious> ETA for that to hit bionic-proposed?
<nacc> xevious: it's there now, i'm retriggering php-defautls nnow
<xevious> Oh great.
<nacc> xevious: monolog is also fixed (in b-p), and it should migrate with phpunit
<xevious> That covers everything I looked at so far.
<nacc> xevious: thanks for all your help. I'll probably be EOD soon, but after some other work tmrw AM, I will pivot back to your script's output
<xevious> Once I have the 'excuses...' parsing issue sorted out, I'll update the gist with the current output and copy of the script.
<nacc> xevious: thanks again
<xevious> Glad I can help. :)
<xevious> nacc: I updated the gist (https://gist.github.com/iammattcoleman/88013cb5f92105b15a66ee2ada442a16)
<xevious> nacc: I just noticed php-codesniffer updated to version 3.2.2 in my script's output. They just introduced a new way of annotating overrides for PHP_CodeSniffer and there have been a few regressions. At least some of them will be fixed in 3.2.3.
<xevious> (3.2.3 should be out this week)
<nacc> xevious: ok, i can also backport it this week, if that ends up being the only thing blocking us :)
<lotuspsychje> morning to all
<lotuspsychje> im suffering this weird bug on 1 xenial machine, could you have a look? https://bugs.launchpad.net/ubuntu/+source/linux-hwe/+bug/1749237
<ubottu> Launchpad bug 1749237 in linux-hwe (Ubuntu) "External usb 3.0 harddisk not detected by default on 16.04.3" [Undecided,New]
<cpaelzer> pitti: I remember on the postgres MREs that we always had the armhf issues since the switch of lxc to lxd
<cpaelzer> I wanted to mask the relaed tests now
<cpaelzer> bug 1748161
<ubottu> bug 1748161 in postgresql-9.5 (Ubuntu) "improve britney hints for postgres MREs" [Undecided,New] https://launchpad.net/bugs/1748161
<cpaelzer> rbasak: found that the actual fix would be very small actually https://anonscm.debian.org/cgit/pkg-postgresql/postgresql-common.git/commit/?id=fc40fc34ce
<pitti> cpaelzer: for the old releases, you mean? AFAIK I fixed the namespace issues maybe a year or two ago
<cpaelzer> pitti: was there a reason/blocker not to backport this or could I just group that with the next MRE?
<cpaelzer> pitti: yeah trusty/xenial only
<pitti> http://autopkgtest.ubuntu.com/packages/p/postgresql-9.5
<rbasak> cpaelzer: are you responding to my MP comment? Or tell me that you also found that commit? :)
<pitti> wow, since when do we have a *smiley* for errors?
<cpaelzer> rbasak: I respond to your MP comment trying to clarify with pitti if there was a reason not to bring this back to T/X
<pitti> cpaelzer: not a blocker, there just has never been a postgresql-common SRU where I could have slipped this in
<rbasak> Oh, OK
<rbasak> Carry on :)
<pitti> I didn't want to SRU p-common just for this
<pitti> but if you want to, please do of course
<rbasak> Oh, it needs an SRU to a different package?
<cpaelzer> yes
<rbasak> I hadn't realised that.
<pitti> the integration tests are in postgresql-common
<rbasak> I do have one observation though.
<rbasak> ATM, humans are still checking the armhf failure and verifying that it's just the stderr problem and nothing else. The test is still running.
<pitti> so the arm64 error is infra-related, otherwise at least http://autopkgtest.ubuntu.com/packages/p/postgresql-9.4 loosk good
<rbasak> If we force-badtest it for future MREs, then we will stop looking at the armhf test run completely, which is objectively worse.
<pitti> right
<rbasak> I could be persuaded that on balance it's not worth the effort to look manually and force-badtest all future armhf though, as the MP requested.
<rbasak> I didn't realise the SRU would need to be in a different source package. I agree it's not worth an SRU just for that.
<pitti> cpaelzer: at least precise fell off the radar by "natural cause" âº
<pitti> this looked quite poor
<rbasak> Though if postgresql-common is tiny, perhaps it could be done at the same time as a postgres MRE and it wouldn't have any meaningful impact to users.
<pitti> one more year to go for trusty
<rbasak> (if it's trivial source package)
<pitti> or 4 MREs
<pitti> rbasak: yes, it's a small arch:all package
<rbasak> Then I'm in favour of "bundling" the fix at the same time as the next SRU
<cpaelzer> ok
<rbasak> (to not-postgresql-common)
<cpaelzer> taking a note for that
<cpaelzer> rbasak: we still want to switch off mimeo thou
<rbasak> Unless someone thinks otherwise
<rbasak> cpaelzer: agreed
<cpaelzer> rbasak: I'll update the MP comment and bump it to just affect mimeo
<cpaelzer> back in a bit
<rbasak> ack
<pitti> cpaelzer: https://salsa.debian.org/postgresql/postgresql-common/commit/07ea2e63241c9806 FYI
<cpaelzer> thanks
<cpaelzer> rbasak: new MP is https://code.launchpad.net/~paelzer/britney/hints-ubuntu-xenial-postgresqlMREv2/+merge/337696
<cpaelzer> just mimeo as discussed
<rbasak> ack
<rbasak> cpaelzer: one note: when you do the next postgresql MRE, get the SRU reviewer to accept postgresql-common and want for binaries to be published before accepting the others
<rbasak> Then the dep8 test will definitely run against the new one.
<rbasak> (I don't think a versioned dependency relationship is needed here)
<rbasak> s/want/wait/
<pitti> that's not true
<pitti> dependencies are satisfied from relelase/-updates as far as possible
<pitti> you either need a versioned test dependency, or explicitly trigger the test to run against p-common in -proposed
<rbasak> Oh.
<pitti> (the latter appears better to me)
<rbasak> OK we'll do an explicit trigger
<rbasak> Thanks
<pitti> i. e. see it fail, re-trigger armhf tests against p-common in -proposed, that should succeed and also validate the p-common SRU
<pitti> although bumping the test dep in postgresql's d/tests/comtrol isn't wrong
<cpaelzer> just as I did last week with some other migrations
<rbasak> I generally shy away from bumping versioned deps to reflect bug fixes on the other side
<pitti> (except the typoed file name, of course - tpying is hrad!)
<rbasak> Seems like a recipe to madness
<pitti> yeah, and breaks the clean backports, too
<pitti> so I think manual trigger for that one round is just fine
<rbasak> Yep
<mvo> xnox: hey, just wanted to ask for your opinion on 1749000 - I have a debdiff for systemd ready (trivial fix) that would help snapd to pass tests again in bionic
<juliank> tjaalton: I think I tried reproducing your autopkgtest-build-lxd problem 2 hours ago. I don't remember doing it exactly, but I do have a freshly generated image, so I say I did it and can't reproduce it.
<juliank> What's better to use anyway, images:ubuntu/bionic or ubuntu-daily:bionic?
<tjaalton> juliank: ah, well that's weird
<juliank> tjaalton: did you retry it?
<juliank> might be timing issues...
<tjaalton> I've tried many times on two machines
<juliank> I know that other lxd stuff retries apt update a few times
<tjaalton> one bionic, the other xenial
<juliank> tjaalton: So I have the same first failure (from update), but the rest works
<juliank> So what happens is that it should do retries
<juliank> as the container's network is not fully up when it tries to run update
<tjaalton> does it try to install eatmydata on your end?
<juliank> yeah, and that works, as network is up for me at that point
<juliank>     chroot "$root" apt-get update || (sleep 15; chroot "$root" apt-get update)
<juliank> um yeah, that's not going to work
<juliank> It exits with 0, saying "They have been ignored, or old ones used instead."
<cjwatson> at various points in the past that has exited non-zero in at least some interesting failure modes
<cjwatson> we made the same change in LP (in fact autopkgtest probably got it from LP) and it basically eradicated most of the chroot-failure builds we were seeing at the time
<juliank> Well, yeah, some times it might. But I think we cleaned up some of that
<juliank> so more stuff is exit 0 now than it used to be or something
<juliank> because some stuff was wrongly classified
<tjaalton> oh, a shell script.. I'll have a look
<juliank> We also have another solution
<juliank> or not
<juliank> I thought it should set Acquire::Retries, but I'm not sure we have a time out or something, and busy retrying seems bad
<willcooke> Could someone with mailing list admin approve my subscription please?  I want to get an email out today if possible.  Cheers!
<willcooke> oh, wait, it told me I am already subscribed, but when I just posted it told me I wasn't
<seb128> willcooke, same email?
<willcooke> seb128, yeah
<seb128> no canonical vs ubuntu ?
<seb128> weird
<willcooke> I'll try and post again
<willcooke> (I cancelled the previous one)
<willcooke> Ah, ok, it's because I'm not an Ubuntu developer.  I actually read the reply this time
<willcooke> could a mod approve it please?
<cjwatson> what list?
<willcooke> cjwatson, ubuntu-devel
<cjwatson> willcooke: done
<willcooke> thanks a lot cjwatson
<Odd_Bloke> juliank: I think you were playing with ddebs, I'm seeing "E: Failed to fetch http://ddebs.ubuntu.com/dists/bionic-proposed/main/binary-amd64/Packages.xz  File has unexpected size (45916 != 38288). Mirror sync in progress? [IP: 91.189.90.217 80]"
<juliank> Odd_Bloke: updates might take some time, and are not even close to atomic
<juliank> I think I know how to fix that.
<Odd_Bloke> juliank: "Release file created at: Wed, 14 Feb 2018 13:07:11 +0000" <-- that long?
<juliank> says Date: Wed, 14 Feb 2018 15:17:46 UTC here
<juliank> ah no, wrong pocket
<juliank> Odd_Bloke: The release file is updated last, though
<juliank> Odd_Bloke: it seems to be indexing s390x now
<juliank> ah no, it's on ppc64el
<juliank> It takes about 2 minutes per architecture for main
<juliank> I want to fix it by creating dists/bionic.new and then doing mv(bionic, bionic.old), mv(bionic.new, bionic)
<juliank> but, it's not a priority
<juliank> at least that's what slangasek said :)
<juliank> I think that is testable code, thouh
<juliank> gh
<juliank> so it should be easily possible
<juliank> later maybe
<juliank> cjwatson: Is ddeb-retriever back to normal runtimes again?
<juliank> seems to be fine from what I can tell
<juliank> At least it did not update bionic-updates today :D
<cjwatson> juliank: it hasn't been complaining at me in cronmail, so I assume so
<cjwatson> I only really notice when it whinges about being unable to take its lock
<juliank> okay
<xnox> mvo, hey, that looks funky. I can include that in my next upload into bionic.
<xnox> mvo, also scary stuff =)
<juliank> Odd_Bloke: proposed should be fine now
<Odd_Bloke> juliank: It is, thanks!
<Odd_Bloke> juliank: Was there actually a problem, or was I being impatient?
<Odd_Bloke> (Or both? :p)
<juliank> you were being impatient :)
<xnox> mvo, also, will i need that in many other .service files as well?!
<mvo> xnox: when do you plan your next upload? its blocking snapd right now (its one of the autopkgtest failures we see currently in 2.31)
<mvo> xnox: probably, we only care about this one service in snapd
<xnox> mvo, today? =)
<mvo> xnox: \o/
<GunnarHj> Hi wgrant! Do you have an idea why LP refuses to import the .po files here:
<GunnarHj> https://bugs.launchpad.net/ubuntu/+source/gnome-sudoku/+bug/1734545/comments/4
<ubottu> Launchpad bug 1734545 in gnome-sudoku (Ubuntu) "Translations not updated from upstream" [High,Confirmed]
<mvo> xnox: also I'm not sure what upstream dbus will do about this, its a bit of a mess IMO, so maybe the default will be "unconfined"
<mvo> xnox: but jamie or tyler will know more
<mvo> xnox: out of curiosity, how many dbus service files are there for systemd? i mean, dbus activatable ones?
<xnox> loads.
<xnox> hostanem1 locale1 login1 network1 resolve1 systemd1 timedate1
<xnox> the only odd one out, is systemd1
<xnox> the rest can be bus activated.
<GunnarHj> wgrant: Please disregard my question for now. seb128 noticed that there was an obsolete upstream sharing link, so we have removed that link and will try a re-upload.
<seb128> GunnarHj, wgrant, well +sharing-details was still stating " Translations are not enabled on the upstream project. " and " Automatic synchronization of translations is not enabled. " so unsure if that's the issue, that part of lp translations is confusing so it would still be good to know if that is what stopped the .po to be listed for import
<Unit193> juliank: Would it make sense to call automake with --forign?  Does it do anything else other than make it a little more lax in file checking?
<juliank> idk
<Unit193> If, say, 'ChangeLog' is missing, autoreconf fails because of gnu stupidity.
<juliank> I think a lot of configure.ac seit foreign in AM_INIT or something?
<juliank> *set
<Unit193> Ooh, nice.
<juliank> I think it also needs an option in Makefile.am
<juliank> SOMETHING = foreign
<juliank> but details.......
<xevious> nacc: I updated the gist (https://gist.github.com/iammattcoleman/88013cb5f92105b15a66ee2ada442a16)
<Unit193> I wondered why autoreconf failed but autogen.sh worked on some weird package, that was it.
<nacc> xevious: thanks, phpunit migrated overnight
<nacc> xevious: note also, i only care about those that are currently marked as regressions, if that makes sense?
<xevious> You don't need to retest passed packages when there's a newer version available?
<nacc> xevious: not explicitly no (I mean, in theory, it's good), but it won't change the blocked state
<caravena> jsalisbury: Hello, My name is Cristian Aravena Romero :-)
<caravena> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1748470
<ubottu> Launchpad bug 1748470 in linux (Ubuntu) "Spectre V2 : System may be vulnerable to spectre v2" [High,Triaged]
<caravena> Is this report okay?
<tjaalton> mitya57: hi, do you have plans to upload the qt patch for bug 1749472 before FF?
<ubottu> bug 1749472 in qtbase-opensource-src (Ubuntu Bionic) "mesa 18.0.0 will cause rendering errors in Qt applications" [Undecided,New] https://launchpad.net/bugs/1749472
<tsimonq2> tjaalton: Hi, I will, yes.
 * tsimonq2 is working on the 5.9.4 transition in Bileto now
<tjaalton> great, it will take some time to get this through anyway so next week is fine for me
<tsimonq2> Worst case scenario, FF doesn't apply to things already uploaded iirc.
<tsimonq2> Sure.
<infinity> FF also doesn't apply to bugfixes.
<tjaalton> nvidia driver updates are still WIP and needed before it can land
<tsimonq2> infinity: Does it apply to ABI bumps?
<tsimonq2> i.e. I bumped ABI for qtbase for the sake of getting everything rebuilt.
<tsimonq2> But, there's no real FF violation.
<tsimonq2> tjaalton: Ah, OK.
<infinity> tsimonq2: Err, you did what?
<tsimonq2> infinity: the virtual package
<infinity> Okay, you had me mildly terrified that you were picking package names or SONAMEs out of thin air.
<tsimonq2> Hahahaha.
<tsimonq2> No.
<xevious> nacc: Has phpunit fully pushed? I see both 5.4.6-3 and 6.5.5-1ubuntu2 listed under php7.2 on the 'excuses...' page. The 6.x test is marked as a regression, but it's only because php-defaults hasn't gone through and the test script pulled in a mix of 7.1 and 7.2 packages (including php7.1-xml instead of php7.2-xml)
<nacc> xevious: yes it has
<nacc> xevious: the logs you see are presumably old
<nacc> xevious: i've not retriggered much yet
<xevious> Gotcha
<nacc> xevious: deubgging something in php-pear first (using count() on a return value from a function that can return a string or array)
<nacc> that's part of the php-defaults failures
<xevious> Yeah, that's the issue I was going to mention
<xevious> That's affecting php-console-table, php-log, php-mail-mime, and php-net-smtp.
<nacc> yep
<nacc> i am just trying to figure out what they *wanted* to do :)
<xevious> php-horde-activesync and php-horde-core are showing issues related to PHPUnit. Can you rerun those now that the new version of phpunit has pushed?
<xevious> php-crypt-chap's log is vague about its error.
<nacc> xevious: let me look
<nacc> xevious: i think horde-activesync is actually tied to horde-test
<xevious> Likely. It seems like their test class just needed to be adapted to PHPUnit namespacing everything.
<nacc> xevious: yeah, i belileve i did that already
<xevious> *needs
<nacc> it's what's in proposed, but the triggers nneed to be adjusted
<nacc> (php-horde-test, that is)
<nacc> xevious: so let's hold off on php-horde as it relates to php-defaults
<nacc> for now
<nacc> let's get everything else green or understood, and then i'll work on unwedging horde itself
<nacc> similar to phpunit, it will be easier to get horde migrated, then just retrigger the new versions in bionic
<nacc> xevious: uploading a fixed php-pear
<xevious> Aside from the Horde_Test_Case issue, the PEAR test count() thing, and the issue in php-crypt-chap, all the other regressions should be rerun using the new PHPUnit.
<nacc> ok i'll retrigger amd64 (which tends to work fastest) and see if they go green, then trigger the rest
<nacc> ok, retrigged something like 30 amd64
<nacc> i'll debug the crypt-chap one nonw
<nacc> and once php-pear publishes, i'll retrigger the dependent tests
<xevious> A few of the PHPUnit tests look like they'll have the same issue as the PEAR tests: `count(): Parameter must be an array or an object that implements Countable` We'll see after they rerun with PHPUnit 6.x
<nacc> yeah, it's a pain, because sometimes it's not in the code itself, but some dependent library
<xevious> nacc: How do you deal with php-defaults regressions that are failing because php-defaults hasn't been updated? For instance, phpunit is pulling in a mix of php7.1-* and php7.2-* packages.
<nacc> xevious: hrm, i saw the phpunit run was using an old phpunit
<nacc> xevious: so i retrigged it without anything
<nacc> xevious: as php-defaults (in that section) is already a trigger
<nacc> xevious: not sure if that answered your question
<xevious> nacc: This build failed due to php7.1-xml being pulled in instead of php7.2-xml. https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/amd64/p/phpunit/20180214_163244_07123@/log.gz
<xevious> s/build/test/whatever
<xevious> I don't think that's one of the ones you just kicked off though, is it?
<nacc> xevious: which lilnk is that from? sorry, there's lots of moving pieces
<xnox> -apt-pocket=proposed=src:php7.2 --apt-upgrade phpunit --env=ADT_TEST_TRIGGERS=php7.2/7.2.2-1ubuntu1
<xnox> that's run of phpunit, as triggered by php7.2 without the new php-defaults
<nacc> xnox: err, duh, thanks
<nacc> xevious: right, so i was just retriggering a lot of php7.2's tets, with php-defautls from proposed
<xnox> nacc, next one to migrate is php-defaults, right, or no?
<xnox> cause once that one migrates, everything else should become easier, no?
<nacc> xnox: yeah, the problem is php-defaults is probably wedged by php-horde*
<nacc> and i think i see why horde is wedged
<nacc> i'm not 100% on the why of the why, but it seems like there was a beahvior change in phpunit
<nacc> wrt the bootstrap fille
<nacc> xnox: so yeah, i'd *like* to unstick php-defaults, but i have a feeling it's going to actually be easier to unstick php-horde* and then retrigger php-defaults
<nacc> and php-horde-test looks to need a bunch of changes
<nacc> working on that now
<nacc> xnox: that is to say, i don't think i *can* unstick php-defaults until i fix horde
<nacc> xevious: php-crypt-chap is failing because php7.2-mcrypt is gone
<nacc> http://php.net/manual/en/migration71.deprecated.php
<xevious> Ah, that'll do it.
<nacc> so i think i need to pull in a new package
<xevious> It's available in PECL now.
<xevious> What uses php-crypt-chap? Can it be retired?
<nacc> xevious: php-horde-passwd :)
 * xevious strongly dislikes Horde
<nacc> but php-horde-passwd itself has no revdeps
<nacc> xevious: i'm pinging the debian folks to find out if they are going to package the pecl mcrypt
<nacc> xevious: ok, almost got horde-test working
<nacc> xevious: and some of the retriggers i ran are going throug now (php-imagick, php-memcache)
<nacc> xevious: horde-activesync needed a new horde-test and horde-stream-wrapper
<nacc> (new as in either upstream or cahnges)
<nacc> xevious: and i just retriggered the php-pear dependent ones
<nacc> and the arches for those where amd64 passed
<nacc> xevious: i'm going to elt excuses settle for a bit, i'll get the php-pear fixes uploaded first
<xevious> nacc: Are these tests running on the Launchpad build farm that this channel's topic says has limited capacity?
<cjwatson> Oh, that's out of date
* cjwatson changed the topic of #ubuntu-devel to: Artful Released + taken down LP#1734147 | Archive: open | 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 http://wiki.ubuntu.com/UbuntuDevelopment | Patch Pilots:
<jbicha> cjwatson: should we drop the Artful bug from the topic now?
<cjwatson> jbicha: I dunno
<cjwatson> ask somebody who was involved with that :)
* jbicha changed the topic of #ubuntu-devel to: Archive: open | 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 http://wiki.ubuntu.com/UbuntuDevelopment | Patch Pilots:
<rharper> nacc: I'm trying to do git ubuntu build or build-source  and I'm getting some errors when it attempts to lxc file push stuff into the ephemeral container ... is that a known issue ?
<nacc> rharper: which snap channel?
<nacc> rharper: and yes, possibly :)
<rharper> nacc: looks like stable
<rharper> on classic
<rharper> should I move to edge ?
<nacc> rharper: yeah
<nacc> rharper: it's fixed in edge and i've not done a release to stable in a while
<rharper> snap install git-ubuntu --classic --edge ?
<nacc> it's on my todo, but we're in heavy flux on edge and ENOTIME :)
<nacc> rharper: snap refresh --channel edge git-ubuntu
<nacc> iirc
<rharper> k
<nacc> possibly just snap refresh --edge git-ubuntu
<rharper> yeah
<rharper> or any order snap refresh git-ubuntu --edge
<nacc> rharper: right
<nacc> xevious: jmespath.php fixed (it just migrated, i'll wait til it shows up in rmadison then retrigger it)
<xevious> Good news. I was wondering about that one, since it wasn't showing up in APT at all.
<nacc> yeah i'm working on unwedging php-pear now (I need to craft the triggers properly)
<rharper> nacc: well, it fails *differently*
<rharper> E: Package 'equivs' has no installation candidate
<rharper> and similar to the stable release, it seems to ahve trouble with the temporary tarball
<nacc> rharper: can you pastebin the command exact output/
<nacc> *and exact output
<nacc> rharper: the equivs thing, presuming your lxd setup is good, should go away after a few attempts
<rharper> sure
<nacc> (we are just waiting on network in the lxd)
<rharper> what container are you launching? and why not give it cloud config ?
<nacc> rharper: we just use lxc appropriately
<nacc> rharper: i don't know what you meann by a cloud config in this context
<nacc> rharper: we need the equivalent of an sbuild environment
<rharper> if the lxc image you run inside has cloud-init , then whatever set of commands you want to run for like package install could do that
<nacc> rharper: because then we'd need to trust cloud-init :-P
<rharper> well, it waits for the network ...
<nacc> rharper: we *could* do that too
<nacc> rharper: feel free to file a bug
<rharper> sure, I'm mostly interested in which image you're using the minimal, or the cloud based ones
<nacc> cloud-based
<nacc> we just spawn ubuntu-daily:<whatever>
<nacc> based uponn the changelog
<rharper> if it's bionic, then you can do something like: lxc exec <name> -- cloud-init  status --wait which will block until cloud-init is done which ensures networking is up ; that way you're not spwaning apt commands when no network has come up
<nacc> rharper: and on trusty, xenial, artful?
<rharper> the networkd layer is somewhat sluggish due to ipv6 mantory waits
<rharper> cloud-init wait is back to xenial
<rharper> not trusty
<nacc> rharper: which then we'd have to special case :)
<nacc> tbh, this is all experimental enough that it's not a big deal
<rharper> y
<nacc> and we're not doing any work on that toolingn right nnow, focusing on the importer
<rharper> for sure
<nacc> i have a MP up that at least silences that output so it's not so scary
<rharper> I'm looking at my add-a-patch workflow so I can do that via git-ubuntu instead
<nacc> ack
<rharper> https://paste.ubuntu.com/p/q235rHvvjv/
<rharper> there's the command and output
<nacc> rharper: ok, yeah the equivs is just noise while it waits for network (with a backoff)
<nacc> reading the failure bit
<nacc> can you pass --keep-build-env and then go into the container and see what's there?
<rharper> I do have an orig.tgz in the parent dir for the package
<rharper> yeah
<nacc> i wonder if for some reason the tarball is root-owned
<nacc> bcause it's ap ermission issue, not a enofile
<rharper> yeah
<rharper> let's look
<rharper> no, owned by me
<nacc> rharper: in the container/
<nacc> *?
<rharper> oh
<rharper> let's wait
<rharper> it's thinking about retrying
<nacc> rharper: ok :)
<rharper> interesting, it gets the uid of my user on the host
<rharper> -rw-rw-r--  1 1001 1001 22039 Feb 14 23:16 bcache-tools_1.0.8.orig.tar.gz '
<rharper> -rw-------  1 1001 1001 28516 Feb 14 23:16 tmp1k_sj6kn.tar.gz
<rharper>  
<nacc> hrm, i guess that's probably because of `lxc file`
<nacc> and maybe local lxd config
<nacc> but that would be why you get an issue, as we run as the ubuntu user in the lxd
<nacc> now the question is why are the perms like that
<xevious> nacc: I updated the script to only flag regressions that have newer packages available. I also added a script to run it in a Docker container, in case that's convenient for you. https://gist.github.com/iammattcoleman/88013cb5f92105b15a66ee2ada442a16
<nacc> xevious: thanks
<rharper> nacc: yeah, you su - to the ubuntu user
<nacc> rharper: is this a branch you have pushed to LP that i can test?
<rharper> nacc: I think this is a local issue because on my system, my username is not uid=1000 like ubuntu is
<nacc> (just to see if it's reproducible)
<nacc> ah that would make sense
<nacc> and is probalby then an underlying bug
<nacc> (we should be chown'ing the files to ubuntu:ubuntu as we copy them
<nacc> we can use --uid, i think
<sarnold> pls no "chown as copy", but do the copy as the user in question..
<rharper>  https://code.launchpad.net/~raharper/ubuntu/+source/bcache-tools/+git/bcache-tools/+ref/add-bcache-export-patch
<nacc> sarnold: lxc file push --uid then?
<nacc> rharper: thanks, but based upon what you just said, that's the issue
<sarnold> nacc: yeah, that way if it's busted you can yell at serge and stephane :D
<nacc> sarnold: yeah
<rharper> nacc: right, I think that's it as well
<nacc> rharper: do you mind fililng a bug?
<rharper> sure, can I ubuntu-bug or what ?
<nacc> rharper: probably not? since it's not a package
<rharper> boo
<nacc> https://bugs.launchpad.net/usd-importer/+filebug
<rharper> so, what do ?
<rharper> k
<nacc> thanks
<rharper> np
<nacc> something like 'lxc file operations should set the uid'
<rharper> git ubuntu build fails when user's uid doesn't match ubuntu user in container
<nacc> yeah
<nacc> that works too :)
<xevious> nacc: I'm calling it a day.
<rharper> https://bugs.launchpad.net/usd-importer/+bug/1749609
<ubottu> Launchpad bug 1749609 in usd-importer "git ubuntu build fails when user's uid doesn't match ubuntu user in container" [Undecided,New]
<rharper> nacc: ^
<nacc> rharper: thanks
<nacc> xevious: have a good evening
<xevious> nacc: If you want to give me one/several of the "update to namespaced PHPUnit 6 classes" tasks tomorrow, those are ones I could easily tackle between other things I'm working on and meetings and whatnot.
<nacc> xevious: sure, i'll let you know
#ubuntu-devel 2018-02-15
<xevious> nacc: phpdox 0.10.1 introduced namespaced PHPUnit classes. The latest tagged version is 0.11.0.
<xevious> I've got a loose definition of calling it a day.
<xevious> There's a 0.10.1 package in sid: https://packages.debian.org/source/sid/phpdox
<nacc> xevious: i've uploaded 0.11 already
<nacc> xevious: it's in bionnic-proopsed
<xevious> hah
<nacc> xevious: they are wedged (i just checked, thanks for the poke) on php-phpdocumentor-reflection
<nacc> looking at it now
<nacc> xevious: looks like it needs an update too
<nacc> xevious: heh, 1.1.0 packaged, 3.0.0 released upstream
<nacc> sometimes Debian
 * nacc shakes fist
<xevious> I wonder how strongly people would object to letting PHP project .deb packages contain a vendor folder that's created by running `composer install` during `debuild`.
<nacc> well, i mean we use composer
<nacc> the problem is the composer.json in 1.1.0 is so solld
<nacc> 8old
<nacc> bah, old
<xevious> I mean instead of handling dependencies via dpkg dependencies.
<nacc> xevious: so you mean shipping all your dependencies in the deb?
<nacc> i think that would be expressly rejected
<xevious> I think so, too.
<nacc> i think debian/ubuntu would rather drop the php packages
<nacc> now that cmoposer exists :)
<xevious> Just having packages for the PHP interpreter and extensions would be a-ok with me.
<nacc> yeah, that seems lilke a 'better' future
<nacc> but i'm not sure we can do that for 18.04
<nacc> maybe 20.04 :)
<xevious> Yeah, that's definitely too much for 18.04.
<nacc> and reallly, i'm hoping debian will pick up some of this 'slack'
<xevious> Debian's PHP ecosystem is heavily tied to PECL/PEAR, which hardly anyone in the PHP community is using any more.
<nacc> e.g., start dropping horde
<xevious> Yeah, Horde's got to go.
<xevious> I hope there's some activity on this front soon: https://wiki.php.net/rfc/deprecate-pear-include-composer
<nacc> xevious: yeah that would make sense to me
<nacc> so much of PECL is cruft
<xevious> I agree with deprecating PEAR in that RFC, but I'm not sure about outright including Composer in the PHP core. I think it's doing a good job, but don't want to reject the possibility of something better coming along.
<nacc> yeah, i'm not sure why it needs to be 'in' the core
<nacc> but i'm not reallly a php user or developer
<nacc> just stuck in this swamp :)
<xevious> My job is all over the place. A pretty even mix of PHP, Python, JS, C, C++, C#. Sprinkle in a bit of Bash, Ruby, Assembly, ASL/DSL, and packaging for almost all platforms.
<xevious> I think you're spot-on with calling it a swamp. Getting rid of the PHP applications and focusing on the interpreter and extensions would make it much easier to maintain.
<xevious> It'd be interesting to monitor how often the PHP application packages are actually used.
<cjwatson> There are probably some hot spots, like Icinga
<cjwatson> I imagine popcon output in Debian would be helpful
<nacc> cjwatson: yeah that's a good point
<xevious> So, that brings me back around to my first suggestion... Most modern PHP applications manage their dependencies with Composer: have their packages put their source in /usr/lib/packagename (with a complete ./vendor hierarchy) and create /usr/bin symlinks for any `bin` entries in the composer.json.
<xevious> It'd lead to duplicate files, but it would allow different PHP applications to depend on different versions of a library.
<nacc> xevious: yeah, basically what snaps do for applications
<xevious> Exactly
<xevious> It'd be a small amount of bloat (bytes are cheap these days) in exchange for drastically simplifying the packaging process for PHP on Debian/Ubuntu.
<xevious> nacc: Have you heard back about mcrypt?
<nacc> xevious: not yet
<xevious> If PHP upstream is abandoning it, it seems silly to go through the effort of packaging the PECL version.
<xevious> Is there a proper venue for polling Ubuntu Server users about things such as "Can we remove Horde? Does anyone actually care?"
<blahdeblah> horde == burn it with fire :-)
<sarnold> mcrypt deserves the same inferno, right?
<nacc> xevious: i'd start with ubuntu-server@lists.ubuntu
<Unit193> sarnold: Except, I thought I needed that for something, but for the life of me can't remember what!
<xevious> sarnold: Yeah. Projects still using mcrypt need to update and get with the times.
<cpaelzer> hmm - all x86 builders seem to be locked in "cleaning"
<cpaelzer> is there another maintenance change going on or do the just need some help to get out of that state?
<cjwatson> probably just the latter.  poking
<cpaelzer> I see them turn idle and picking up jobs again, thanks cjwatson
<seb128> could somebody here trigger an Ubuntu/bionic iso build?
<seb128> the daily one built a bit before some seed changes we want to try were in place
<Laney> ok
<seb128> Laney, thx!
<tseliot> ginggs: I have just uploaded 390.25-0ubuntu1~ppa1.4, and the upgrading issues should be gone. Please test it, if you can
<ahasenack> hi, I need a component-mismatch fix for http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#sssd
<ahasenack> python-sss is in main, that's the py2 version
<ahasenack> python3-sss is in universe
<ahasenack> these python3?-sss packages are produced by the sssd source itself
<tarzeau> how to get software mentioned in "Software" ?
 * tarzeau would like to suggest something for "Audio Creation & Editing": klystrack, protracker, schismtracker, milkytracker
<tarzeau> and how come, in Games, "Mr Boom" has a "No screenshot provided"?
<tarzeau> and the "Fonts" section is half-screen empty...
<tarzeau> Education & Science, Astronomy: is missing saods9
<juliank> tarzeau: saods9 does not provide any appstream data
<juliank> same for everything else you mention probably
<tarzeau> how, and who is one supposed to add appstream data?
<jbicha> https://www.freedesktop.org/software/appstream/docs/
<jbicha> very few fonts provide AppStream metadata
<tarzeau> is that in the package? or external?
<juliank> Summary: AppStream data is an XML file to be provided by upstream to be shipped in packages.
 * tarzeau reads up on given url
<juliank> in /usr/share/metainfo/%{id}.metainfo.xml,
<juliank> where %{id} is a unique identifier
<sladen> thought it used to also fetch from  http://screenshots.debian.net/  or is that out of date
<jbicha> tarzeau: also https://wiki.debian.org/AppStream/Guidelines
<tarzeau> sladen: mentioned things have screenshots.d.n
<juliank> for example, /usr/share/metainfo/org.gnome.Calendar.appdata.xml
<tarzeau> thanks for the links, /me will try to improve
<juliank> screenshots have to be provided alongside the appstream metadata
<juliank> unless someone patched something into gnome-software to do something with screenshots
<tarzeau> jbicha: does debian use the appstream meta data, anywhere?
<jbicha> you can add AppStream metadata downstream in the packaging but forward upstream if you can (I did this for Cantarell)
<juliank> sure
<jbicha> some fonts don't really have an active upstream though
<juliank> and yes, Debian uses AppStream
<tarzeau> where?
<juliank> tarzeau: All the stuff in http://ftp.de.debian.org/debian/dists/unstable/main/dep11/ comes from it
<jbicha> tarzeau: Debian GNOME installs the GNOME Software app by default. That app only works with AppStream
<jbicha> there is also the Discover app for KDE users
<tarzeau> oh, i've never used the gnome software app on debian (or any kind of gnome software at all, actually)
<tarzeau> jbicha: never heard of that, but will try once i visit a kde user
<jbicha> what desktop do you prefer?
<tarzeau> jbicha: amiwm, or wmaker+gnustep software
<tarzeau> not exactly a desktop, but with gworkspace you have a nice file manager
<jbicha> oldschool :)
<tarzeau> but fast! even with remote x on slow lines
<tarzeau> the few hundred users @work use mate, unity, gnome mainly. and used to use kde but it got far less than a few years ago
<tarzeau> some use tiling wms, ratpoison, fvwm2 still, but very rare
<jbicha> if you like terminals, there's appstreamcli I guess
<tarzeau> and enlightenment
<tarzeau> desktop linux users are so rare
<juliank> GNOME, GNOME, GNOME is the only thing I use
<juliank> though nobody really knows why
<juliank> I mean, I basically don't use much except the shell and the terminal
<tarzeau> i've had headaches when i saw the menus of gedit lately
<tarzeau> the hamburger menu, and menu placements etc
<juliank> gedit looks awesome
<tarzeau> i prefer any editor in terminal over it
<juliank> but since it does not support mixed space/tab indentation, it's a toy
<juliank> just like vs code, atom, gnome-builder, and their friends
<juliank> or well, a bad joke, rather
<juliank> hence I use geany
<juliank> Unfortunately it does not have a header bar with client side decoration yet, but a menu bar and a tool bar
<juliank> with colored toolbar icons
<juliank> terrible
<juliank> app has menu => throw away
<tarzeau> what a pity must be in package. :(
<tarzeau> and its creation is like work people already have done (like debian/* copyright, homepage etc)
<tarzeau> there's no debian2appstream script or something?
 * tarzeau found appstream-generator
<jbicha> tarzeau: ideally, the appstream metadata is upstream (it is for official GNOME apps)
<jbicha> see also https://appstream.debian.org/sid/main/ or http://appstream.ubuntu.com/
<ginggs> tseliot: thanks, i'll try downgrading + upgrading - no problems with previous version and cuda 9.1
<tseliot> ginggs: great, thanks
<tarzeau> jbicha: i see. but the "Software" store, should not be GNOME only, well the gtk version, or the maybe qt version discover for kde (which I didn't have a look at yet)
<tarzeau> but right, anyone can provide such appstreams... preferably upstream, i got that
<jbicha> tarzeau: GNOME Software's .desktop doesn't set OnlyShowIn/NotShowIn; you can use it even if you don't use GNOME Shell
<juliank> tarzeau: appstream is not a gnome thing - it's a cross distribution development effort that was started by distributions, for distributions, over half a decade ago.
<juliank> Mostly by Fedora, SUSE, and Debian, IIRC
<jbicha> LocutusOfBorg: you're going to have a problem with tracker's autopkgtests - upstream decided to add failing tests in the 2.0.x series after 2.0.1 :(
<juliank> there also are more than those two store apps
<roaksoax>  /win 3
<xevious> It'd be convenient if the first line of the autopkgtest logs was the date & time that the job started.
<LocutusOfBorg> jbicha, I know, maybe we can disable such tests?
<LocutusOfBorg> I'm wondering what is the best thing to do here
<LocutusOfBorg> new tests, failed probably even before... maybe a versioned hint is good
<LocutusOfBorg> since they fail in Debian too, and in fedora too
<LocutusOfBorg> (I spent some time over the fedora/upstream bugs today)
<jbicha> the tracker tests worked fine until upstream added broken tests
<jbicha> I complained at tracker, but maybe it would help if someone else complained
<LocutusOfBorg> jbicha, I know, maybe we can disable such tests?
<LocutusOfBorg> I'm wondering what is the best thing to do here, new tests, failed probably even before... maybe a versioned hint is good
<LocutusOfBorg> since they fail in Debian too, and in fedora too (I spent some time over the fedora/upstream bugs today)
<LocutusOfBorg> also freeipa is a sad thing
<jbicha> what do you mean "failed probably even before"? the bad tests were added in 2.0.2
<LocutusOfBorg> jbicha, I mean, they arent related to the transition, and probably the problem is also in release
<jbicha> it is not related to the libunistring transition, but bionic only has 2.0.1 so you still have the problem of newly introduced bad tests
<LocutusOfBorg> so, relaxing the tests is fine I would say
<jbicha> that would make the tracker autopkgtest useless, right?
<LocutusOfBorg> yep :/
<jbicha> do you want to open a tracker bug upstream to complain about the troubles they are causing us?
<juliank> Failing tests should be optionalllllllllllll
<juliank> Well, it should say ignored failure or something, everything else is just bad
<xevious> nacc: https://gist.github.com/iammattcoleman/88013cb5f92105b15a66ee2ada442a16#file-2018-02-15_101023_php-defaults_issues-md
<nacc> xevious: thanks
<nacc> i think mcrypt has more than that
<nacc> based up on reverse-depends php-mcrypt
<xevious> I just based that on the autopkgtest logs.
<nacc> ah ok
<nacc> yeah
<xevious> The ones with "Declaration of DOMNodeComparator::assertEquals() must be compatible with ObjectComparator::assertEquals()" were almost all run on PHPUnit 5.4.6. Can you retrigger those with PHPUnit 6?
<xevious> Maybe all, actually.
<nacc> xevious: yeah i should be able to
<nacc> sorry, 'm digging into the horde stack right now
<nacc> and am on a call
<xevious> Sure I understand.
<nacc> but yeah i can use that
 * Laney has a race condition with juliank's race condition post :-)
<juliank> Laney ...
<juliank> I feel like I really should go build apt update --strict
<Laney> I wrote a draft saying "this is a race condition"
<Laney> and then I saved it to test the patch I'm attaching
<Laney> and there your post is :P
<juliank> Laney: I wrote all this on IRC yesterday already, should have posted it to the ML then, but ML required some setup
<juliank> I receive emails to ubuntu.com on one account, but can only send them from another :D
<juliank> So I re-subscribed with my canonical.com account, so I can send emails from there too
<juliank> Laney: I think it's best I introduce Acquire::TransientErrorsImportant, and then scripts can pass Acquire::TransientErrorsImportant=true or something
<juliank> or a counter
<Laney> it already has a bad exit status no?
<juliank> It exits 0
<juliank> Well the update exits 0
<juliank> the install eatmydata exits 1 I guess
<juliank> One shows "W:", the other "E:"
<juliank> yes. for the same error type
<Laney> mmm
<juliank> Laney: There's a wait+retry in the script so that would have caught it
<juliank> update || { sleep 10: update}
<juliank> basically
<juliank> um, ";", not ":"
<Laney> yeah we have those in a few places
<Laney> it's annoying having to sprinkle it everywhere
<juliank> Well and it also does not work.
<juliank> Probably because DonKult fixed a few bugs
<juliank> and now more errors are transient than before or something
<juliank> Well, any error from connect() is transient IIRC
<juliank> and after connect some HTTP errors are transient
<juliank> and transient errors only cause warnings, as they are "temporary"
<juliank> :D
<juliank> I should (1) add an option to control stuff (2) SRU it everywhere
<xevious> nacc: Would you like me to work on 'Class 'PHPUnit_Framework_TestCase' not found'? Can you start the tests for php-net-ldap2 2.2.0-3ubuntu1, php-parser 3.1.3-1, php-text-captcha 1.0.2-4ubuntu1, and phpdox 0.11.0-0ubuntu1?
<nacc> xevious: php-net-ldap2 and php-text-captcha retriggered
<nacc> xevious: php-parser and phpdox i'm trying to unstick so that they can migrate through then it's easier to retrigger
<nacc> xevious: that would be fine
<nacc> xevious: php-mockery needs an update from upstream but that in turn is failnig here, i'm debugging that too
<xevious> Ok. Is there a place I can see which packages are stuck like php-parse and phpdox? phpdox is listed as 'Valid candidate' on the 'excuses...' page.
<nacc> xevious: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt
<nacc> xevious: if it's valid and not migrating that page will explain why
<xevious> Great. Thanks.
<nacc> in this case because of php-phpdocumentor-reflection
<nacc> which i believe depends on a specific rev of php-parser
<nacc> xevious: oh that's why i was down that rathole yesterday
<nacc> php-phpdocumenter-reflection needs an updated php-mockery
<nacc> which in turn fails to pass its tests by default :)
<ginggs> tseliot: downgrading was somewhat messy, but after cleaning up i enabled your ppa and everything upgraded smoothly :)
<tseliot> ginggs: that's good. Thanks for testing
<ginggs> yw!
<nacc> xevious: ok, i see how to fix the mockery failure
<nacc> xevious: just need to do it correctly :)
<xevious> 'Correctly' seems like a solid plan.
<nacc> xevious: ah is see mockery added a helpers file that needs to be sourced before running the tests
 * nacc tries with an updated bootstrap.php
<nacc> woo i think it is passing
<nacc> that should unblock a few more (and fix the regression with php-defaults -> php-mockery)
<nacc> xevious: also php-crypt-chap has been removed from bionic
<nacc> xevious: see LP: #1749745
<ubottu> Launchpad bug 1749745 in gosa (Ubuntu) "php7.2 has removed the mcrypt module" [Undecided,Incomplete] https://launchpad.net/bugs/1749745
<xevious> Wasn't that a dependency of one of the Horde packages?
<nacc> xevious: reverse-recommends only
<tarzeau> juliank: ah okay, completely missed it.
<xevious> Yay, no more mcrypt!
<tarzeau> jbicha: so it's only the debian/fonts-cantarell.metainfo.xml that is doing the appstream thing?
<jbicha> tarzeau: yes, but that was upstreamed in Cantarell 0.100 (in Debian experimental)
<tarzeau> jbicha: i'm always in contact with my packaged software, upstream (where possible)
<tarzeau> so my plan would be, add it where it's useful, and provide it upstream for inclusion in future releases
<jbicha> it's a bit tricky to test appstream metadata. If you upload a package that installs it, it will show up in Debian or Ubuntu's GNOME Software about a day later
<tarzeau> jbicha: that's great :)
<tarzeau> i'll try it for fonts first, then games, then multimedia apps, later scientific software
<nacc> slangasek: i've got a package at 0.9.5 -- that then went to 1.0. There is also a 1.0.0~alpha1. uscan seems the 1.0.0-alpha1 and wants to use that and not the 1.0. Is it appropriate to mangle the uversion to suffix a .0 to two-digit versions so they sort properly?
<nacc> (upstream versions for the above)
 * tarzeau votes for epoch!
<nacc> tarzeau: wrt to my question? not sure how that would help? I guess it would force 1:1.0 to sort after 0.9.5 ?
<nacc> tarzeau: aiui, i don't think an epoch bump is neeeded here, 1.0 should sort after 0.9.5 (per the manual)
<nacc> the problem is uscan doesn't compare them properly, i think
<nacc> with my manual mangle, it sees 1.0 as 1.0.0 and correctly updates to ti
<nacc> *it
<tarzeau> ah
<nacc> tarzeau: that's my understanding right now, at least...
<nacc> xevious: and that pulls in a new php-hamcrest :)
<nacc> xevious: uploding php-hamcrest
<nacc> xevious: waiting on a response to the above before i upload php-mockery
<xevious> php-mail-mime's log is unclear about what the actual errors are. It just says which tests failed, not why.
<nacc> xevious: let me look
<nacc> xevious: yeh that's becuse they are using pear not phpunit directly :/
<nacc> it *might* need the php-pear from proposed
<nacc> xevious: i can retry it locallyw ith propsed
<nacc> xevious: do you have autopkgtest setup locally?
<xevious> I don't. I was just going to ask how I can get my local machine configured so I can actually start helping with the packages.
<nacc> xevious: 1) have lxd setup locally
<nacc> xevious: 2) install autopkgtest
<nacc> xevious: 3) autopkgtest-build-lxd ubuntu-daily:bionic
<nacc> xevious: 4) autopkgtest -U -s php-mail-mime -- autopkgtest-virt-lxd autopkgtest/ubuntu/bionic/amd64
<nacc> xevious: if you want to test with proposed, you puass --apt-pocket=proposed
<nacc> xevious: you can also pass it a soruce package dsc rather than the name, fi you have local stuff
<xevious> easy-peasy
<xevious> Thanks
<nacc> xevious: you can also specify specific packages in the apt-pocket line, iirc, which is what LP is doing
<nacc> and what changing the triggers changes
<nacc> infinity: would you have any opinion on the d/watch change i mentioned above? (I can repost it if that's easier)
<nacc> xevious: php-mail-mime also fails with proposed enabled
<nacc> xevious: debugging it
<xevious> nacc: I'm running 16.04 on this machine and didn't get an autopkgtest-build-lxd, autopkgtest, or autopkgtest-virt-lxd commands from installing the autopkgtest package. It installed adt-build-lxd, adt-run, and adt-virt-lxd, but adapting your command 4) didn't work.
<xevious> adt-run -U -s php-mail-mime -- adt-virt-lxd autopkgtest/ubuntu/bionic/amd64
<nacc> xevious: s/autopkgtest/adt/ in what i wrote
<nacc> it just got renamed
<xevious> There isn't a command just named adt and adt-run is complaining about those parameters.
<xevious> nacc: adt-run: error: adt/ubuntu/bionic/amd64: unsupported action argument
<xevious> That was the output when I ran: adt-run -U -s php-mail-mime -- adt-virt-lxd adt/ubuntu/bionic/amd64
<nacc> xevious: when you ran the build-lxd, it succeeded, right?
<nacc> xevious: if so, then check then anme (`lxc image list`)
<nacc> xevious: oh and adt might need three dashes
<nacc> not two
<xevious> Yes it succeeded. The image is named adt/ubuntu/bionic/amd64
<xevious> Trying three dashes
<xevious> That did it
<nacc> xevious: sorry, i forgot about that
<xevious> Seems like my container can't lookup hostnames. Can I pass it nameserver info or just tell it to use the host system's /etc/resolv.conf?
<nacc> xevious: have you used lxd before on your system?
<nacc> xevious: it might need soe network config if not
<slangasek> nacc: yes, no problem with version mangling to 1.0.0.
<nacc> slangasek: ok, thanks
<xevious> nacc: php-mail-mime passed on my system.
<xevious> (without proposed enabled)
<nacc> xevious: hrm, but with php-defaults from proposed? that's what is broken
<xevious> Rerunning it
<nacc> xevious: thanks, i definitely saw lall the failure siwth all proposed (which is my usual first test)
<nacc> as it's easier to type then figuring out the exact packages to test (locally)
<xevious> Yeah, I just added '--apt-pocket=proposed' for this run.
<nacc> xevious: yep
<xevious> For the projects that need to be updated for namespaced PHPUnit classes, most of them have already fixed that upstream. Can we just update to a new upstream version, or do we have to patch the packaged version?
<nacc> xevious: depends? :)
<nacc> if uscan can find it, and uupdate works, and the package builds and tests successfully, go for it
<nacc> but sometimes, that ends up making its own nest of dependency migrations
<xevious> Yeah, gotta watch out for backwards incompatible changes, for sure.
<xevious> If all the PHP library dependencies were packaged with the PHP applications, then several versions could happily coexist on a system.
<xevious> I really need to post about that on the ubuntu-server mailing list.
<xevious> nacc: Running the test with proposed enabled reproduced the log from the excuses... page.
<nacc> xevious: yep
<xevious> nacc: Now that I've got autopkgtest/adt set up on my system, how do I use it to test local changes to a package?
<nacc> xevious: you know how to build source pacakges?
<xevious> Yes
<nacc> xevious: so e.g., `pull-lp-source  ... ` etc
<nacc> make changes, etc. dpkg-buildpackage -S -nc -d
<nacc> pass the resulting dsc to adt
<nacc> (after modifying the changelog)
<xevious> I'm very comfortable with everything but the LaunchPad aspect of it. I've either worked with repos from internal source control or just modifying packages downloaded with `apt-get source`.
<nacc> ack
<nacc> so don't worry about lp for now :)
<nacc> (pull-lp-source is a way to do `apt-get source` without having to have sources defined)
<nacc> and to pull down source from any release
<nacc> you can file bugs against the srcpkg, and attach debdiffs (`debdiff existing.dsc new.dsc`) and i can sponsor them for you
<xevious> That sounds relevant, since I've got LXC set up on a 16.04.3 system right now.
<xevious> I'll read up on pull-lp-source and dig up my LP credentials.
<xevious> I'm fairly certain my GPG keys are long gone. :\
<nacc> xevious: pull-lp-source doesn't require auth, fwiw
<nacc> just the bug filing will
<xevious> Right.
<xevious> I'm going to go find some food to munch on.
<xevious> bbiaf
<nacc> xevious: sounds good, i'm uploading php-mockery now and i filed a bug to remove php-phpdocumentor-reflection
<nacc> xevious: php-mail-mime is using count() in Mail/mimePart.php line 314
<nacc> xevious: changing it to be if (is_array($this->subparts) && .. ) and it passes
<nacc> xevious: i'll upload that fix
<nacc> xevious: oh i think it's fixed in 1.10.2 upstream
<nacc> i'll update to that
<nacc> (safer in this case)
<nacc> xevious: ah it's in debian building right now (1.10.2-0.1
<xevious> nacc: php-doctrine-cache 1.7.1 should resolve the issues. Can you rerun its tests with the new package?
<xevious> Woops
<xevious> I forgot to refresh.
<xevious> nacc: Are you still focused on Horde?
<infinity> nacc: Your debian/watch woes can be solved with a rewrite of -alpha to ~alpha (and similar for -beta) if you know that's how upstream names things.
<xevious> watch woes?
<infinity> nacc: It's not that uscan is sorting "incorrectly", just that it uses a dpkg version sort, and upstream doesn't.
<xevious> I'm looking at php-guzzlehttp-promises and the archive it's pulling down doesn't include the tests folder.
<xevious> ...just because they chose to upload a tarball without the tests folder for that release, apparently.
<xevious> Using the GH API tarball URL also produces an archive without the 'tests' directory. Anyone have any idea what's going on here?
<nacc> infinity: it does that already (afaict)
<nacc> infinity: but ack on the 'incorrectly'
<nacc> xevious: i can look
<xevious> nacc: Is there a setting on GH that makes it not include a 'tests' directory in archives?
<nacc> xevious: not that i know of, but possibly it's controlled by a file in the repo
<xevious> It sure is
<xevious> .gitattributes
<nacc> xevious: yeah
<nacc> xevious: does that imply guzzlehttp-promises also fails without -proposed?
<infinity> nacc: Oh!  I focussed on the ~ and missed the 1.0 versus 1.0.0.  Derp.
<nacc> infinity: yeah, it's that bit
<xevious> nacc: I was trying to just update it from 1.1.0 to 1.3.1, since they've already switched to namespaced PHPUnit classes.
<infinity> nacc: Yeah, you could either mangle to add another .0 or (which seems more sane) add a version ignore for the 1.0.0~* ones.
<xevious> 1.3.0 should work, though.
<nacc> infinity: ack, thanks
<nacc> sigh, libc6 in bionic is < libc6 in artful-security?
<nacc> that seems less than ideal?
<nacc> 2.26-0ubuntu2 vs 2.26-0ubuntu2.1
<nacc> and does that imply a security fix raced with the bionic open?
<nacc> xevious: you might compare the current package's results on artful
<nacc> xevious: so the version in the archive now has a tests/ dir
<xevious> Everything prior to 1.3.1 did, because there wasn't a .gitattributes file in the repo preventing tests from being exported.
<nacc> xevious: oh i see
<nacc> xevious: yeah, so you cn bump to just 1.3.0 if you want
<xevious> Is it reasonable to submit a "Fix Debian/Ubuntu packaging" PR that removes 'tests' from .gitattributes to the upstream repo, or should I adapt the package to upstream's changes?
<xevious> I could change the get-orig-source target in rules to use `git archive` instead of uscan.
<nacc> xevious: you could do that, but then you'd also need to change it to git cloen first
<nacc> that's not great
<nacc> as you'd need to make git a build-depends
<xevious> A 1 line PR to upstream to include tests in the archive is the simpler solution from the packaging perspective. However, I'm hesitant to make Debian/Ubuntu-specific requests in an upstream project.
<nacc> xevious: i've done it before :)
<nacc> xevious: do they explain upstream why they changed it?
<xevious> To "improve packaging" https://github.com/guzzle/promises/commit/e278912eaaa94079b9277d5dbe23fc0a22d308bf
<nacc> xevious: phpdox just migrated
<xevious> It wouldn't need a 'git clone' in the build process. Updating the get-orig-source target to use `git archive` would still produce a tarball.
<nacc> xevious: how? it's run from debian/rules?
<nacc> xevious: where youdon't have a git repo
<xevious> Well that plan's out the window
<xevious> GitHub doesn't allow archiving.
<nacc> xevious: so 1.3.0 didn't work?
<xevious> nacc: You can pass `--remote=` to `git acrhive` to create a tarball of a remote repository.
<nacc> xevious: oh interesting
<nacc> xevious: i didn't realize that, sorry
<xevious> It would still require adding git as a build dependency, which isn't great.
<nacc> yeah
<xevious> I'll just open a PR to make the tests directory export again. We'll see what they say.
<nacc> xevious: fwiw, i think php-horde-core is more than just a retry -- you can see that some did run against the version in b-p and still failed
<nacc> xevious: so you're still working on guzzlehttp-promises? mockery should migrate in a bit and i'll retrigger it then
<xevious> I'm just going to open a PR with the change and move onto the next PHPUnit-related one.
<xevious> Alternatively, I could just make the package not run the tests.
<xevious> That doesn't seem great.
<nacc> it has been done to a few packages now
<xevious> Well, if there's precedent...
<xevious> What do you recommend?
<nacc> xevious: so, aiui, the issue is that the upstream isn't packaging the tests, so the dep8 tests fail? doe sit still build?
<nacc> xevious: you can remove the dep8 tests if they really aren't available anymore, i think, and i will need to send a hint MP to ignore the regression (removing tests is considred a regression too)
<xevious> It doesn't build because there's a patch for bootstrap.php in the tests directory.
<nacc> xevious: right i had to fix soethig similar recently
<nacc> in a different package
<nacc> xevious: but i mean the dep8 tests no longer make sense right?
<nacc> xevious: since the tests are no longer shipped
<xevious> Right
<xevious> I can either remove the tests from the packaging process or I can open a PR with upstream in hopes that they quickly tag a new version.
<nacc> xevious: you can do both :)
<nacc> xevious: which is probably ideal ;)
<xevious> Ok
<xevious> I'll do both
<xevious> nacc: https://github.com/guzzle/promises/pull/87
<nacc> xevious: yeah, i can understand the upstream theory, you don't need the tests to have a functional package
<nacc> but i've not seen other upstreams do that
<nacc> and the extra space is ... minimal
<xevious> Yeah, I understand their reasoning, However, I can think of a number of cases where you'd want to use an archive download rather than git, and then be able to run the tests.
<jbicha> cjwatson: if you're around, can you kick the ppc64el builders?
<nacc> xevious: yep
<xevious> nacc: It looks like php-guzzlehttp-promises is inherited from Debian. How does cooperating with them work? Should I make the change on LaunchPad and we incorporate it into Bionic, then upstream it to Debian? Or, should I work with Debian from the start and pull it into Bionic when it's in their repo?
<nacc> xevious: either is ok, the latter tends to take longer
<nacc> xevious: so the simpleset answer is make the change in ubuntu, and we can send stuff up to debian (there is a submittodebian helper)
<nacc> after we get ubuntu working :)
<xevious> Perfect
<nacc> xevious: fixed php-horde-core
<nacc> testing it again and then i'll upload
<xevious> Right on!
<nacc> that might be what's needed throughout
<nacc> i *think* possibly phpunit 6 dropped support for autoloading a boostrap.php file?
<nacc> that seems to fix a lot of packages (passing the option to phpunit)
<sarnold> slangasek,bdmurray, I have a suspicion Something Is Wrong: a friend showed me 'apt upgrade' https://bpaste.net/show/a0ccc1e394d7 and 'apt dist-upgrade' https://bpaste.net/show/aa8d1ff48634 results that looked like they worried him, and I can reproduce something very similar: http://paste.ubuntu.com/p/WTD9rYCcFq/ (please ignore firefox..)
<nacc> yep somoene elsehwere also reported the removal of unity-scope* from their system
<sarnold> nacc: oh, hooray, did you recall where? or bug number?
<nacc> looking in my logs
<nacc> sarnold: #ubuntu-discuss, no bug filed
<bdmurray> sarnold: what release?
<sarnold> bdmurray: I believe xenial all around
<nacc> checking on that there but they did say xenial at one point
<nacc> which seems 'even worse' :)
<sarnold> https://irclogs.ubuntu.com/2018/02/15/%23ubuntu-discuss.html#t20:17
<nacc> sarnold: thanks
<nacc> uggggh
<nacc> compiz-core migrated without a unity rebuild?
<nacc> unity: depends on compiz-core-abiversion-20151010,
<nacc> Provides: compiz-core-abiversion-20170630
<nacc> latter from compiz-core in updates
<bdmurray> if its already in -updates we'll need an archive admin
<nacc> it looks to be in both right now
<nacc> https://launchpad.net/ubuntu/+source/compiz
<nacc> updates and proposed, i mean
<nacc> bdmurray: i'm not 100% on my analysis but that abi mismatch seems worrisome with no changes to unity
<sarnold> is this time for the !regressions batsignal or whatever it is?
<nacc> heh
<nacc> sarnold: it's being discussed in #ubuntu-release
<sarnold> nacc: <3
<nacc> sarnold: phasing stopped
<nacc> (presumably all affected were in the last 4 hours)
<nacc> xevious: fyi php-horde-core uploaded
<xevious> Great. Looking forward to seeing a bunch more green...
<nacc> xevious: bbiab
<tsimonq2> Can a Core Dev please approve this bug nomination? 1746807
<tsimonq2> bug 1746807 even
<ubottu> bug 1746807 in base-installer (Ubuntu) "18.04 daily installer fails missing kernel" [Critical,Confirmed] https://launchpad.net/bugs/1746807
<rbasak> tsimonq2: why does it need nomination for Bionic?
<tsimonq2> rbasak: It's a Bionic-specific bug, I'll nominate Bionic out of habit I guess (for future ref should I need to revisit it at any point).
<tsimonq2> s/Bionic out/Bionic if I have access to out/
<tsimonq2> rbasak: I guess there's no *need* to but it's good for bookkeeping I guess
<rbasak> tsimonq2: it'll affect >= Bionic until it is fixed, no?
<rbasak> That's the same as any other bug, and we don't usually nominate the development release for that kind of thing.
<tsimonq2> OK
<rbasak> There was a time when people were adding a development-release-specific bug task for release bug tracking purposes
<rbasak> I'm not sure if we still do that
<rbasak> I'm not sure it's a good idea in general, because it collides with tracking SRUs when a series is relaesed.
<rbasak> But I don't think anyone has actually tried to define a policy on this since Kate left.
<tsimonq2> OK
<rbasak> infinity, slangasek: ^ opinion?
<slangasek> rbasak: we do have per-team reports on bugs targeted to the current development release; I gather Server Team isn't using this? http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-bb-tracking-bug-tasks.html#ubuntu-server
<xnox> rbasak, for foundations it does make a different if something is "whenever" vs "whenever, but to fix for bionic"
<rbasak> slangasek: we're aware of the link, but we never controlled what was actually on that list, or how to get bugs out of the list, partially (IMHO) due to a lack of an Ubuntu-wide policy on it.
<rbasak> So (again IMHO) it never seemed to be a particularly useful way of tracking anything
<xnox> rbasak, well, the report is fixed, in what it is generating into accepted / incoming / rejected pages.
<rbasak> xnox: who accepts/rejects though, and what if the server team disagrees with such a nomination?
<slangasek> rbasak: there is a tag to decline a bug from that list as not-committed-by-team despite being targeted to the release; I forget the exact name, bdmurray would remember
<bdmurray> notfixing
<slangasek> it might be rls-$series-declined
<slangasek> ok that
<xnox> rbasak, people who what it request for a bug to be considered add rls-LL-incoming; if $team accepts it, the $team removes the tag and targets to series, and potentially to a monthly milestone (but we moved on to creating trello cards for these)
<xnox> rbasak, or drop incoming tag and replace by notfixing.
<xnox> rbasak, as $server team is meant to keep track of the bugs, to packages, which the team is subscribed to, for rls-incoming bugs.
<xnox> at least foundations does it for foundations-bugs subscribed packages.
<slangasek> "is meant to" - well, that's the intent of the report, but we obviously don't dictate how other teams use it
 * xnox wonders if we due to scope we need automation for this
 * xnox wonders if we do, due to scope we need automation for this
 * xnox wonders if we do, due to scope. Hence we need automation for this
 * bdmurray wonders about xnox
<xevious> nacc: Should I add `override_dh_auto_test` to rules, or should I delete the `test` rule from the upstream project's Makefile?
<rbasak> We use Trello too
<xnox> bdmurray, i had a volleyball training, my fingers are a bit shaky, and I'm misstyping a lot.
<slangasek> can we automate the scope, if the guards come with him
<xnox> rbasak, for us bugs are public; trello is private.
<rbasak> Our Trello is public I think
<rbasak> But it's really a ~canonical-server Trello, rather than an ~ubuntu-server Trello.
<xnox> rbasak, yeah, most teams have it like that. It's just the PDX based managers who have it private.... kernel team / foundations team / security (?!) / is (?!)
<tsimonq2> rbasak: You guys have your plans to take over the world there? :P
<tsimonq2> s/guys/guys and gals/ if you will
 * tsimonq2 steps away from that debate real quick
<slangasek> xnox: we were keeping the managers' locations private
<rbasak> Private customer work happens on a different board
<xnox> rbasak, yeah, so rls-incoming is "canonical-foundations is commiting to things" vs "non rls-tracked bugs ubuntu-foundations may volunteer to do it with no sla"
<rbasak> xnox: for packages to which you subscribe, presumably
<xnox> rbasak, typically rls-LL-incoming bugs we get; are escalations from either community or other ~canonical-foo or ~ubuntu-foo teams. We try to assess criticality, and impact. As we get flodded with bugs =/ and we use that for people to bubble things up to us; we review incoming bugs at every weekly meeting.
<xnox> we hardly are a zero-boogz-found team =/
<xnox> aka inbox-zero
<rbasak> That sounds reasonable except I'm not convinced about the need to peg it to a particular release
<xnox> well, we used to have foundations STS handle stable releases incoming bugs a bit ;-)
<xnox> and reports currently track things as "accepted" when targetted to a release, instead of an 'rls-LL-accepted' tag.
<xnox> i guess that is simply how the reports got implemented.
<rbasak> tsimonq2: so I suppose that means that you need to tag your bug rls-bb-incoming
<rbasak> tsimonq2: rather than asking for a nomination to be accepted directly
<rbasak> tsimonq2: since Foundation is subscribed to that package (presumably)
<tsimonq2> rbasak: aha, ok
<xnox> that =) at least for packages that are subscribed by ~foundations-bugs team
<tsimonq2> rbasak: I'm trying to see if it's something I can figure out on my own, but obviously if I can't do that, I'll pass to Foundations
<xnox> rbasak, rls-xx-incoming sometimes become hot in the run up to point releases... vs rls-bb-incoming in the run up to feature freeze / milestones....
<xevious> nacc: adt-run [18:42:14]: @@@@@@@@@@@@@@@@@@@@ summary
<xevious> *                    SKIP no tests in this package
<xevious> On to the next one...
<nacc> xevious: i'm back now
<nacc> xevious: nice, i'm guessing you need sponsorship for that? file a bug against hte srcpkg and upload the debdiff to it
<nacc> xevious: and subscribe me to it
<cjwatson> jbicha: done
#ubuntu-devel 2018-02-16
<xevious> nacc: Do I have to do anything to clean the source repo before running debdiff?
<xevious> All I've done in it was run `dpkg-buildpackage -S -us -uc -d`
<nacc> xevious: that would clean it (-nc would not)
<nacc> xevious: that should generate your new dsc
<xevious> Thanks... just making sure there wasn't anything extra. Filing the bug now.
<nacc> xevious: i'd let you know in the bug if there is :)
<nacc> xevious: i'm doing php-horde-{argv,auth,autoloader}
<nacc> xevious: i have a feeling it's not going to make sense to retrigger much more for php-defaults until we get all the new uploads in
<xevious> I agree.
<xevious> I can churn through several of these PHPUnit ones now that I've got the workflow down.
<nacc> xevious: yeah, it's pretty repetitive
<nacc> things to grep for PHPUnit_, setExpectedExpectation, getMoc
<nacc> *getMock
<nacc> and then for php7.2 itself, count( and i'm just finding create_function
<xevious> nacc: https://bugs.launchpad.net/ubuntu/+source/php-guzzlehttp-promises/+bug/1749850
<ubottu> Launchpad bug 1749850 in php-guzzlehttp-promises (Ubuntu) "tests have been removed from the upstream distribution archive" [Undecided,New]
<xevious> nacc: Also, I let the PHP_CodeSniffer lead dev know that we've currently got a version with known issues packaged: https://github.com/squizlabs/PHP_CodeSniffer/pull/1899#issuecomment-366100156
<nacc> xevious: thanks
<nacc> yeah, and if it's not a feature thing, but a bugfix changes, we aren't bound to Feature Freeze
<nacc> worst-case, we can backport the fixes back
<nacc> xevious: but i expect we'll get lots of bug rreports (or none as people are using composer directly) for these packages in the next few months
<xevious> nacc: If those php-guzzlehttp-promises changes look good, I'll move on to the next package with the "Class 'PHPUnit_Framework_TestCase' not found" issue.
<xevious> (I'll skip over any Horde packages...)
<nacc> xevious: it looked ok, except i think your debdiff's chagne to bootstrap.php may have had some local context? i'm not sure
<nacc> xevious: it didn't apply cleanly here
<nacc> xevious: tbh, for cases like this, i should have said, it's eaiser to give me a debdiff (really just a patch) to apply from the uupdated repo to the version you want me to build
<nacc> so that i can avoid the uupdate itself as part of the patch
<xevious> Isn't that what I gave you?
<nacc> xevious: what you gave me appears to be the full debdiff (incl. the uupdate itself)
<nacc> if that makes sense
<nacc> hrm, uscan for me is not reporting a new upstrea version
<nacc> did you have to modify the watch file?
<xevious> I didn't
<nacc> i'm admittely on bionic
<xevious> About the full debdiff: when I ran debdiff, it complained about not having a directory for the 1.1.0 version to generate the diff from. So, I pulled another copy of 1.1.0 and made a debdiff that includes the uupdate. How would I generate it against the already uupdated version?
<xevious> I built/tested it on a xenial system, using pull-lp-source to do the initial download.
<nacc> xevious: i meant you can just give me a patch (something like): cd <old srcpkg>; uscan; uupdate ../new tarball; cd ..; cp -aR <new srcpkg> <new srcpgk>.bak; cd <new srcpkg>; <make changes>; cd ..; diff -urpN <new srcpkg>.bak <new srcpkg> > debdiff; lp-attach debdiff
<nacc> xevious: since the first bits of that i have to do locally anyways, as i need th eorig tarball to build it to sponsor it :)
<xevious> Want me to do that for you on this one or just the ones going forward?
<nacc> going forward, i think; i'm working on this one now
<nacc> xevious: those php-horde ones i just entioned all uploaded, btw
<nacc> *mentioned
<xevious> Looks like you need to bump php-mockery on i386.
<xevious> (It's still showing regressions and is the only arch listed for the old version on the 'excuses...' page.)
<nacc> xevious: thanks
<nacc> xevious: did you make changes to the upstream Makefile?
<xevious> I did not
<xevious> Intead of removing their 'test' target, I added an empty 'override_dh_auto_test' target to debian/rules.
<nacc> xevious: oh i see what's going on
<xevious> I removed a patch to the Makefile
<nacc> xevious: you were in a patches applied state
<xevious> Uhoh
<nacc> so i think it got a bit confused
<nacc> so the patch is dropped in your debdiff
<nacc> or maybe i am
<xevious> Which patch?
<nacc> let me do this by hand :)
<xevious> The one that changes vendor/bin/phpunit to phpunit?
<xevious> I removed that patch.
<nacc> right, but sponsor-patch is claiming that it is still happening, and im' not sure why
<xevious> The changes were simple. Want me to redo it with your suggested workflow?
<nacc> it's ok, i can fix it up locally
<nacc> so the problem is your debdiff is totally correct
<nacc> except if you're already in a patches applied state (e.g., after just extracting the source package normally)
<nacc> xevious: ah you're missing a changelog entry and a update-maintainer run
<nacc> hrm, no you're not
<nacc> well the latter yes, but for some reason patch didn't see your change to changelog
<nacc> PEBKAC, nm
<xevious> update-maintainer?
<nacc> xevious: marks the package as being matinained by ubuntu
<nacc> so that debian is not contacted for issues in it
<nacc> also fixed yoru version (i thought uupdate did this correctly) it should have been 1.3.1-0ubuntu1
<nacc> because we are going ahead of debian
<xevious> Yeah, I set the version when I wrote the changelog with dch. I'll stick to what uupdate recommends.
<nacc> yep
<nacc> also, i'm inserting a bug reference in the changelog
<nacc> this way LP will close the bug for us when the package migrates
<xevious> Cool
<xevious> Yay automation
<rbasak> nacc: mysql-5.7 migrated. Thanks!
<rbasak> (I assume it was something you did, judging from your activity here)
<xevious> nacc: So, I hate to be a PITA, but should we update to PHPUnit 7? Support for PHPUnit 6 ends a little less than a year into 18.04's life. PHPUnit 7 is at least supported until a couple months before 20.04 comes out.
<xevious> I'm imagining the look of rage on nacc's face.
<nacc> rbasak: yeah i finally got the right set of triggers
<nacc> rbasak: and well, fixed that package too :)
<nacc> xevious: heh, how bad is the backwards compat
<nacc> xevious: the issue is this mess is already pretty bad
<nacc> and, tbh, we've done no updates to phpunit 5.1.3
<nacc> in xenial
<xevious> It's hard to tell how bad it'd be: https://phpunit.de/announcements/phpunit-7.html
<xevious> Looks like it could be a pain.
<nacc> xevious: tbh, my vested interest is pretty minimal
<nacc> while i agree fully with what you are saying, phpunit itself is in universe
<xevious> Ok, let's not do it.
<nacc> and it would a ton (more) delta to ubuntu packages :)
<xevious> I'm sold. PHPUnit 6 it is.
<xevious> Guzzle dev does not want to add the tests back into the archive and asked if we can use `git clone` instead: https://github.com/guzzle/promises/pull/87#issuecomment-366109645
<nacc> xevious: this may be worth an email to the debian devs
<nacc> xevious: i'm not entirely sure what the best practice is from a packaging perspective
<xevious> Yeah, it kind of blows up the whole process, since `uscan` can't do its thing without a web page to parse.
<xevious> Well, really it's because `uscan` only does HTTP downloads.
<xevious> Oh wait
<xevious> It does do git?
<nacc> xevious: so it does, but only for tar.xz
<nacc> which is fine
<nacc> it does say 'last resort' :)
<xevious> Yeah, well this is the last resort.
<nacc> yeah i suppose so :)
<xevious> From the man page...
<xevious> > If the upstream publishes the released tarball via its web interface, please use it instead of using this mode.
<xevious> ...however, if they've removed the files you need from the released tarball available via the web interface...
<xevious> Alright, let me read up on uscan and see if I can make a new version that retains the tests.
<nacc> new php-mail-mime is in bionic-proposed, i'm retriggering now
<nacc> slangasek: i'vetried to reproduce the current failure with php-defaults & php-horde-core in bionic-proposed with: `autopkgtest -U -s --apt-pocket=proposed=src:php-defaults,src:php-horde-core php-horde-core -- autopkgtest-virt-lxd autopkgtest/ubuntu/bionic/amd64` but it passes here
<nacc> slangasek: do you have any idea what i'm missing?
<nacc> xevious: i need to eod/afk soon, but i'll check back in later and be back online/active tmrw morning after kid dropoff
<slangasek> nacc: the passage of time?  is the failure still reproducible if you retry it on autopkgtest.u.c?
<xevious> nacc: Which TZ are you in? When's morning for you?
<xevious> I'm Eastern US...
<nacc> xevious: PST US
<nacc> slangasek: i thougth so becuase i'm pretty sure i retriggered it
<nacc> slangasek: but let me try again and see
<xevious> Cool. I'll get all my non-PHP-packagin things out of the way in the morning tomorrow, that way I can be totally focused on this once you're online.
<nacc> xevious: sounds good, thanks!
<xevious> nacc: I'm going to rework this to try to add the tests back in before calling it a day.
<nacc> xevious: sounds good, feel free to add the debdiff tat results in the bug (based upon the version now in b-p)
<xevious> Will do
<nacc> xevious: and waiting on php-guzzlehttp-promises to publish then i can retrigger those
<xevious> nacc: Can you retrigger all the guzzle packages to run their tests with this new php-guzzlehttp-promises package, assuming its tests complete?
<xevious> nacc: I got it to detect the new version using git, but it's failing to download it.
<xevious> it=uscan with an updated debian/watch
<xevious> > uscan: Newest version of php-guzzlehttp-promises on remote site is 1.3.1, local version is 1.1.0
<xevious> > uscan:    => Newer package available from
<xevious> >       https://github.com/guzzle/promises.git refs/tags/v1.3.1
<xevious> > Undefined subroutine &main::getcwd called at /usr/bin/uscan line 3370, <REFS> line 72.
<xevious> ?!
<xevious> That line is: my $curdir = getcwd();
<roaksoax> xevious: uscan will downalod to ../
<xevious> Yeah
<roaksoax> so you would be able to cd ../<package>-<version>
<xevious> I'm trying to update the watch file to download based on a git tag instead of parsing a web page.
<Unit193> That's not entirely accurate.
<xevious> It's correctly parsing the git repository, but failing immediately upon entering the git-specific section of the `uscan` code.
<tsimonq2> I hate doing that with GitHub *so* much.
<tsimonq2> I just copy/paste from other packages I maintain.
 * tsimonq2 finds an example
<tsimonq2> This is for src:vc:
<tsimonq2> version=4
<tsimonq2> opts=filenamemangle=s/Vc-(\d\S+)\.tar\.gz/vc_$1\.orig\.tar\.gz/ \
<tsimonq2>   https://github.com/VcDevel/Vc/releases .*/Vc-@ANY_VERSION@@ARCHIVE_EXT@
<xevious> tsimonq2: For this one, I need to clone via git instead of downloading the latest release via HTTP. They added a .gitattributes file that prevents all the tests from being included in any archives.
<xevious> Ok I found the bug.
<tsimonq2> Ok cool
<xevious> `/usr/bin/uscan` doesn't have `use POSIX;` any where in it.
<xevious> *anywhere
<xevious> nacc: Ok my plan was foiled anyway: uscan's git mode uses `git archive` behind the scenes, so the resulting tarball won't include the test files.
<xevious> That lack of `use POSIX;` has been fixed in a newer version of `uscan`.
<xevious> They switched to `cwd()` instead of `getcwd()`: https://anonscm.debian.org/cgit/collab-maint/devscripts.git/tree/scripts/uscan.pl#n4435
<xevious> So, that's currently broken in 16.04.
<nacc> xevious: ack re: guzzle
<nacc> slangasek: fwiw, retrigger didn't help ... should i retry with all-proposed=1? i can't reproduce this error (https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/amd64/p/php-horde-core/20180216_012156_effd8@/log.gz)
<xevious> nacc: I'm done. Have a good night. See you on the onlines tomorry.
<xevious> nacc: Looks like php-parser needs to be prodded for ppc64el.
<tsimonq2> tjaalton: Looking more at this patch that fixes Qt with the new mesa, there's some problems upstream with it getting approved. Solus and openSUSE have the patch now but I think generally in Ubuntu and Debian we're in agreement that we shouldn't follow suit until it's ready for review upstream. I'll keep you posted, but that's where it's at right now.
<nacc> xevious: thanks, retrigged
<tjaalton> tsimonq2: ok, good to know
<tsimonq2> tjaalton: Did you get a chance to look at that xorg script that doesn't follow the XDG spec?
<tsimonq2> (for lack of a better reference... heh)
<tjaalton> not yet
<tsimonq2> Alright.
 * mvo hugs rbalint for automatic kernel cleanup in unattended-upgrades
<rbalint> mvo: :-)
<Unit193> juliank: Pokepoke?  Did you happen to see my ping the other day?
<doko> jamespage, fyi: <zigo> doko: FYI, I'm currently flipping the switch to Py3 for all OpenStack stuff.
<jamespage> doko: yeah that's quite optimistic
<doko> jamespage: debian imports are still on ...
 * jamespage shrugs
<jamespage> doko: debian and ubuntu don't merge/sync on openstack packages anyway
<jamespage> doko: and zigo is putting all of that work into experimental first
<doko> ahh, ok
<ahasenack> hi, could an AA please take a look at the new queue for this libzstd sru please?
<ahasenack> https://launchpad.net/ubuntu/xenial/+queue?queue_state=0&queue_text=
<ahasenack> xenial, artful
<jamespage> doko: and his freeze is alot further away than ours :-)
<jamespage> based on my exp of the single openstack package we have migrated, there are lots of paper cuts and its not fully backed into the upstream testing
<pitti> cjwatson: hello Colin, how are you?
<pitti> cjwatson: I'm trying to change https://code.launchpad.net/~pitti/systemd/+git/debian to the new location at salsa.d.o.
<pitti> I can't seem to find that - easier to delete and recreate the branch? or does that need some admin review too?
 * pitti deletes and recreates it
<jbicha> doko: ring FTBFS in Ubuntu and has no rdepends. Would you be interested in kicking it out of bionic when I do the evolution-data-server transition?
<dgadomski> hello, could anyone please take a look at bug #1644662? there's a trivial patch to be sponsored there, thanks
<ubottu> bug 1644662 in gnome-themes-standard (Ubuntu Bionic) "Icons missing when appearance setting is "high contrast"" [Undecided,New] https://launchpad.net/bugs/1644662
<jbicha> dgadomski: the bionic part of that is fixed in https://ftp-master.debian.org/new/gnome-themes-extra_3.27.90.1-1.html
<jbicha> upstream changed the source package name so it'll need to go through the new queues
<jbicha> unless you were in a hurry and wanted it in bionic faster so that you could do a SRU?
<dgadomski> jbicha: exactly, the fact it's missing in bionic is blocking our users waiting for SRU in xenial
<slashd> jbicha, if you sponsor bionic (which is a SRU requirement). I'll sponsor dgadomski for the stable release with my SRU uploader right.
<jbicha> slashd: ok, I'll upload it to bionic now
<slashd> jbicha, tks
<slashd> dgadomski, ^
<slashd> ddstreet, fyi ^
<dgadomski> thanks jbicha
<ddstreet> thnx
<jbicha> dgadomski: done: https://launchpad.net/ubuntu/+source/gnome-themes-standard/3.22.3-3ubuntu2
<xevious> nacc: Good morning. How are things looking on your end? I updated the gist this morning: https://gist.github.com/iammattcoleman/88013cb5f92105b15a66ee2ada442a16#file-2018-02-15_181233_php-defaults_issues-md
<nacc> xevious: uploaded a few horde fixes already
<nacc> xevious: otherwise same old same old )
<xevious> nacc: What about just removing unused packages? The Sabre libraries are unmaintained and only two packages are showing any reverse-dependencies: php-sabre-dav, which uses php-sabre-vobject. Can we remove the other Sabre packages?
<xevious> php-sabre-dav is only used by php-horde-dav
<nacc> xevious: can you see if they are removed in debian testing (rmadison -u debian <srcpkg>) and if there are bugs filed there
<xevious> nacc: They're all showing "source, all" in both stable and unstable when I run rmadison on them.
<nacc> xevious: ah that emans removed from testing
<xevious> Ah, yeah. php-sabre-dav shows a lot more than just stable and unstable.
<nacc> https://bugs.launchpad.net/bugs/1749783
<ubottu> Launchpad bug 1749783 in php-phpdocumentor-reflection (Ubuntu) "php-defaults stuck in bionic-proposed" [Undecided,Fix released]
<nacc> xevious: feel free to add srcpkg task there
<nacc> (also affects distribution/package)
<nacc> xevious: also, i would appreciate a sanity check if you can. Can you run the autopkgtest for php-horde-core locally with just php-defaults from proposed (or all proposed) and see if it passes?
<xevious> nacc: Running it with all of proposed, since I haven't learned how to enable a single package from proposed yet.
<nacc> xevious: something like --apt-pocket=proposed=src:<srcpkg>, or =proposed=<binpkg>
<xevious> Oh, that's pretty simple.
<nacc> yeah it's handy
<nacc> and that's basiclaly what the retry triggers end up translating too
<nacc> *to
<xevious> The Zeta components are another thing I'd like to see phased out, since they're also very old and unmaintained. However, they're used by `phpab` (only, nothing else uses them), but that's a build dependency of a ton of PHP packages.
<nacc> xevious: does phpab depend on it upstrea too?
<xevious> Yes
<nacc> xevious: yeah hard for us to diverge there
<xevious> Although, if we switch to having the packages contain their full Composer dependency stack, then it wouldn't matter.
<nacc> xevious: yeah i'm drafting that up soon
<nacc> although i'm going the other direction
<nacc> let's drop php* in universe :)
<nacc> with your suggestion hopefully being a middle ground if there is pushback
<xevious> There are several PHP applications that sysadmins probably want to be able to install via packages.
<xevious> Zabbix, etc.
<nacc> imo, i think they should be snaps
<nacc> not debian packages
<nacc> the packages get out of date too quick
<nacc> and if they are snpas, we might be able to get the upstream to maintain them :)
<nacc> we can provide the infrastructure to use for building the snap using the right dependencies (basically the php runtie)
<nacc> but it doesn't really make sense for, e.g., me to try and maintain zabbix in ubuntu
<xevious> The thing slowing down the packages is just the fact that we can't have two different versions of the same PHP library installed via APT.
<nacc> i never have used it :)
<nacc> well, there is that and there is backwards-incompatible changes
<nacc> we are in between both now
<xevious> So, since those sabre packages aren't in testing, does that mean we can remove them from bionic?
<nacc> xevious: should be ok, yeah
<nacc> xevious: they can then come back in via unstable and get wedged in proposed separately, if they gt fixed
<nacc> xevious: making good progress on horde
<nacc> it's just all knotted together
<nacc> so it's not worth me retrying too much until i get them all fixed
<nacc> xevious: any luck getting php-horde-core to fail? i'm stumped no it
<nacc> *on*
<ahasenack> is it ok, in general, to call apt-cache policy in a maintainer script like postinst?
<ahasenack> I'm wondering about locks and such
<nacc> ahasenack: is this to see if a package is isntalled?
<ahasenack> sort of, it's to see if a repository is available
<ahasenack> like a ppa
<xevious> nacc: No, it passed. Lots of tests that "need some love"
<nacc> xevious: yeah, that's what i see too
<ddstreet> jbicha re: gnome-themes-standard, it seems the pkg does a fancy dance to update the debian/control file 'Uploaders:', based on content of the currently-installed /usr/share/gnome-pkg-tools/1/rules/uploaders.mk file, you aware of that?  should i just let that field get upated and sponsor/upload the sru with a changed Uploaders: entry?
<nacc> xevious: but consistently fails on launchpad :/
<nacc> xevious: i'll come back to it last
<nacc> ahasenack: hrm
<ddstreet> jbicha e.g. for artful sru, it changed the control file Uploaders as:
<ddstreet> -Uploaders: Dmitry Shachnev <mitya57@debian.org>, Jeremy Bicha <jbicha@ubuntu.com>, Laurent Bigonville <bigon@debian.org>, Michael Biebl <biebl@debian.org>
<ddstreet> +Uploaders: Dmitry Shachnev <mitya57@debian.org>, Emilio Pozuelo Monfort <pochu@debian.org>, Laurent Bigonville <bigon@debian.org>, Michael Biebl <biebl@debian.org>
<ahasenack> I could grep /etc/apt/sources.list.d/*, also maybe /etc/apt/sources.list
<ahasenack> but apt-cache policy would also tell me if the repo I'm looking for has pinning
<ahasenack> the use case is that a new version of ua-tools will enable pinning for the fips repository, but only for new installs
<nacc> ahasenack: yeah, it just seems ... not great, to parse that output
<ahasenack> and I'm wondering how to check a) that fips is in use already (the tool itself uses apt-cache policy + uname -r);
<ahasenack> and b) if pinning is configured already or not
<ahasenack> it looked more resilient to use apt-cache policy than to look for the specific config files we create
<ahasenack> but I might as well call the case of the user having renamed the files a corner case
<nacc> ahasenack: yeah, i'm just not sure either is great :)
<ahasenack> right
<xevious> nacc: I'm going to do the Zeta packages, since they have to be updated for phpab.
<nacc> xevious: thanks
<nacc> xevious: did you look at php-numbers-words alrady?
<nacc> xevious: beause afaict, we just have horde and zeta and sabre right now?
<xevious> php-numbers-words is another old, unmaintained project.
<xevious> It's only *recommended* by php-text-captcha, not a hard requirement.
<nacc> does it pass with the sed?
<nacc> i'll check
<nacc> xevious: yea looks like it will, needs a count replacement too
<nacc> will do it after kid pickup
<xevious> nacc: Should I run `quilt pop -a` before generating the debdiff?
<xevious> nacc: Can you check out the patch on this ticket? https://bugs.launchpad.net/ubuntu/+source/php-zeta-unit-test/+bug/1750041
<ubottu> Launchpad bug 1750041 in php-zeta-unit-test (Ubuntu) "incompatible with PHPUnit 6" [Undecided,New]
<xevious> nacc: If it looks good, can you merge it and rerun the tests for php-zeta-base and php-zeta-console-tools with it?
<xevious> nacc: I'm doing a non-marathon day today, so I'll be calling it quits soon (going to the G3 concert in NYC!)
<jbicha> ddstreet: all the Debian GNOME pacakges do that debian/control.in thing. I wouldn't worry about it :)
<jbicha> the SRU Team doesn't worry about that field so either change it or don't change it is fine
<ddstreet> jbicha awesome, i figured as much, thnx
<nacc> xevious: reviewing it now
<nacc> xevious: thanks! enjoy the show!
<cjwatson> pitti: I could've done it, but was on leave today.  I see you deleted and recreated it, so fine.
<nacc> why would request.cgi complain about a non-existent package only for certain archs (e.g., i386) when it's a all binary package? and it works for some of the arches
<nacc> is it just a matter of things being copied to the rigth spot?
#ubuntu-devel 2018-02-17
<themill> Hi! Is there a way to find out why a package was pulled from Debian experimental into bionic? I uploaded ktikz to experimental because I don't consider it ready for release... and now it's in an LTS.
<sarnold> infinity: any chance you're still awake and can take a look at themill's question? ^^
<Unit193> sarnold: slangasek was the one to sync it, so best to poke him.
<sarnold> Unit193: ah! thanks
<sarnold> slangasek: any chance you're still awake and can take a look at themill's question? ^^
<themill> I'm guessing it's an effort to get rid of Qt4 but I find pulling from experimental into LTS somewhat surprising.
<themill> (It's a random git snapshot from a branch that isn't even merged into master)
<Unit193> #ubuntu-release.2018-02-11.log:03:10:06 < slangasek> apw, doko: gawk, ktikz, octave-interval sorted; that leaves only linux-tools-* blocking binutils + mpfr4 + poppler
<Unit193> ...Annnd that was quite stupid of me.  I'm sorry.
<themill> ah, so it might be poppler-qt4
<slangasek> themill: well, the other option is that I can remove the package if it's not LTS-suitable... and if a poppler-qt4-less version makes it into unstable, we can sync that in its place
<themill> What's the timeline for that sync to happen?
<themill> Upstream is keen to get the kf5 (i.e. no more poppler-qt4) version into bionic but is time poor etc etc.
<slangasek> themill: if there's a new version in unstable by end of month, we would auto-sync it back in.  If after March 1, an Ubuntu dev would need to manually sync it
<themill> ok, that might be good leverage to get upstream moving
<slangasek> themill: should I delete the experimental version of ktikz now in anticipation of this?
<themill> Let's leave it there on the assumption I'll be able to replace it with this kf5 version soon enough
<slangasek> ok
<sarnold> thanks slangasek, themill :)
<themill> (depends on how much you want to play "always in a releaseable state" line you follow)
<sarnold> infinity: ^^ handled by slangasek :)
<themill> I'm mostly nervous about this being non-master and potentially a dead-end branch.
<xevious> nacc: I updated the gist: https://gist.github.com/iammattcoleman/88013cb5f92105b15a66ee2ada442a16
<tarzeau> i'm out of ideas, i know about this command: pkg-config --print-variables Qt5Core
<tarzeau> but i'm out of ideas how to get the mm3d 1.3.9 to build on ubuntu
<tarzeau> on debian it just builds/works (mm3d with qt5)
<tarzeau> patches/hints welcome
#ubuntu-devel 2018-02-18
<gsilvapt> Hello everyone. Can someone tell me how can I install autopkgtest from source?
<gsilvapt> Nevermind, got it
#ubuntu-devel 2019-02-11
<LocutusOfBorg> ahasenack, don't know...
<ahasenack> LocutusOfBorg: I got hold of him, thx anyway :)
<Odd_Bloke> I'm currently trying to upload a package who has a Build-Depends that requires a version in disco-proposed; I don't want to install it (and its dependency chain) from -proposed in my dev environment.  I've tried to use sbuild to build the source package a couple of times, and both have been rejected on upload.  Can anyone share with me a correct invocation of sbuild to do what I want?
<Odd_Bloke> (Or should I just be waiting until the package migrates from -proposed?)
<ahasenack> what was the rejection note about?
<Odd_Bloke> Missing source tarball; at the moment I'm running `sbuild --source-only-changes`.
<gQuigs> what package?
<rbasak> I'm not sure how to use sbuild to build the source package. I normally use dpkg-buildpackage directly, since a chroot isn't usually needed to build a source package.
<rbasak> In that case, "-S -sa" is what is needed.
<rbasak> To avoid installing build deps locally, you can use "-nc -d"
<rbasak> Then dpkg-buildpackage won't clean the working tree (you have to ensure its clean yourself) and doesn't need build dependencies locally to build the source package.
<rbasak> And "-S -sa" says to build a source package only, and include the orig tarball in the changes file.
<Odd_Bloke> OK, cool, I'll do that then.
<rbasak> IOW, make sure the source tree is clean yourself, then do "dpkg-buildpackage -S -sa -nc -d"
<Odd_Bloke> rbasak: Thanks for the help. :)
<rbasak> yw :)
<kenvandine> cjwatson: can you help me figure out what's wrong with the git repo mirroring for gedit?  https://code.launchpad.net/~gnome3-team/gedit/+git/gedit
<kenvandine> the scan fails but no hints as to why and what we can do to fix it
<cjwatson> kenvandine: did you already try pressing the rescan button?
<kenvandine> cjwatson: yeah... same thing
<kenvandine> it's been broken for ages
<kenvandine> we've dropped the mirror and re-added too
<cjwatson> don't do that
<cjwatson> at best you might make things harder to debug
<cjwatson> kenvandine: I see the problem but need a sysadmin to be around to bounce a service for me, and I'm EOD.  Please file a ticket (https://answers.launchpad.net/launchpad)
<cjwatson> I don't know what the problem was before you deleted and readded, but it looks simple enough now
<kenvandine> cjwatson: will do, thanks
<cjwatson> cheers
#ubuntu-devel 2019-02-12
<kstenerud> Can someone help me out with questions about debian/control? I have a package that breaks itself and replaces itself, but I can't find info in https://www.debian.org/doc/debian-policy/ch-relationships.html that explains what this is for (every mention of it says "see below", but never actually explains)
<cjwatson> kstenerud: Can you pastebin the whole debian/control?
<Faux> https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-in-other-packages ?
<cjwatson> kstenerud: I believe that the "see below" is simply a reference to the definition of Provides
<kstenerud> http://paste.ubuntu.com/p/DR7g5HsyRx/
<cjwatson> kstenerud: I don't see any self-Breaks/Replaces there
<cjwatson> kstenerud: Two packages have Breaks/Replaces on similar but distinct package names (extra ".0")
<kstenerud> OK, I'm not sure I follow. Why would there be all these different package names?
<cjwatson> kstenerud: It looks like just a package rename
<kstenerud> Basically: If I can remove the Breaks delta, that removes the remaining delta on the tomcat8 package, so I want to know if I can safely remove the delta and turn this into a sync
<cjwatson> kstenerud: That is, at some point the maintainer felt it best to rename libtomcat8.0-java to libtomcat8-java and tomcat8.0-user to tomcat8-user, and the Breaks/Replaces would be to make the upgrade proceed smoothly
<rbasak> kstenerud: remember I said it was likely to need to remain until after the next LTS?
<rbasak> kstenerud: if you can figure out when the rename took place, that'll tell us when it can be removed.
<cjwatson> The history is in https://bugs.launchpad.net/ubuntu/+source/tomcat8.0/+bug/1717998
<ubottu> Launchpad bug 1717998 in tomcat8.0 (Ubuntu) "Please remove tomcat8.0 before 18.04 releases" [High,Fix released]
<cjwatson> So you can see there that those binaries were in cosmic, so removing that delta has to wait until after 20.04
<kstenerud> ok
<cjwatson> (because otherwise, somebody who's upgrading through a supported upgrade path may find that they have the old package name installed, apt schedules the replacement package for installation, and then dpkg would throw an error when trying to unpack the replacement package because it ships files from another package without an appropriate Replaces)
<rbasak> If backporting 0.23.0-1 from Bionic to Xenial, what would be the best version number string to use? I don't see a standard documented anywhere; what's the de-facto standard? 0.23.0-1~16.04.1 perhaps? Or an "ubuntu" in there somewhere?
<rbasak> For 0.22.2-1ubuntu0.1 I was going to use 0.22.2-1ubuntu0.1~16.04.1 - is that sensible?
<rbasak> (this is the certbot backport that will be SRU'd)
<cjwatson> rbasak: The de-facto standard is whatever backportpackage(1) does
<cjwatson> which I think would be ~ubuntu16.04.1
<cjwatson> (yes, this does result in duplicate "ubuntu" sometimes)
<rbasak> Ah, I didn't think to look there. Thanks!
 * rbasak likes standards
<Skuggen> Good thing there are so many of them, then :)
<rbasak> :)
 * rbasak will try to avoid creating another one
<seb128> jbicha, just curious but why libnotify did a "no change upload for autopkgtest"?
<jbicha> seb128: Locutus thought that maybe virtualbox/i386 wouldn't be triggered (see #ubuntu-release ) but it didn't work
<seb128> k
<jbicha> sorry but the explanation felt too wordy for debian/changelog
<seb128> it's just the first time I see a no change upload for autopkgtests, usually those can be retried/hinted without needing uploads
<LocutusOfBorg> seb128, I thought a new upload wouldn't trigger that i386 autopkgtest, and looks like I was wrong
<LocutusOfBorg> probably kernel didn't trigger it because it is built only on amd64...
<Laney> but why do that in the archive?
<LocutusOfBorg> Laney, how could we do it otherwise?
<LocutusOfBorg> looks like qtbase is not triggering vbox/i386 autopkgtest for virtualbox/6.0.4-dfsg-5: amd64: Pass
<Laney> silo?
<LocutusOfBorg> that usually means autopkgtests runs twice (but your point is valid, I didn't trigger the no-change rebuild, even if I proposed it)
<LocutusOfBorg> anyway, [12:01:50] <LocutusOfBorg>  ./sil2100:force-badtest virtualbox-ext-pack/all/i386
<LocutusOfBorg> [12:02:02] <LocutusOfBorg> can we please add virtualbox/all/i386? same reason for it...
<Laney> Doesn't seem to me to be an appropriate use of the archive
<talx> is it possible to get here
<talx> for preseed installation
<teward> talx: support in #ubuntu or #ubuntu-server but it looks like you already were helped about 3 hours ago in #ubuntu-server?
<talx> nope
<talx> the issue isn't solved for me
<teward> talx: well, support is still in #ubuntu or #ubuntu-server, not here.
<talx> oh
<teward> this channel is specific for ubuntu development, not support.
<talx> I was directred to here
<talx> no intention to disrespect
<teward> no problem :)
<vorlon> stgraber, kees: TB meeting?
<Eickmeyer> Odd question: I'm trying to fork the Lubuntu plymouth theme (obvious fork of the Ubuntu plymouth theme) for Ubuntu Studio by merely replacing the Lubuntu logo with the Ubuntu Studio logo and changing the background to a dark gray (RGB 0.17 0.17 0.17), but it keeps crashing. Trying to figure out what I'm doing wrong.
<Eickmeyer> I've tried changing the size of the logo (a png file) but I'm getting nowhere.
<Eickmeyer> Reason for the change: our existing plymouth theme is long-in-the-tooth and doesn't scale well.
<sarnold> what crashes, where?
<Eickmeyer> sarnold: plymouth during boot.
<JackFrost> ...Ugh, libotr5-dev is in universe..
#ubuntu-devel 2019-02-13
<riiot232> hello
<coreycb> bdmurray: thanks for helping move bug 1809454 along. would you be able to take a look at bionic today?
<ubottu> bug 1809454 in OpenStack Compute (nova) queens "[SRU] nova rbd auth fallback uses cinder user with libvirt secret" [Medium,In progress] https://launchpad.net/bugs/1809454
<cpaelzer> coreycb: is the 18.04.2 freeze lifted already ?
<coreycb> cpaelzer: ahh, maybe not.
<coreycb> cpaelzer: do you think we can re-evaluate this MIR? https://bugs.launchpad.net/ubuntu/+source/placement/+bug/1805691
<ubottu> Launchpad bug 1805691 in placement (Ubuntu) "[MIR] placement" [Undecided,Expired]
<coreycb> the security team ACKed it I believe
<coreycb> i don't think nova is going to drop their placement support until train (corresponds to Ubuntu E release) but it would be nice if we could move forward with charm changes
<cpaelzer> coreycb: yes and done
<coreycb> thanks very much cpaelzer
<seb128> if some wonder why retracing are failing recently in disco, bug #1815774
<ubottu> bug 1815774 in binutils (Ubuntu) "binutils 2.32 update breaks debug symbols in disco" [High,New] https://launchpad.net/bugs/1815774
<seb128> doko, ^
<riiot232> hello
<riiot232> is some one there.....?
<LtWorf> riiot232: no :P
<riiot232> :l
<riiot232> why?
<riiot232> where is every one at?
<LtWorf> (i was kidding)
<riiot232> ok.
<riiot232> so are u dev?
<LtWorf> anyway i'm more active on debian, which is oftc rather than freenode
<riiot232> ok
<bdmurray> seb128: How did you find bug 1815774? Were you manually retracing something or looking at logs / failures to retrace?
<ubottu> bug 1815774 in binutils (Ubuntu) "binutils 2.32 update breaks debug symbols in disco" [High,New] https://launchpad.net/bugs/1815774
<LtWorf> riiot232: very minor contributions in debian, that then end up in ubuntu
<seb128> bdmurray, I wondered why we got a few bugs invalidated by the retracers so I decided to try to sigsegv g-c-c locally and see what was the problem
<riiot232> LtWorf ok
<riiot232> how do I say ur name?
<seb128> bdmurray, which gave me the warnings described in the bug, which I google for, found thar arch bug...
<bdmurray> seb128: Hmm, I thought I was subscribed to apport-failed-retrace but didn't notice anything. I'll have to dig.
<seb128> bdmurray, https://bugs.launchpad.net/ubuntu/+source/gnome-control-center/+bug/1815703
<ubottu> Error: launchpad bug 1815703 not found
<seb128> https://bugs.launchpad.net/ubuntu/+source/gnome-control-center/+bug/1815704
<ubottu> Error: launchpad bug 1815704 not found
<seb128> if you want some examples
<bdmurray> seb128: cool, thanks
<seb128> bdmurray, they didn't got tagged apport-failed-retrace it looks like, just untagged
<bdmurray> what's up with that ascii art?
<seb128> so maybe an apport bug there
<seb128> lol, good question :)
<bdmurray> ah, well then
<bdmurray> wow, pretty colors too
<chiluk> So I discovered today that my ubuntu one login has 2fa enabled, but since I'm no longer at Canonical, I'm no longer in the correct groups that tell Ubuntu One I need to see 2fa configuration pages... Seems like we should auto-enroll all members of ex-canonical in sso-2f-testers  *(or maybe some other group)..  The strangest thing was that I was able to log in to ubuntu one using only my user/pass, but when trying to enable
<chiluk> livepatch it required my 2fa ..
<chiluk> who owns ubuntu sso / one login now?
<cjwatson> the snap store team
<cjwatson> What you describe is interesting; I've heard people with this problem before but not the specifics about logging into login.u.c directly vs. via something like livepatch
<cjwatson> Though it's possibly related to the same kind of thing that caused https://bugs.launchpad.net/canonical-identity-provider/+bug/1073074
<ubottu> Launchpad bug 1073074 in Canonical SSO provider "sso prevents login when 2f required but user doesn't have 2F feature available" [High,Confirmed]
<chiluk> Cool I'll move conversation to that bug..
<cjwatson> I'm not certain it's the same thing, so I'd suggest a new bug
<cjwatson> Can always be duped later
<chiluk> Yeah I'll proceed with due diligence.
<cjwatson> I don't think auto-adding people to a team is the solution
<chiluk> I'm not sure what the right answer is either.. nor do I have the power any more.
<cjwatson> Well, it seems that if a user is set to require 2FA then we should show them 2FA ...
<cjwatson> (which is what I thought the behaviour was, but the difference between direct login and via livepatch suggests maybe not on all code paths)
<chiluk> right..
<chiluk> also explains why I haven't noticed till now..
<cjwatson> chiluk: livepatch via CLI or OpenID?
<chiluk> It was via the "Software & Updates" application...  I forget what the actual runtime is for that.
<cjwatson> chiluk: OK, worth also trying something that's definitely OpenID, e.g. open a private browser window and try to sign into LP using it
<chiluk> although I think I hit this via cli before as well when following the livepatch instructions.
<cjwatson> I have to go out shortly though
<chiluk> now I'm really confused.. via a private browser it required 2fa..
<chiluk> so it could likely be the same issue.
<cjwatson> chiluk: And double-check direct login to login.u.c via a private browser?
<chiluk> yeah also requires 2fa..
<cjwatson> so I'm not sure what you mean by "I was able to log in to ubuntu one using only my user/pass"
<chiluk> I was just added to https://launchpad.net/~sso-2f-testers ... and can now configure the 2fa devices..
<cjwatson> oh
<cjwatson> in that case all tests after the point when you were added to that team should be flagged as uninteresting for the purpose of this bug
<cjwatson> evidence now invalid
<chiluk> yeah.
<chiluk> I'm not sure when that exactly happened.
<cjwatson> LP should have the timestamp
<chiluk> right but I dont' have timestamps on my browsers.
<cjwatson> ah
<cjwatson> well, it happened at 15:53:25
<cjwatson> which was a couple of minutes before you asked about it here
<cjwatson> so anything you did in response to my questions can't be useful evidence
<chiluk> yeah.
<cjwatson> oh well
<chiluk> cjwatson want to remove me from sso-2f-testers  to retest?
<chiluk> does it matter?
<chiluk> I'm willing to help out for a few minutes if you are intrigued.
<chiluk> I figure you getting removed from canonical might be more prohibitive for testing.
<cjwatson> (a) I can't do that since I'm not an admin of sso-2f-testers, (b) we can set up a similar situation with a local SSO deployment, (c) I have to go out
<cjwatson> so thanks but we should be able to manage :)
<chiluk> sure thing..
<chiluk> it's been nice seeing an old-familiar nic...
<chiluk> I haven't played here in far too long.
<roadmr> chiluk: hey, I enabled your 2fa group membership, so maybe I can help, but give me a few because I'm busy atm
<chiluk> yeah my day is pretty busy too..
<cjwatson> ah, roadmr is likely in a better position to help with this than I am anyway, excellent
<chiluk> roadmr: I described what I was seeing here : https://bugs.launchpad.net/canonical-identity-provider/+bug/1073074    I think the two are probably the same.
<ubottu> Launchpad bug 1073074 in Canonical SSO provider "sso prevents login when 2f required but user doesn't have 2F feature available" [High,Confirmed]
<roadmr> chiluk: ok, reading the bug now and I checked the backlog as well
<roadmr> chiluk: ok so to summarize, as an ex-canonicaler, you saw different 2fa requirements for API (i.e. gnome-software) vs. web (login.ubuntu.com) ?
<roadmr> chiluk: the code does have custom logic for how to decide 2fa-ness for someone in canonical vs. someone in ~sso-2f-testers
<roadmr> so that's where I'd start looking but it does look like a bug. I'll investigate!
<roadmr> chiluk: and to be clear, are things working well for you now?
<chiluk> Yeah things are fine now.
<chiluk> the weirdest thing is that openid/web login seemed to work fine and did not require 2fa...
<roadmr> yes, that's weird
<chiluk> and I'm positive of this because I've been using launchpad for years without my yubikey..
<chiluk> today I had to go grab my old yubikey that I had previously had linked.
<chiluk> all my devices were still configured.
<roadmr> chiluk: which email address do you use to log in these days? (you can pm it to me if you don't want to expose it here)
<roadmr> this is so I can look you up and check your account setup, so I can then trace how the logic handles your login attempts via api vs. web
<chiluk> Including my old @canonical authenticator app. *(I actually wonder if that is a mini security hole)...
<chiluk> is there a better channel for this?  no need to spam everyone here.
<roaksoax> ~/win 4
<sparr> is there an appropriate channel for support-in-investigating-and-filing-a-bug-report in a mainline kernel package?
<rbasak> sparr: mainline as in upstream? Or Ubuntu?
<rbasak> For Ubuntu, #ubuntu-kernel
<sparr> thanks
<roaksoax> /win/win 4
<seb128> wgrant, cjwatson, hey, can we open disco for translations?
<wgrant> seb128: I believe it's just blocked on UTC turning it on
<wgrant> Oh, or maybe not
<wgrant> Hm
<wgrant> Apparently we never initialised it
<wgrant> Things are a bit on fire atm, may be able to look later.
<seb128> wgrant, no hurry, thx
#ubuntu-devel 2019-02-14
<sparr> https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.0-rc6/ has five patch files that are applied to the source before building the mainline kernel
<sparr> https://help.ubuntu.com/community/Kernel/Compile and https://wiki.ubuntu.com/KernelTeam/GitKernelBuild don't mention those steps
<sparr> if I am trying to build a kernel that is as close as possible to the ubuntu packaged kernels, should I be applying those or any other patches?
<sparr> aww, damnit, sorry, all that belongs in another channel. sorry
<LocutusOfBorg> hello oSoMoN
<oSoMoN> hi LocutusOfBorg
<LocutusOfBorg> can I upload a chromium fix for https://bugs.launchpad.net/ubuntu/+source/python-selenium/+bug/1667208 ?
<ubottu> Launchpad bug 1667208 in python-selenium (Ubuntu) "Ubuntu's selenium hardcodes a path that is valid for Debian, but not for Ubuntu" [Undecided,Confirmed]
<LocutusOfBorg> my wild guess is: let chromium-chromedriver provide chromium-driver
<LocutusOfBorg> and add a symlink from /usr/lib/chromium-browser/chromedriver to /usr/bin/chromedriver
<LocutusOfBorg> this way chromium should expose the same binary packages as debian, and the binary would be in the same location, so applications can use it
<oSoMoN> LocutusOfBorg, why not patch python-selenium to change the hardcoded path?
<LocutusOfBorg> because we would need to patch all the reverse-dependencies if we do it that way...
<LocutusOfBorg> do you have a reason for exposing tools in a different location with debian?
<oSoMoN> no specific reason, just trying to figure out the least invasive fix â I'm not sure IÂ understand why reverse deps would need to be patched, if the path is already in python-selenium, do other packages hardcode it too?
<LocutusOfBorg> maybe ruby-selenium-webdriver?
<LocutusOfBorg> not sure how many else...
<LocutusOfBorg> ./lib/selenium/webdriver/chrome/service.rb:        @executable = 'chromedriver'.freeze
<LocutusOfBorg> ./lib/selenium/webdriver/chrome/service.rb:          Unable to find chromedriver. Please download the server from
<LocutusOfBorg> if applications are supposed to find it in $PATH, I think we should patch chromium...
<oSoMoN> that makes sense
<LocutusOfBorg> in the future more applications might start using it, this is why I think the binary package should be provided and the tool exposed in the system in a sane-way, otherwise we might not even have a way to find what in the archive breaks because of this
<oSoMoN> LocutusOfBorg, please do not upload the fix right away though, as there's a new release in the stable channel for which I was preparing an upload when you pinged, if you make a patch and hand it to me I'll include it
<LocutusOfBorg> oSoMoN, I think I'll reassing the bug to chromium, and I'm already looking at how debian did it, I'll provide a patch shortly
<LocutusOfBorg> thanks for confirming my analysis, I'm of course not a chromium user/developer :)
<oSoMoN> LocutusOfBorg, thanks, I'll put my upload on hold until I get your patch
<LocutusOfBorg> mmm interesting, the debian package is 100MB, the Ubuntu one is 700MB
<oSoMoN> I haven't checked in a while, they probably strip down the upstream source tarball
<LocutusOfBorg> since nobody is using the old location https://codesearch.debian.net/search?q=browser%2Fchromedriver
<LocutusOfBorg> I think I will avoid the symlink
<LocutusOfBorg> https://paste.ubuntu.com/p/5TQn4kBMv6/
<LocutusOfBorg> oSoMoN, ^^ it takes more time for the debdiff than for the patch itself...
<oSoMoN> LocutusOfBorg, note that the description of bug #1667208 is incorrect, it says "/usr/lib/chromium/chromedriver" but it's "/usr/bin/chromedriver"
<ubottu> bug 1667208 in chromium-browser (Ubuntu) "Ubuntu's selenium hardcodes a path that is valid for Debian, but not for Ubuntu" [Undecided,Confirmed] https://launchpad.net/bugs/1667208
<LocutusOfBorg> true...
<oSoMoN> LocutusOfBorg, here is an updated diff, would you mind giving it a sanity check? https://paste.ubuntu.com/p/mdzS9BGmVt/
<LocutusOfBorg> yes, I like it!
<LocutusOfBorg> of course if it builds :)
<oSoMoN> wait, I forgot the provides line
<oSoMoN> adding it
<LocutusOfBorg> oops true
<rbasak> In backporting certbot from Bionic to Xenial, dh_installsystemd no longer exists which I think is causing the timer and service to no longer be installed.
<rbasak> Suggestions?
<rbasak> How were systemd services installed back then?
<LocutusOfBorg> rbasak, hold on
<LocutusOfBorg>  dh-systemd | 1.29ubuntu4                 | xenial-updates/universe   | all
<LocutusOfBorg>  dh-systemd | 10.2.2ubuntu1~ubuntu16.04.1 | xenial-backports/universe | all
<LocutusOfBorg> using dh-systemd from backports should work...
<LocutusOfBorg> rbasak, is it ok?
<LocutusOfBorg> anyway, you should build-depend on dh-systemd (>= 1.5) on control file, it wasn't part of debhelper at that time
<rbasak> I can do that. Thanks!
<LocutusOfBorg> in virtualbox/xenial I simply do dh --with systemd
<LocutusOfBorg> and it should take care of mostly of it...
<rbasak> I'll give that a try.
<rbasak> I had completely forgotten about dh-systemd!
<LocutusOfBorg> man dh_systemd_enable should give you the best answer :)
<LocutusOfBorg> it took me a while to that back in time :)
<rbasak> Oh. It's in backports?
<rbasak> This is for an SRU.
<rbasak> Will 1.29 be enough?
<rbasak> It's >= 1.5 of course ;)
<LocutusOfBorg> not sure, vbox uses virtualbox.service IIRC and it works
<rbasak> It looks like certbot.service got installed but not the timer.
<rbasak> And the override_dh_installsystemd didn't run.
<rbasak> But I can trawl through the docs now. Thanks again!
<LocutusOfBorg> override_dh_systemd_enable:
<LocutusOfBorg>         dh_systemd_enable -p$(sname) --name vboxweb --no-enable debian/vboxweb.service
<LocutusOfBorg> this is what I did in vbox for non-standard services names
<LocutusOfBorg> if it is non-standard naming you should anyway tell it how to enable
<rbasak> dh_systemd_enable: Could not find "certbot.timer" in the /lib/systemd/system directory of certbot. This could be a typo, or using Also= with a service file from another package. Please check carefully that this message is harmless.
<rbasak> Maybe I can just installed that manually with dh_install
<rbasak> (well, certbot.install)
<rbasak> The certbot.service is ending up in the deb though.
<Ark74> ricotz, hello!
<Ark74> I've being studiying the libreoffice ppa compilation/build.
<Ark74> Is this a good place to ask about it?
<hggdh> kenvandine: ping re. a few gnome packages and snaps
<kenvandine> hggdh: pong
<hggdh> kenvandine: we compared the installed snaps from a Disco RC with an upgraded-to-Disco install. The RC install brings in gnome-(calculator|characters|logs|system-monitor), while on the already-existing system these are all (Disco) packages
<hggdh> kenvandine: even more, at least gnome-calculator is at a different version package x snap
<kenvandine> hggdh: upgraded from what?
<kenvandine> disco has the devel series of the debs
<kenvandine> the snaps are built from the upstream stable series
<kenvandine> which is still 3.30.x
<kenvandine> once that hits 3.32 the snaps will as well
<hggdh> kenvandine: the upgraded system was Bionic->Cossmic->Disco
<kenvandine> bionic shipped with those 4 as snaps not debs
<kenvandine> so it should have the snaps instead
<kenvandine> hggdh: could it have been an upgrade from a bionic system that was originally installed before bionic release?
<kenvandine> the switch to the snaps was pretty late
<hggdh> my snap list only shows gnome-common-themes
<kenvandine> they were seeded pretty late, so if you installed around beta you wouldn't have gotten the snaps
<hggdh> kenvandine: it *might*, yes. I got the laptop in... Feb 2018, so before release
<kenvandine> ah, yeah they weren't seeded yet
<hggdh> yeah
<kenvandine> so they would have been there as debs
<hggdh> k. Still, then, we now have two different paths -- older systems still carry the package, new ones carry the snap
<hggdh> but they are at different versions. The gnome-calculator package on Disco is 1:3.31.90-1ubuntu1, the snap (stable) is 3.30
<hggdh> (edge does have a 3.31.90)
<kenvandine> yeah
<kenvandine> that's the intent
<zimmerian> so this is probably a larger apt / dpkg thign but on remove my symlink gets removed
<zimmerian> nothing in post pre scripts
<zimmerian> is this a known bug?
<zimmerian> or could it be the upgrading package at fault?
<cjwatson> not very clear what you mean - how is this symlink created?
<infinity> ^
<infinity> Need more info here.  What symlink, what package is being removed, does the package believe it exclusively owns that path?
<infinity> dpkg makes no real distinction between links and files
<cjwatson> (except for some details around symlinks vs. directories on upgrade)
<zimmerian> k - let me look a bit deeper I think I may know what's going on - sorry and thanks
<cjwatson> Certainly if a symlink is shipped in a .deb then it'll be removed when that package is removed.
<cjwatson> Intentionally
<infinity> Or if you replace a file shipped by a deb with a symlink.
<infinity> Same story.
<zimmerian> okay nope - still confused â¦ so more info time - let me write this to be more clear and concise :-)
<zimmerian> alright - I hope this helps
<zimmerian> https://pastebin.com/bw1MpGDU
<sarnold> maybe start with ls -l and dpkg -L output with the old version and new version of your package
<cjwatson> It's possible that dpkg feels itself entitled to clean up the top-level directory (actually a symlink) when there was previously exactly one package using it and then that package was removed.
<cjwatson> Not really specific to /opt except that packages generally don't install under /opt but apparently this one does.
<zimmerian> cjwatson: that is true - it is the only package afaik
<zimmerian> and yes - I fig'd that but this is the only package using /opt :-)
<cjwatson> Not sure if there's a good way to avoid that here.
<cjwatson> It's just generic "remove cruft that appears to be no longer used" code
<zimmerian> hmm well I can create a stupid package with /opt/dont_delete_me or something
<zimmerian> maybe that'd work
<zimmerian> but curious if I should file this as a bug w/ debian
<infinity> It's not a bug.
<zimmerian> after I do actually test your theory - which seems to apply
<cjwatson> I mean you could, but I'm not sure how it would be fixable even in theory
<infinity> dpkg will always remove a directory when the last package owning it is removed.
<infinity> (if it's also empty)
<zimmerian> infinity: it's a symlink and there's other stuff that the symlink has -
<zimmerian> it's a bug IMO
<zimmerian>  /other/moar_stuff does exist
<infinity> It might be a bug if it's non-empty and dpkg has decided to treat it as a file instead of a directory.
<zimmerian> and so this has a larger impact
<cjwatson> The question is how it could possibly be fixed without breaking lots of other stuff
<cjwatson> But it's certainly not Ubuntu-specific, so if you wanted to pursue it then the proper place would be a bug report on Debian dpkg, yes
<zimmerian> cjwatson: true but I'm hoping somehow a test -L can be used - dunno
<zimmerian> thank you all!
<infinity> It's not about testing if it's a link and then not removing it.
<infinity> It's about resolving it, treating it as a directory, and then applying the directory tests.
<zimmerian> well to see if it is indeed because no other packages are using there
<infinity> (if not empty, don't remove)
<infinity> So it does indeed feel like a bug in this case, if the target isn't empty.
<zimmerian> yeah - I agree infinity but I think that would actually make it a bigger quest perhaps?
<cjwatson> dpkg just tries rmdir/unlink and ignores stuff like ENOTEMPTY; it doesn't look before it leaps
<zimmerian> not sure of the cost of delving into each / every item to see if there's something else if it's a symlink
<cjwatson> (if it has no remaining references to the thing)
<zimmerian> and it makes some sense from the apt / deb side
<cjwatson> nothing to do with apt
<cjwatson> purely dpkg
<cjwatson> whether it's a bug or not
<infinity> I mean, the word "bug" is perhaps not the right one here.  Misfeature. :P
<zimmerian> cool - well thanks all - I'll see what I can find
<zimmerian> hehehe true
<infinity> I think it's behaving as expected (by the people who wrote it), but those people could be seen to be wrong, based on what a user might expect in this case.
<cjwatson> It is mildly surprising, looking at the code, because it should try rmdir first, get ENOTEMPTY, give up before getting as far as the unlink that must have removed the symlink.  But I haven't often needed to look at this code so might be misreading something.
<infinity> cjwatson: Or, the misfeature was fixed, and you're reading a newer version than he's using.
<infinity> Guillem does have a nasty habit of improving dpkg occasionally.
<cjwatson> oh, I'm misreading
<cjwatson> rmdir would get ENOTDIR in that case, and then it falls through
<infinity> Ahh.
<infinity> But that also highlights a maybe-not-computationally-insane path to fixing it.
<infinity> If ENOTDIR, check linkiness, check contents of target, bail if not-empty.  *hand-wavy*
<cjwatson> Maaaaybe.  If there aren't legit cases that would break
 * cjwatson is happy for somebody else to think through that maze
<zimmerian> well I'll be - seems like way back this was a thing and well â¦ still is
<zimmerian> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=182747
<ubottu> Debian bug 182747 in dpkg "dpkg should not remove a symlink to a directory unless it's empty" [Wishlist,Open]
<cjwatson> Probably means it's hard :)
<zimmerian> â¦. and in true fashion - also /opt :-D
<infinity> Yeah.
<infinity> The real answer here might be to admit that /opt is a thing and ship it in base-files. :P
<infinity> google packages have similar potential issues.
<infinity> My hot take is that as soon as something is in deb/rpm form, it should be installing to system locations, not /usr/local or /srv or /opt, but obviusly there are those who disagree, and plenty of packages in the wild to prove it.
#ubuntu-devel 2019-02-15
<cpaelzer> sil2100: doko: vorlon: rcj:  fginther: tobikoch: I was just made aware (thanks tomreyn) that http://releases.ubuntu.com/18.04/ubuntu-18.04.2.0-live-server-amd64.iso.torrent on https://www.ubuntu.com/download/alternative-downloads#bittorrents is a 404 - I'd expect it to point to http://releases.ubuntu.com/18.04/ubuntu-18.04.2-live-server-amd64.iso.torrent instead
<cpaelzer> uh spam alert, but I just didn#t know who would pick tihs one up :-)
<rbasak> That might be one for IS (so #canonical-sysadmin).
<juliank> rbasak: i think it's design and the bug is an extra .0 in this page: https://github.com/canonical-websites/www.ubuntu.com/blob/master/templates/download/alternative-downloads.html
<infinity> (For the record, the above is being sorted)
<tomreyn> (And for the record, the real credit goes to 'yn' in #ubuntu, I just forwarded.)
<seb128> cpaelzer, on bug #1815978 your comment describe bionic details but the report/title is about xenial?
<ubottu> bug 1815978 in spamassassin (Ubuntu) "sa-compile broken on 16.04 LTS AMD64" [Undecided,Incomplete] https://launchpad.net/bugs/1815978
<seb128> hum
<seb128> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-disco/disco/armhf/s/software-properties/20190215_033903_76f69@/log.gz
<seb128> failed on
<seb128> 'Cannot add PPA: 'ppa:~xnox/ubuntu/nonvirt'.
<seb128> The user named '~xnox' has no PPA named 'ubuntu/nonvirt''
<seb128> xnox, ^ is that normal it uses your personal ppa?
<kstenerud> Does anyone here know how I could make a service that can, when an env is set, prevent the service from actually starting, but signal success so that the installer doesn't bail out?
<kstenerud> Or something similar... I need to update an initd script that does exactly that to a systemd script.
<rbasak> kstenerud: can you explain more about the problem you're trying to solve? How are you sure that's the right approach to take, for example?
<kstenerud> I don't know if I'm taking the right approach. The package needs a configuration, but doesn't provide one, so when the package is installed and started, it fails, and the installer fails.
<kstenerud> So the init script for it checks for a $RUN variable, and if set to "no", prints a message saying the service didn't really start, and please make a config file and change the run variable to "yes"
<rbasak> What do you mean by "installer"?
<kstenerud> apt
<rbasak> Which package is it?
<kstenerud> freeipmi
<kstenerud> it's been broken since cosmic
<kstenerud> https://bugs.launchpad.net/ubuntu/+source/freeipmi/+bug/1808637
<ubottu> Launchpad bug 1808637 in freeipmi (Ubuntu) "freeipmi-ipmidetect postinst fails on default install" [Undecided,Triaged]
<rbasak> Is it definitely impossible for the package to ship with a configuration that does work?
<kstenerud> freeipmi fails because no nodes are defined. And a node is whatever "thing" a user happens to want to make
<kstenerud> so maybe I could make some sort of default "thing", but I don't know enough about the package to know if it's possile
<rbasak> Is Debian impacted by this?
<rbasak> There is ConditionPathExists, but I don't see anything for an environment variable specifically.
<kstenerud> yup, just tested on debian and it also fails on postinstall
<rbasak> It's also possible to arrange for the service to not be enabled by default and expect the user to enable it, but then that could be different from init.d and therefore confusing.
<rbasak> I don't see any way to get an ExecStartPre failure to cause systemd to treat the service as not failed, but perhaps that's possible.
<rbasak> So there are a variety of options to solve the problem.
<kstenerud> The initd one just spits out a message telling the user to make a config and then change a setting to make the script really load the service
<rbasak> Maybe best to see which path the Debian maintainer takes.
<kstenerud> debian side is broken too. I just checked a sid container
<rbasak> Does a bug exist in Debian, and if not please could you file one?
<rbasak> Another way might be to make ExecStartPre cause a hard fail but don't attempt to start the service on install.
<kstenerud> so policy-wise, does this mean hold off on merge until debian fixes it?
<rbasak> But then it'd show as failed after next boot.
<Skuggen> You can set a service to disabled by default, can't you?
<Skuggen> We do this with the multi-instance service for MySQL upstream
<Skuggen> Oh, you already said that. nm :)
<rbasak> kstenerud: sorry, just saw your question. It's our shout policy-wise. The downside of fixing it now is the extra effort and possible UX problems if the Debian maintainer decides to fix it in a different way.
<rbasak> So I would give the Debian maintainer a few days to respond at least.
<jmgb4> Hey, just a quick question about how ubuntu packages things. Is there a way to see how a specific package (remmina) pulls down stuff like openssl and what the requirements are? Like a make file or an ebuild (like in gentoo)?
<teward> jmgb4: what do you mean by 'pulls down stuff'?  Most packages in Ubuntu are built based off the *other* packages and pulls them in at build/run time into the environment for use
<jmgb4> Dependencies teward
<teward> package dependencies are in debian/control for the given package, you'd have to download the source package and read through its dependencies... or read through the package page - https://packages.ubuntu.com/bionic/remmina
<teward> which lists the deps :P
<teward> as for 'pulling them in' they're *typically* already packaged in the repos and are 'pulled in' by the underlying build daemons as part of the build env setup process
<teward> via apt, for example, pulling in the dependent packages listed for the given packages
<teward> unless i'm not understanding your question well :|
<xnox> seb128, it was using my ppa because of my utf-8 characters in the launchpad ppa key
<xnox> seb128, it's on my list investigate, as to what's wrong with it.
<jmgb4> I like it how you have to put pulled in in quotes everytime teward
<vorlon> cpaelzer: can you flag that to the web team if it's not already fixed? the link on https://www.ubuntu.com/download/alternative-downloads#bittorrents should be reset to our normal schema (it was changed temporarily because we had to issue an 18.04.1.0)
<infinity> vorlon: I escalated it to them and it was fixed moments after it was noticed.
<danboid> Does the current disco installer have ZFS root support?
<sarnold> I don't believe so
<danboid> I wrote a ZFS installer for Arch and I'm hoping that Ubuntu will default to using a config that will work with zedenv boot environments, like ALEZ does
<danboid> https://github.com/danboid/ALEZ
<danboid> Arch Linux Easy ZFS installer
<sarnold> "zedenv is still experimental and should not be used on production systems"
<danboid> sarnold, Yes, but it does actually work and its best to plan ahead
<danboid> Is Ubiquity still going to be the installer in 19.10+?
<danboid> I mean, is it still the installer
<danboid> launchpad seems to think so
<sarnold> I don't follow the installer very closely, but I think at this point ubiquity will be 19.10 desktop, subiquity 19.10 default server install image, debian-installer for the alternative desktop and alternative server..
<jbicha> danboid: there is work being done on a new Ubuntu Desktop installer, it's being mentioned in https://community.ubuntu.com/c/desktop/team-updates
<jbicha> I assumed it was more related to https://lists.ubuntu.com/archives/ubuntu-devel/2018-May/040301.html than to subiquity
<danboid> I've opened a ticket as a 'reminder' https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1816190
<ubottu> Launchpad bug 1816190 in ubiquity (Ubuntu) "Use a boot environment capable ZFS config" [Undecided,New]
<jbicha> danboid: those weekly reports mention that the zfs root thing is an experiment with the new WIP installer
<jbicha> the zfs thing may have nothing to do with using zfs on your computer; it might only be about internal structuring of the live images
<jbicha> now you know just about as much as I do on the topic :)
<sarnold> danboid: nice, thanks :)
<danboid> sarnold, NP!
<danboid> You can install to ZFS with maas currently but you get zero options, there is no support for mirrored vdevs, RAIDZ etc, and it only supports installing to UEFI. I hope these restrictions don't last long
<sarnold> no mirrored vdevs? that's pretty minimal :)
#ubuntu-devel 2019-02-16
 * RAOF wonders when core-on-ZFS happen ð
<teward> xnox or vorlon: can one of you confirm my knowledge for me?  A source package in Main can build-dep on Universe packages so long as the built Main binaries don't have any Universe runtime deps.  But what about a source package in Main that produces Main and Universe binaries?  The Main binaries obviously can't have the Universe runtime deps, but can the Universe binaries?
<teward> asking because nginx source pacakge builds both Main and Universe packages, and there's some things that might end up in the pipeline that would affect the Universe packages but not the Main package.  (ANd the resultant additional package that would be added would be a Universe package specifically, even though the nginx source package builds it)
<teward> sarnold said to ask either of you :p
<sarnold> :)
<JackFrost> teward: See also: irssi 1.2.0
<JackFrost> I just did this, thanks to Rhonda's thinking the otr plugin is in universe while the rest remain in main.
<sarnold> sweet, thanks JackFrost
<teward> JackFrost: in that otr has Universe runtime deps to work?
<teward> because build-deps I know about :p
<JackFrost> teward: ...Well it links against libotr, sooo..
<JackFrost> sarnold: Sure thing!
<teward> so that's a yes heh
<JackFrost> Very much so, yep!
<teward> cool.
<teward> then that should settle the question that i posed to sarnold lol
<teward> and The More We Know :P *shot*
<sarnold> it sure sounded plausible as the way things would work but I didn't want to give teward a wrong asnwer :)
<sarnold> *rainbow&
<teward> lol
<JackFrost> Rhonda spoke to one of the Ubuntu peeps, so I took that word on it. :P
<RAOF> sarnold: thanks for the yaml-cpp review!
<sarnold> RAOF: and thanks to you for humouring my questions :)
#ubuntu-devel 2020-02-11
<ackk> juliank, hi, wrt your comment on https://code.launchpad.net/~ack/ubuntu/+source/maas/+git/maas/+merge/378890 is https://pastebin.canonical.com/p/W2twwC7HVj/ what you mean? sorry, having trouble unpacking your sentence, not super-familiar with debian policies
<juliank> ackk: No, the opposite of that
<juliank> ackk: You want Conflicts: bind9, chrony, isc-dhcp-server, maas-cli, maas-common, maas-dhcp, maas-dns, maas-proxy
<JackFrost> rbasak: It should be working again, FWIW.
<juliank> ackk: And you want Breaks: maas-rack-controller (<< 1:0.1~), maas-region-api (<< 1:0.1~), maas-region-controller (<< 1:0.1~)
<juliank> ackk: So that you tell the package manager to upgrade those 3 packages you have meta packages for, and that the other packages you Conflict with are obsolete and need to be removed
<rbasak> JackFrost: thank you!
<ackk> juliank, oh I see
<ackk> juliank, WRT makefile, it's just there for help testing with creating a repo (as is the conf/distribution). is it a problem to have it there?
<juliank> It's not a problem, but it's going to be fairly pointless once uploaded
<doko> tumbleweed:  p=toil: reverse-depends src:$p; reverse-depends -b src:$p
<doko> b'<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">\n<html><head>\n<title>500 Internal Server Error</title>\n</head><body>\n<h1>Internal Server Error</h1>\n<p>The server encountered an internal error or\nmisconfiguration and was unable to complete\nyour request.</p>\n<p>Please contact the server administrator at \n admin@ubuntuwire.com to inform them of the time this error occurred,\n and the actions you performed just before this error.</p>\n<p
<doko> >More information about this error may be available\nin the server error log.</p>\n<hr>\n<address>Apache/2.4.18 (Ubuntu) Server at qa.ubuntuwire.org Port 80</address>\n</body></html>'
<ackk> juliank, fair enough
<ackk> juliank, thanks, updated everything I think
<juliank> ackk: I think you also want to make the Replaces unversioned for those items that have turned from Breaks to Conflicts
<juliank> ackk: snapd is also available on s390x and armhf, I take it there are no maas snaps built for those?
<ackk> juliank, correct. about that, I was wondering if the list should be there for all packages, or just the "maas" one and have "all" for the others?
<tumbleweed> doko: I'll poke it
<JackFrost> rbasak: Heh, looks like you or someone poked IS anyway.
<rbasak> JackFrost: I did, yes, thanks. I'm a bit puzzled as to how it's all put together and who can do what, but thank you for whatever you did, if anything :-)
<juliank> ackk: Well
<JackFrost> rbasak: Someone just restarted it too, which is likely a decent thing anyway.  I'm not Canonical at all, just know a trick to get it back. :)
<juliank> ackk: This way at least, you don't end up with packages that have missing dependencies
<juliank> ackk: But it's a bit wasteful
<rbasak> JackFrost: I'm starting to make sense of it now, thanks :)
<ackk> juliank, yeah, I was wondering if there was a best practice for this case
<juliank> optimally the snap would be published for armhf and s390x as well, then the package could be architecture: all
<juliank> I mean, it could be now, but it would fail to install there
<juliank> which isn't super nice
<juliank> but also not super terrible I think
<ackk> juliank, right, but we don't support those archs at the moment. publishing snaps would mean we'd have to (or at least give the impression we do?)
<juliank> Well, they were "supported" before, fsvo of that word
<juliank> in the sense that the binaries where architecture independent and could be installed everywhere :)
<juliank> The other argument is that probably nobody will have installed it, so keeping it Architecture: all won't break anyone
<juliank> The other argument is that if people do have it installed on armhf/s390x, they'll be left without maas after a dist-upgrade, instead of an old maas
<juliank> which I think is all reasonable
<juliank> but not super optimal
<juliank> Probably keeping the Architecture list makes sense
<juliank> but you probably do need them for all, so ubuntu-release-upgrader has an easier time
<juliank> and offers to remove the maas installation on armhf/s390x (if any) after an install
<juliank> s/install$/dist upgrade/
<xnox> ackk:  given that MAAS supports s390x, i'm not sure why you wouldn't built it there?
<ackk> juliank, ok, sparkiegeek just enabled builds for all archs, so I guess I can switch to all there
<ackk> xnox, IDK why they weren't built before
<xnox> ackk:  however the argument is that normally one will deploy MAAS on an amd64 box, and then deploy onto s390x from an amd64 box
<xnox> ackk:  needs manually ticking tick boxes
<xnox> =)
<ackk> yeah
<ackk> I'll switch it to all
<juliank> Sometimes I feel I should add External-Depends: snap:foo to apt
<juliank> so people can depend on snaps
<juliank> to some extend :D
<juliank> or Snap-Depends: foo
<juliank> :D
<ackk> juliank, ooh that'd be nice, with channel/tracks please :)
<juliank> Snap-Depends: foo/ubuntu-18.04
<juliank> ?
<juliank> :D
<ackk> juliank, Snap:Depends maas:2.7/stable/ubuntu-18.04 ? :)
<juliank> channels confuse me, aargh
<ackk> juliank, you're not alone
<ackk> juliank, we might still have an issue with i386 though?
<juliank> ackk: no, i386 is dead
<ackk> juliank, for apt as well?
<juliank> it's only there as an extension to amd64
<ackk> juliank, what if you have an i386 install and you ugprade?
<juliank> you can't
<juliank> packages have been removed
<juliank> (on focal)
<ackk> ah, good
<ackk> juliank, updated dependencies and set arch to "all" fwiw
<techalchemy> juliank, i finally have python-apt building with pybuild+setuptools+ tests passing, do you want me to file a bug somewhere before making a merge request?
<Darkchaos> I'm experiencing problems when rebuilding openjdk-lts on Ubuntu: The .so's have missing elf headers where building on debian has the headers. I've now tried to add buster packages to bionic within pbuilder, but it doesn't work YET. I've added binutils and everything gcc/libc related, is there something I am missing?
<Odd_Bloke> I'd like to avoid shelling out to determine the arch I'm running on; is there any file I could read that contains the same value that `dpkg --print-architecture` would return?
<cjwatson> Odd_Bloke: I'm not aware of any other reliable way
<Odd_Bloke> Thanks!
<cjwatson> Odd_Bloke: (OK, I suppose another approach is to be in an Architecture: <not "all"> package and just encode $(DEB_HOST_ARCH) into your own program or an auxiliary file at build time)
<cjwatson> Would also preclude that package being particularly compatible with just about any kind of multiarch
<juliank> techalchemy: no, a bug is not needed
<juliank> :)
<Odd_Bloke> cjwatson: That sounds more complicated than the 2ms it takes to exec dpkg warrants, so I'll stick with --print-architecture. :p  Thanks again!
<cjwatson> :-)
<dannf> Odd_Bloke: 'include /usr/share/dpkg/architecture.mk' will set the dpkg-architecture vars for ya
<Odd_Bloke> Ah, yeah, this is a runtime thing not a build time thing.
<dannf> ah
#ubuntu-devel 2020-02-12
<xnox> Odd_Bloke:  cjwatson: isn't it the first one in /var/lib/dpkg/arch ?!
<xnox> but i think that is internal / private, not public api
<mwhudson> ENOENT
<mwhudson> dpkg seems to set it at build time
<didrocks> cpaelzer: thanks for the libos-info patch (and yeah, the readme needs some update it seems :p)
<cpaelzer> didrocks: yw
<cpaelzer> for once I tried to follow the "how to contribute" and then it is outdated :-)
<cpaelzer> didrocks: did you spot any issues in the MR ?
<cpaelzer> and if not maybe say "LGTM" there as you also are listed as Reviewed-by on the last Ubuntu changes
<didrocks> cpaelzer: Iâll have a deeper look this morning, but at first glance, I didnât spot anything. Once done, yes, Iâll answer on gitlab
<cpaelzer> thank you didrocks
<tkamppeter> Some core dev around here? Could you have a look at bug 1862926? It updates SANE to make the scanning in nearly all modern multi-function printers work and hopefully also stops users from mucking around with HPLIP (bug 1766020).
<ubottu> bug 1862926 in sane-backends (Ubuntu) "Request for update: SANE 1.0.29" [High,New] https://launchpad.net/bugs/1862926
<ubottu> bug 1766020 in hplip (Ubuntu) "package python3 3.6.5-3 failed to install/upgrade: installed python3 package post-installation script subprocess returned error exit status 4" [Medium,Confirmed] https://launchpad.net/bugs/1766020
<LocutusOfBorg> tkamppeter, .
<tkamppeter> LocutusOfBorg, ? ?
<LocutusOfBorg> 16mb of debdiff... meh
<LocutusOfBorg> can't we help uploading in debian experimental and then go for ubuntu?
<tkamppeter> LocutusOfBorg, the huge debdiff is due to the upstream code included.
<tkamppeter> LocutusOfBorg, an new upstream version always causes a big debdiff, especially if it is two feature releases later.
<LocutusOfBorg> yes, but I would prefer to upload on debian expeirmental
<LocutusOfBorg> and then sync
<tkamppeter> LocutusOfBorg, could you do that? We need to get it done before FF.
<cpaelzer> cjwatson: hiho - a binfmt question, qemu's style to use this is very outdated
<cjwatson> cpaelzer: I'm pretty sure there's a Debian bug about this
<cpaelzer> yes
<cpaelzer> 866756
<cpaelzer> but I have a detail question abotu it for you as binfmt expert
<cjwatson> Sure
<cpaelzer> we had a problem e.g. in WSL containers that the (old style) direct calls to "update-binfmts ... --install" failed there
<cpaelzer> the fix in the past was to have a better contianer detection
<cjwatson> --import shouldn't have that problem
<cpaelzer> but reading through the bug above I was wondering what binfmt triggers will do
<cjwatson> I mean, by all means try it out, but it isn't supposed to fail if the equivalent of --install fails
<cpaelzer> so it would try and gracefulyl go on
<cjwatson> more or less on the grounds that the information is still on disk and can be replayed, yes
<cpaelzer> cjwatson: do you have a package in mind that already uses the --import + trigger correctly?
<cjwatson> please don't say trigger here - binfmt-support probably should support actual triggers, but it doesn't yet (https://bugs.debian.org/945019)
<ubottu> Debian bug 945019 in binfmt-support "binfmt-support: please use dpkg triggers" [Wishlist,Open]
<cjwatson> I don't know of anything using --unimport correctly (which isn't to say they don't exist); quite a few use --import (e.g. pythonX.Y, llvm-8-runtime).  But really if you follow the detailed instructions in /usr/share/doc/binfmt-support/README.Debian you should be fine
<cpaelzer> thanks cjwatson
<cjwatson> The only qemu quirks AFAIK are that it has arch-specific binfmts, and that it needs to be extra-careful to avoid accidentally registering a binfmt for the native architecture (which is a great way to instantly lock up your system)
<cpaelzer> the omit logic didn't change for years and I'd not touch it on that change
<cjwatson> I suppose you can keep on computing that at run-time and just import the right set of binfmt files
<cjwatson> I'm not sure that will work well though
<cjwatson> cpaelzer: you really want to ship the right set of binfmt files at build time rather than at run-time
<cjwatson> cpaelzer: doing it at build time means they can all go in /usr/share/binfmts/, which means that if binfmt-support is installed after qemu then it can run 'update-binfmts --import' and catch up
<cjwatson> cpaelzer: this is not going to work well if you keep the arch-specific handling entirely in the postinst
<tkamppeter> LocutusOfBorg, reported SANE update request to Debian as Debian bug 951213.
<ubottu> Debian bug 951213 in sane-backends "Request for update: SANE 1.0.29" [Important,Open] http://bugs.debian.org/951213
<LocutusOfBorg> tkamppeter, will have a look tomorrow hopefully
<tkamppeter> LocutusOfBorg, are you Debian developer?
<LocutusOfBorg> tkamppeter, yes I am
#ubuntu-devel 2020-02-13
<lathiat> Seeing an Xorg crash in libinput since todays focal updates [was fine yesterday] every time I move my touchpad - normal mouse works OK.. theres another report but due to apport its private currently. added some notes and possible upstream bug link https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1863000
<ubottu> Error: launchpad bug 1863000 not found
<marcustomlinson> doko: did you revert my 1:6.4.0-0ubuntu5?
<marcustomlinson> oh it was vorlon
<marcustomlinson> once python lands please don't forget to put it back, thanks :)
<sunweaver> hi all!
<sunweaver> For focal, it seems that i386 is not fully supported anymore... May I suggest to have eatmydata as a 32bit build? It speeds up schroot builds tremendously...
<doko> marcustomlinson: we'll need a new upload. ppc64el was still built with the old icu. but please no upload before the python3-defaults migration
<marcustomlinson> okidokes
<LocutusOfBorg> sunweaver, can you please get in touch with vorlon ?
<LocutusOfBorg> he should be the best person to talk with
<ddstreet> juliank re: lp #645404 maybe it would be easier if i just create a completely new tool instead of rewriting add-apt-repository?
<ubottu> Launchpad bug 645404 in software-properties (Ubuntu Eoan) "Support Private PPAs" [Medium,In progress] https://launchpad.net/bugs/645404
<juliank> ddstreet: i think that would be a bad user experience
<ddstreet> ok
<ai_lion> Hi
<ai_lion> Is this channel a good place to ask questions about `Germinate` and `seeds`?
<ai_lion> I have sudo_xxx.deb in my pool/ but its not installed to /target by d-i.
<coreycb> cpaelzer: doko: I think I need to add python3-importlib-metadata back to kombu. it's breaking several packages because they run tests for all available py3's.
<ai_lion> After installation, I get sudo command not found, and it can be installed by root user.
<coreycb> cpaelzer: doko: that's for bug ug 1851393
<coreycb> bug 1851393
<ubottu> bug 1851393 in python-zipp (Ubuntu) "[MIR] python-importlib-metadata (required by kombu)" [High,New] https://launchpad.net/bugs/1851393
<cpaelzer> coreycb: I thought that is now part of python3 itself
<cpaelzer> coreycb: didn't that work out as expected
<coreycb> cpaelzer: it's part of python3.8 only
<cpaelzer> coreycb: so as long as here is a 3.7 left in focal you are broken  - is that it?
<coreycb> cpaelzer: yes. I suppose I could go through all the packages that use it and change up tests but that's not ideal.
<cpaelzer> hmm, yeah ok for now
<cpaelzer> doko: is the plan to eventually have no 3.7 in focal?
<cpaelzer> so that coreycb can bring back the change, just later?
<doko> marcustomlinson: you can upload a new LO now
<doko> cpaelzer, coreycb: yes, needed as long as we have 3.7 as supported, to be dropped in focal
<coreycb> doko: will 3.7 be dropped from focal soon?
<doko> yes
<cpaelzer> thanks for the insight doko
<marcustomlinson> doko: alright thanks
<ddstreet> cjwatson for merge requests to python-launchpadlib, do you prefer them in launchpad, or salsa?
<coreycb> doko: cpaelzer: I think I'll re-enable those deps just to get unblocked and continue checking on 3.7 status
<marcustomlinson> doko: question: do I now do a -v1:6.4.0-0ubuntu4?
<doko> marcustomlinson, no, don't use any previously used version number
<marcustomlinson> ok thanks
<vorlon> sunweaver: hi, I'm inclined to say that this use case is out of scope for our i386 port in focal; it exists for binary compatibility with third-party binaries, and is not a target for users to build against
<ackk> juliank, hi, wrt https://code.launchpad.net/~ack/ubuntu/+source/maas/+git/maas/+merge/378890, would you be able to sponsor the upload to focal?
<juliank> ackk: I wonder if I need to break the apt-mark use first
<ackk> juliank, is there any other way to achieve that?
<juliank> ackk: You could Suggest postgresql from maas transitional package to prevent its removal
<juliank> ackk: But aren't you migrating the database anyway so that you don't actually need to care about it once the maas transitional package is configured?
<juliank> well, unpacked even, seeing as it runs in preinst
<ackk> juliank, no, the database is not moved. the reason for that mark is that if you insatlled "maas" or "maas-region-controller", those depend on postgressql-server. so if that was installed as a dependency, an accidental apt autoremove might kill it
<juliank> Can't really discuss this now, can continue on Monday
<juliank> ackk: but I'm investigating if that's "supposed" to work
<cjwatson> ddstreet: Launchpad if upstream, Salsa if specifically to the packaging
<ddstreet> cjwatson ok ack thanks, and i assume it does need to be a bzr merge request, there is no launchpadlib git repo in Launchpad right?
<cjwatson> ddstreet: Correct, for the moment.  Will probably convert it at some point
<ackk> juliank, thanks
<mwhudson> hm i should make go 1.14rc1 the default go
<xnox> yes
<xnox> with a rebuild
<xnox> we did discuss what transitions we still need to complete before FF, we forgot about go =)
<xnox> doko:  ^^^
<xnox> mwhudson:  does it set minimum tls version in the tls package to 1.2? if not, it should. But when I tried all the tests failed.
#ubuntu-devel 2020-02-14
<mitya57> vorlon: why are you trying to sync python-secretstorage? It is still in main, and jeepney is still in universe.
<vorlon> mitya57: because I forgot that's why it wasn't synced and it showed up on merges
<mitya57> Ok
 * mitya57 should have mentioned that in changelog
<mwhudson> xnox: no idea, sorry
<xnox> juliank:  Saviq is stuck in a boot loop, where something creates Ubuntu entry, points it at grubx64 and mokmanager is not being booted (it did boot once, but he quit it rather than completing it)
<Saviq> o/ juliank - I can boot, but I have to keep the grub entry, hopefully not default
<Saviq> And yeah somehow there's nothing resembling mokmanager on my systemâ¦
<Saviq> Not sure how to add
<xnox> once booted,
<Saviq> Or is that what mmx is?
<xnox> yes it is
<xnox> not memory test thing =)
<xnox> i think in verbose mode you should be able to use efibootmgr to add a new entry and set it as bootnext
<xnox> doko:  server team were already looking at xen mini-transition when i poked them due to auto-tracker detecting it. Also it looks like at https://launchpad.net/~lucaskanashiro/+archive/ubuntu/focal-ruby2.7-transition someone from server team is evaluating ruby2.7 transition.
<Saviq> I was able to add it in setup, but it's unsignedâ¦
<xnox> sounds wrong, because it is signed
<xnox> ah
<xnox> well
<xnox> one needs to make shim boot mmx
<Saviq> Right :)
<xnox> there was like a magic config file or variables to make shim boot mm, instead of grub
<xnox> Saviq:  can you use mokutil
<xnox> and like re-roll it with:
<xnox> mokutil --disable-validation
<xnox> mokutil --enable-validation
<xnox> and after the --disable-validaion go through the whole password, reboot, type password flow
<xnox> and again after enable-validation?
<Saviq> Trying
<Saviq> Got mm to start at least
<Saviq> xnox: ok that got me through, thanks!
<Saviq> juliank, I'd still like to talk to you about what went wrong here, maybe we can fix?
<juliank> Saviq: sure we can do some digging on Monday
 * juliank is out today
<Saviq> ack!
<ahasenack> tjaalton: hi, around? Got a question about your pkcs11 patch on bind9
<ahasenack> bug #1565392 for reference
<ubottu> bug 1565392 in bind9 (Ubuntu) "[FFE] add support for native pkcs11" [Undecided,Fix released] https://launchpad.net/bugs/1565392
<rbasak> Can someone remind me where the script is for email address collection for an election please?
<ahasenack> tjaalton: is that still needed by freeipa? Debian dropped that in their 9.12.0 package, stating that there "is a better solution with openssl engines"
<tjaalton> ahasenack: 9.12 reimplemented it in some way, I guess. fedora hasn't moved to it yet
<tjaalton> just like they haven't moved to > jdk8
<ahasenack> tjaalton: but does freeipa need a bind with pkcs11 support?
<tjaalton> err, jdk > 8
<tjaalton> yes
<tjaalton> then again, it got removed from focal, so
<ahasenack> and that cannot be achieved via openssl configuration?
<ahasenack> ah, that was my next question
<ahasenack> freeipa's state in focal
<tjaalton> haven't decided if the server will be reuploaded
<tjaalton> dogtag got removed and freeipa with it, but jdk8 will be in focal
<tjaalton> so experimental has 9.15, you're going to move to it?
<ahasenack> no, the package in experimental has too many packaging changes, and looks incomplete
<ahasenack> it doesn't have devel libraries
<ahasenack> no s ymbols files
<ahasenack> (all lib packages were merged into bind9-libs, and no symbols with them)
<ahasenack> no export version too, afaik
<tjaalton> that was for a reason aiui
<tjaalton> but anyway, maybe best to stick to 9.11.x
<ahasenack> well, that's the thing
<ahasenack> the upcoming 9.16 is their lts release
<tjaalton> heh
<ahasenack> we could really benefit from moving to it
<tjaalton> your call
<ahasenack> 9.16 will be released this week or the next
 * rbasak finds https://bazaar.launchpad.net/~stefanor/+junk/election-tools/view/head:/voter-addresses.py
<Laney> that's the one
<tjaalton> ahasenack: I'm not going to block the update. apparently it's not an easy task to port bind-dyndb-ldap over
<ahasenack> ah, there's that one
<ahasenack> I haven't checked it
<ahasenack> and samba, come to think of it
<rbasak> 147 email addresses for the poll. 28 people are eligible but don't have an email address published that I can use
<rbasak> Some of them are quite active. What have they done in the past? Asked for a poll manually?
<Laney> We've previously said "if you don't receive a ballot, ask for one" in the CfV mail. I don't remember ever receiving such a request though, so maybe that's not enough?
<rbasak> IMHO it's sufficient to have emailed u-d-a@
<rbasak> (with instructions)
<rbasak> As long as I don't get inundanted with manual requests. 28 seems rather a lot. But it sounds like that won't be a concern then :)
<rbasak> inundanted
<rbasak> My fingers seem incapable of typing that
<rbasak> inundated
<Laney> It does sound high for active uploaders, I'd have expected the GPG thingy to have found email addresses from their keys
<rbasak> I disabled the GPG thingy
<rbasak> Maybe I shouldn't have
<rbasak> But don't we no longer trust SKS keyservers?
<Laney> I think it should be OK to query keyserver.u.c with the full fingerprint
<Laney> gtg have lunch, sorry
<rbasak> The code has keyserver.leg.uct.ac.za hardcoded
 * rbasak fights through some Python 2 induced UTF-8 goodness
<rbasak> With the keyserver support fix, 28 errored goes down to 2.
<rbasak> That's much better
<LocutusOfBorg> sunweaver, Missing build dependencies: mate-common (>= 1.24.0-1~)
<LocutusOfBorg> mate-common 1.24.0-0ubuntu1
<LocutusOfBorg> meh
<rbasak> "None of the above" is confusing because it'll appear backwards when people actually vote (on that particular page, "None of the below" would make more sense). What's a better term that doesn't rely on the ordering in which candidates appear?
<slashd> rbasak, do you have an example so I can see ?
<rafaeldtinoco> depmod: ERROR: ../libkmod/libkmod.c:515 lookup_builtin_file() could not open builtin file '/var/tmp/mkinitramfs_HAauWM/lib/modules/5.4.0-14-generic/modules.builtin.bin'
<rafaeldtinoco> are you all getting this ^ for focal as well ?
<rafaeldtinoco> (during update-initramfs)
<rbasak> slashd: so a quick Google revealed https://civs.cs.cornell.edu/cgi-bin/vote.pl?id=E_7afed1599f666137&akey=09c624659290123f for instance. Imagine if "None" said "None of the above". Try to vote for two of those, and nothing else.
<rbasak> (I don't mean that you should actually submit the vote, of course)
<rbasak> How about "No further candidates"?
<rbasak> Debian typically calls it "Further Discussion" but of course that doesn't make sense here.
<slashd> rbasak, I'm good with "No further candidates"
<ddstreet> rbasak possibly instead of allowing a vote for 'None' it would be better to clarify voters should use 'no opinion' for anyone they don't want to vote for, e.g. https://civs.cs.cornell.edu/faq.html
<ddstreet> adding a 'None' candidate just means that if it wins, the DMB will be short 1 member, right?
<rbasak> ddstreet: correct, but multiple people have suggested to me that it will give more credibility to the vote to permit that as an option
<rbasak> I don't see it happening that "No further candidates" will rank higher than any of the current candidates, but giving the electorate that option does make sense I guess.
<slashd> ddstreet, "no opinion" for me sound I don't care-ish ... while I think the vote should be decisive
<ddstreet> i hope 'None' doesn't win then, unless that also adjusts the threshhold for quorum :)
<rbasak> I don't think it'll happen, but if it does, I'll ask the TB to decide what to do.
<ddstreet> slashd no, the 'no option' is an actual ranking choice in the poll, not a title of something you can vote for
<ddstreet> the faq explains it in that first question
<slashd> https://civs.cs.cornell.edu/faq.html
 * slashd reading
<slashd> rbasak, ^^
<slashd> "Voters often pick âno opinionâ when what they mean is that they don't like the choice or that they don't have any information about it."
<rbasak> *If* we want to give the electorate an option to reject a candidate, then I think a "No further candidates" option makes sense to allow the electorate to positively specify that.
<rbasak> On the If, there seems to be consensus from the current DMB that we do what to do that.
<rbasak> So I intend to go ahead with "No further candidates" rather than enable the no opinion option.
<slashd> rbasak, sound good to me
<ddstreet> i guess this means there are only 8 candidates ;-)
<rbasak> ddstreet: why do you say that?
<rbasak> ddstreet: the FAQ "Setting up a poll" question 3 seems to cover this case.
<ddstreet> rbasak well i assumed we don't need 'None' option if there are more candidates than open positions
<ddstreet> but i suppose 'None' could still win over multiple candidates
<rbasak> It could
<ddstreet> rbasak option 3 is possible but it's different than just a 'None', if 'Unacceptable' won first place, then effectively the voters would have chosen *nobody* to serve on the DMB
<ddstreet> not just 1 member short
<ddstreet> anyway, whatever you think is best
<slashd> if this case happens we will ask TBD to decide what is the next step ^^^
<rbasak> ddstreet: yes. I think that's intentional. It allows the electorate to decide that everyone is unacceptable, which is a valid position to hold and be reflected in the vote.
<rbasak> It doesn't help staff the DMB of course, but if that's what the electorate wants... :)
<ddstreet> sounds like the entry should be named as suggested then, 'choices ranked below this are unacceptable'
<sladen> aka  "None of the above", which is always included on Debian votes
<sladen> so you get a result normally like   Alice, Bob, Charlies, None-of-the-above, Drew, Erin, Francis,
<rbasak> OK poll created, and announcement sent to u-d-a@
<rbasak> Now let's see how many mistakes I made :-/
<slashd> rbasak, thanks for the work on this
<slashd> rbasak, there is a typo in rafaeldtinoco nickname, but I don't think it's big enough to generate confusion about who he is, ... but prefer to let you know
<rbasak> Thanks
<rbasak> Sorry rafaeldtinoco!
<rafaeldtinoco> lol
<rafaeldtinoco> no problem, i just realized that now
<rafaeldtinoco> that slashd pointed out
<rbasak> I'm going to pull https://code.launchpad.net/~stefanor/+junk/election-tools into a git repository inside ~ubuntu-core-dev or similar. I have a bunch of fixes to the script, port to Python 3, etc. Any other choices for a good team?
<rafaeldtinoco> u mean a team to place it ? or a name for a new team ?
<rbasak> An existing team to place it
<rbasak> Maybe even ~ubuntu-dev actually
<rafaeldtinoco> +1 on ubuntu-dev
<rbasak> No reason the electorate can't help maintain the script that helps with their own elections
<rafaeldtinoco> actually its really transparent =)
<sunweaver> LocutusOfBorg: temporary issue...
<sunweaver> LocutusOfBorg: I uploaded mate-common 1.24.0-1 to unstable now. Wimpress will see that it syncs over. Then this should be amended.
<Laney> oof
<Laney> rbasak: I used NOTB before: https://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_7ce24ee3e589e440
<Laney> sorry if this is underdocumented, must have escaped my parting brain dump AKA the knowledge base
<Laney> would be good to update that while it's fresh :)
<Laney> what a great slate of candidates!
<LocutusOfBorg> sunweaver, nice!
<rafaeldtinoco> bryce: https://code.launchpad.net/~rafaeldtinoco/ubuntu/+source/initramfs-tools/+git/initramfs-tools/+merge/379222
<rafaeldtinoco> u think u can +1 this ? its very easy to reproduce and check (if you have time of course)
<bryce> rafaeldtinoco, alright, coffee first
<rafaeldtinoco> deal
<bryce> rafaeldtinoco, it's taking me a while to get kvm set up, I don't usually use kvm...  it's coming up with no network and so I can't run update-initramfs -u
<bryce> well, I mean I can run it, but I can't add the ppa before doing so
<ahasenack> bryce: tried multipass?
<ahasenack> or you need more low level access, like tweak qemu's command line?
<bryce> ahasenack, I think I need to set up a bridge network device in NetworkManager
<ahasenack> that sounds too complicated to be true
<bryce> ahasenack, I know... :-/
<ahasenack> if you install libvirt, it creates a virbr0 bridge for you
<ahasenack> same if you install multipass, it creates a bridge for you
<cpaelzer> why would you create a bridge yourself - do you need a VM that can be reached from the outside?
<cpaelzer> bryce: ^^
<bryce> cpaelzer, no, I just need to get a kvm vm that can install a ppa
<bryce> but I rarely use kvm so the directions I'm googling are confusing
<ahasenack> easiest I think is multipass; snap install multipass. multipass launch daily:focal
<ahasenack> multipass shell <name-it-gave-you>
<bryce> ahasenack, thanks that worked
<ahasenack> cool
<Saviq> w00t
<bryce> rafaeldtinoco, ok, mp looks good, +1 -- https://code.launchpad.net/~rafaeldtinoco/ubuntu/+source/initramfs-tools/+git/initramfs-tools/+merge/379222
<rafaeldtinoco> bryce: cool! thx bryce !!
<cjwatson> ricotz: Shouldn't these new transitional packages in libreoffice (-gtk2 and -kde4) actually depend on the things they're being transitional to?  As it stands it's not clear that they achieve anything
<cjwatson> ricotz: I'll accept them to get things moving, but they look kind of pointless
<ahasenack> any idea why apr-util has a build-depends on python:any?
<ahasenack> a grep for "python" in the entire source returns only a d/changelog entry saying that the python b-d was annotated with ":any"
#ubuntu-devel 2020-02-15
<mapreri> sarnold: hi there!  I've been pointed to you for apparmor-related stuff :)  I wonder, could you please have a look at https://bugs.debian.org/951331 and tell me if that thing makes sense?  I know nothing about apparmor, but I'd rather not merge blindlyâ¦
<ubottu> Debian bug 951331 in hexchat "merge HexChat AppArmor profile" [Wishlist,Open]
<mapreri> sarnold: also, tsimonq2 says hi :P
#ubuntu-devel 2020-02-16
<gbit86_> Anyone know of a c program example of using gdbus to grab a simple property value and/or subscribe to changes to it?
<gbit86_> I really want to write something fairly quickly, but in C and haven't yet found a good example that I can get up in running in a few minutes.
<joelkraehemann> hi all
<joelkraehemann> sorry, that I am asking again. Does it require any special action?
<joelkraehemann> https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#gsequencer
<ginggs> joelkraehemann: looks like libinstpatch needs removal on i386
<ginggs> joelkraehemann: i suggest ask in #ubuntu-release for that
<mitya57> locutus__: hi, can you look at Debian #943101 please? It is one of the few remaining blockers for removing Python 2 support from sip.
<ubottu> Debian bug 943101 in src:libserial "libserial: Python2 removal in sid/bullseye" [Normal,Open] http://bugs.debian.org/943101
<LocutusOfBorg> mitya57, will do
<mitya57> Thanks!
<sarnold> mapreri: hey :) thanks for the poke, please say hello back to tsimonq2 :) I've got concerns with these profiles, feel free to hold off for a bit
<sarnold> mapreri: oh :( bummer, no way to open issues for these on the github site..
<mruffell> Does apt work on focal for anyone? https://paste.ubuntu.com/p/dGfDts8hvT/
<mruffell> segfault is from apt version 1.9.7, and I see 1.9.9 is in -main. This was from a fresh daily server installation, built on 2020-01-24 09:49, which I suppose has a bad apt package
<mwhudson> mruffell: it's working for me right now
<mwhudson> although i have 1.9.9 apparently
<mruffell> mwhudson: I think the daily-current server image I downloaded is very out of date. Dowloading the new daily-pending release now
<mwhudson> mruffell: also the server installation runs apt a few times so hmm
<LocutusOfBorg> vorlon, please haproxy and libapache2-mod-perl2 i386 hints?
<mruffell> mwhudson: apt works just fine on daily-pending server timestamp 2020-02-16 08:18. The bug is fixed in 1.9.9 it seems. No need for concern
<mruffell> Maybe a new desktop and server iso should be moved from daily-pending to daily-current though
<mwhudson> yeah i wonder what the hold up is with that
<mwhudson> it might be that the ci was broken by python2 removal things
<mruffell> could be the case
